Linux Firewalls - Michael Rash [50]
The goal of a backdoor is to stealthily grant an attacker the ability to do anything on a remote machine, from collecting keystrokes that reveal passwords to remotely controlling the system. Some backdoors even run their own Ethernet sniffer that is coded to extract user and password information from cleartext protocols such as telnet or FTP (although sniffing such information from other systems is less of a concern on switched networks unless the backdoor is installed on a device that is acting as a gateway or firewall).
The FsSniffer backdoor is an example of such a backdoor. It is detected with the following Snort rule:
alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"BACKDOOR FsSniffer connection
attempt"; flow:❶to_server,established; content:❷"RemoteNC Control Password|3A|";
reference: nessus,11854; classtype:trojan-activity; sid:2271; rev:2;)
At ❶ the FsSniffer Snort rule inspects packets that are part of established TCP connections and that are destined for the server side of a connection, and at ❷ the Snort rule is looking for application layer content that uniquely[32] identifies attempts by an attacker to authenticate to the FsSniffer backdoor.
Recasting this Snort rule into iptables space yields the following iptables rule. (The iptables ESTABLISHED state matching requirement at ❶ ensures that the rule matches against packets that are part of established TCP connections, and the --hex-string command-line argument at ❷ ensures that the hex code \x3A in the original content field is properly translated.)
[iptablesfw]# iptables -I FORWARD 1 -p tcp -m state --state ❶ESTABLISHED -m string
--hex-string ❷"RemoteNC Control Password|3A|" --algo bm -j LOG --log-ip-options
--log-tcp-options --log-prefix "FSSNIFFER BACKDOOR "
* * *
[29] 3 The Snort community refers to its signatures as rules, but the intrusion detection community also embraces the term signature as the mechanism for describing attacks to intrusion detection systems. In this book, the two terms are used interchangeably—nothing limits a signature to a single simple pattern, and therefore it is just as valid to refer to complex attack descriptions as signatures.
[30] 4 Not all web browsers handle this in the same way; I have seen Microsoft IE display the legitimate link while Firefox displays the malicious link (probably because the version of Firefox I was using did not interpret JavaScript embedded in this manner within link tags). Your mileage may vary.
[31] 5 For more information, see http://www.symantec.com/security_response/writeup.jsp?docid=2002-051312-3628-99&tabid=2.
[32] 6 Well, someone could manufacture the "RemoteNC Control Password:" string against an arbitrary TCP server without necessarily trying to authenticate to the FsSniffer backdoor, but either way, this activity is suspicious.
Encryption and Application Encodings
Two factors make it difficult to detect application layer attacks: encryption and application encoding schemes. Encryption is particularly problematic because it is designed to make decryption computationally infeasible in the absence of the encryption keys, and normally IDS, IPS, and firewall devices do not have access to these keys.[33]
However, some application layer exploits do not have to be encrypted in order to be successful. For example, there are Snort signatures (which necessarily operate "in the clear") for certain attacks against SSH servers. When these signatures are used, Snort is looking at payload data without access to the SSH encryption keys. The existence of these signatures tells us that encryption alone is not a panacea, and attackers can sometimes exploit vulnerabilities in applications such that layers of encryption that are normally required make no difference. That is, vulnerabilities can exist within functions that are accessible via non-encrypted means.
Encoding techniques can also be hard for an IDS to deal with. For example, many web browsers support