Ever-increasing complexity within networked applications makes it easier to exploit application layer vulnerabilities. We saw some creative ways to abuse the network and transport layers in Chapters 2 and 3, but these techniques are almost prosaic when compared to some of the techniques levied against applications today.
While the implementations of common network and transport layer protocols generally conform to guidelines defined by the RFCs, there is no standard that controls how a particular CGI application handles user input via a webserver, or whether an application is written in a programming language (like C) that does not have automatic bounds checking or memory management. Sometimes completely new attack techniques are discovered
and released to the security community—a good example is the concept of HTTP Cross-Site Cooking which involves mishandling of web cookies across domains (see http://en.wikipedia.org/wiki/Cross-site_cooking).
The following sections illustrate some common application layer attacks.
Certain attacks can be detected with the iptables string match extension, and an iptables rule for a specific attack is included with each example. (This is
by no means a complete list of all techniques for exploiting applications.)
7.7.3.1 Snort Signatures
One of the best ways to understand application layer attacks is to browse through the Snort signature set.3 Although recent Snort signatures are no longer distributed with the Snort source code, the Bleeding Snort project generates signatures for recent attacks in Snort format (see http://www.bleedingsnort.com).
NOTE We will discuss Snort signatures in detail in Chapter 9, but here we introduce the application layer inspection capability provided by Snort. Linking iptables rules to Snort signatures is the key to getting true intrusion detection capabilities from iptables.
Consider the following Snort signature:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-ATTACKS / etc/shadow access"; content:"/etc/shadow"; flow:to_server,established; nocase;
classtype:w eb-application-activity; sid:1372; rev:5;)
This signature detects when the string /etc/shadow (in bold above) is transferred from a web client to a webserver. The webserver (and any CGI scripts
that it executes) most likely runs as a user without sufficient permissions to read the /etc/shadow file, but an adversary doesn’t necessarily know this before trying to request the file. Snort is looking for the attempt to read the file.
In order to make iptables generate a log message when the /etc/shadow
string is seen over an established TCP connection on port 80 in the FORWARD
chain, you can use the following rule:
[iptablesfw]# iptables -I FORWARD 1 -p tcp --dport 80 -m state --state ESTABLISHED -m string --string "/etc/shadow" --algo bm -j LOG --log-prefix
"ETC_SHADOW "
7.7.3.2 Buffer Overflow Exploits
A buffer overflow exploit is an attack that leverages a programming error made in an application’s source code whereby the size of a buffer is
insufficient to accommodate the amount of data copied into it; hence the term overflow is used when adjacent memory locations are overwritten. For stack- based buffer overflows, a successful exploit overwrites the function return address (which is on the stack) so that it points into code provided by the attacker. This, in turn, allows the attacker to control the execution of the process thenceforth.
Another class of buffer overflow attacks applies to memory regions that are dynamically allocated from the heap.
Buffer overflow vulnerabilities are commonly introduced into C or C+
+ applications through improper use of certain library functions that do not automatically implement bounds checking. Examples of such
functions include strcpy(), strcat(), sprintf(), gets(), and scanf(), and mismanagement of memory regions allocated from the heap via functions such as malloc() and calloc().
NOTE You will find an excellent description of how to write buffer overflow attacks in the widely referenced paper “Smashing the Stack for Fun and Profit,” by Aleph One (see http://insecure.org/stf/smashstack.html). Jon Erickson’s Hacking: The Art of Exploitation (No Starch Press, 2007) is another excellent source of technical information on developing buffer overflow exploits.
In the context of network-based attacks, there is no generic way to detect buffer overflow attempts. However, for applications that transmit data over encrypted channels, an attack that fills a buffer with, say, 50 instances of the unencrypted character A, would be awfully suspicious. (Encrypted protocols don’t usually send the same character over and over again.)
If such an attack exists and it is shared in the underground, it may be worth adding an iptables rule to look for such behavior. For example, the
following rule would be used for SSL communications. Notice the string of A
characters:
[iptablesfw]# iptables -I FORWARD 1 -p tcp --dport 443 -m state --state
ESTABLISHED -m string --string "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAA" -j LOG --log-prefix "SSL OVERFLOW "
Because exploit code can change the filler character A to any other character, the above rule is easily circumvented by a trivial modification to the
exploit code. However, exploit code is sometimes used by automated worms without modification, so the above strategy can be effective in some cases.
While the Snort signature set contains many signatures for overflow attacks, these signatures usually detect attacks in ways that do not require seeing specific filler bytes. Sometimes the size alone of data supplied as arguments to certain application commands indicates an overflow attack.
For example, the following is a signature for an overflow against the chown
command in an FTP server. It looks for at least 100 bytes of data following the chown command in an FTP session.
alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"FTP SITE CHOWN overflow attempt";
flow:to_server,established; content:"SITE"; nocase; content:"CHOWN"; distance:0; nocase;
isdataat:100,relative; pcre:"/^SITE\s+CHOWN\s[^\n]{100}/smi"; reference:bugtraq,2120;
reference:cve,2001-0065; classtype:attempted-admin; sid:1562; rev:11;)
Although there is no regular expression engine available to iptables (having one would allow the pcre condition in bold above to be expressed within an iptables rule directly), we can produce a good iptables approximation of this Snort signature. For example, the iptables rule below searches for the site and chown strings and uses the length match to search for at least 140 byte packets. (Because the length match begins at the network layer header instead of at the application layer, we allow 20 bytes for the IP header
and 20 bytes for the TCP header.)
[iptablesfw]# iptables -I FORWARD 1 -p tcp --dport 21 -m state --state ESTABLISHED -m string --string "site" --algo bm -m string --string "chown"
--algo bm -m length --length 140 -j LOG --log-prefix "CHOWN OVERFLOW "
7.7.3.3 SQL Injection Attacks
An SQL injection attack exploits a condition in an application where user input is not validated or filtered correctly before it is included within a database query. A clever attacker can use the nesting ability of the SQL language to build a new query and potentially modify or extract information from the database. Common targets of SQL injection attacks are CGI applications that are executed via a webserver and that interface to a backend database.
For example, suppose that a CGI application performs a username and password check against data within a database using a username and password supplied by a web client via the CGI script. If the username and password are not properly filtered, the query used to perform the verification could be vulnerable to an injection attack. This attack could change the query so that it would not only check for equality, but would also modify data with a new query. The attacker could use this way in to set a password for an arbitrary user; perhaps even an administrator-level password.
It is difficult to detect a generic SQL injection, but some Snort rules come fairly close for certain attacks. For example, here is a Bleeding Snort signature that detects when an attacker attempts to truncate a section of an SQL query by supplying a closing single quote at � along with two - characters at �(along with NULL bytes following each character). The two - characters comment out the remainder of the SQL query, and this can be used to remove restrictions that may have been placed on the query through additional joins on other fields.
alert tcp $EXTERNAL_NET any -> $SQL_SERVERS 1433 (msg: "BLEEDING-EDGE EXPLOIT MS-SQL SQL Injection closing string plus line comment"; flow:
to_server,established; content: "'|00|"; content: "-|00|-|00|"; � �
reference:url,www.nextgenss.com/papers/more_advanced_sql_injection.pdf;
reference:url,www.securitymap.net/sdm/docs/windows/mssql-checklist.html;
classtype: attempted-user; sid: 2000488; rev:5; )
This Snort rule translates relatively cleanly into iptables, including the NULL characters through the use of the --hex-string command-line argument:
[iptablesfw]# iptables -I FORWARD 1 -p tcp --dport 1433 -m state --state ESTABLISHED -m string --hex-string "'|00|" --algo bm -m string --hex-string
"-|00|-|00|" --algo bm -j LOG --log-prefix "SQL INJECTION COMMENT "
One wrinkle both in the SQL Snort signature above and its iptables equivalent is that the ordering of the two content strings is not respected by either Snort or iptables. If a packet that is part of an established TCP connection contains the two strings in reverse order (with NULLs represented
in Snort’s hex notation), for example, -|00|-|00| foo bar '|00| instead of
'|00| foo bar -|00|-|00|, then both the Snort signature and the iptables rule would trigger. For some signatures, this can increase the false positive rate if there is any chance that legitimate data can emulate malicious data but in reverse.
NOTE The web reference
http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf in the Snort rule contains excellent information on SQL injection attacks.
7.7.3.4 Gray Matter Hacking
Some of the most problematic attacks on the Internet today are those that target people directly via the applications they use. These attacks circumvent the best encryption algorithms and authentication schemes by exploiting people’s tendency to trust certain pieces of information. For example, if an attacker gets a person to trust the source of certain malicious software, or bogus passwords or encryption keys, the attacker can bypass even the most sophisticated security mechanisms. It can sometimes be much easier to exploit people than to find a hole in a hardened system, application, or encryption scheme.
Phishing
Phishing is an attack whereby a user is tricked into providing authentication credentials for an online account, such as for a bank, to an untrusted source.
Typically this is accomplished by sending an official-looking email to users requesting that they access their online account and perform some “urgent”
task in the interest of security, such as changing their password. (The irony here would almost be humorous were it not for the damaging effects of a successful phishing attack against a user.) A web link is provided that appears legitimate but is subtly crafted to point the user to a website controlled by the attacker that closely mimics the authentic website. Once phished users visit the site and enter their credentials, the attacker siphons off their account credentials.
For example, here is a portion of a phishing email I received from the spoofed email address support@citibank.com with the subject Citibank Online Security Message :
When signing on to Citibank Online, you or somebody else have made several login attempts and reached your daily attempt limit. As an additional security measure your access to Online Banking has been limited. This Web security measure does not affect your access to phone banking or ATM banking. Please verify your information <a href="http://196.41. X . X /sys/"
onMouseMove="window.status='https://www.citibank.com/us/cards/index.jsp';return true;"
onMouseout="window.status=''">here</a>, before trying to sign on again. You will be able to attempt signing on to Citibank Online within twenty-four hours after you verify your information. (You do not have to change your Password at this time.)
The innocuous wording feigns a cordial and helpful attitude (“several login attempts,” and “You do not have to change your password . . .”), and the web link is carefully crafted. The link contains a bit of embedded Java-
Script that instructs a web browser to display a legitimate link to the Citibank website if the user puts the mouse pointer over the link text here in the
email message.4 However, the real destination of the link is to the URL http://196.41. X . X /sys, which is a webserver controlled by the attacker. This webserver displays a web page that looks identical to the legitimate page on the authentic Citibank website.
Fortunately, iptables can detect this particular phishing email when it is viewed over a web session with the following rule:
[iptablesfw]# iptables -I FORWARD 1 -p tcp --dport 25 -m state --state ESTABLISHED -m string --string "�http://196.41. X . X /sys/" --algo bm -m string
Trang 310
--hex-string "window.status=|27|https://� www.citibank.com" -j LOG --log-prefix
"CITIBANK PHISH "
At �and �the rule performs a multistring match against the strings
"http://196.41. X . X /sys/" and "window.status='https://www.citibank.com" within established TCP connections to the SMTP port. The first string in the
signature requires a match against the particular malicious webserver setup by the attacker, and so this rule does not generically describe all possible phishing attacks against Citibank. The second string is also important, because it looks for the Citibank website used as the argument to the window.status JavaScript window object property. While the real Citibank website might also use this construct for legitimate purposes, the combination of the two strings together in an email message is highly suspicious and has a low chance of triggering a false positive either within Snort or iptables (regardless of the order of the patterns).
You can maximize the effectiveness of new signatures for new attacks by striking a balance between effective detection and reducing the false positive rate. One of the best ways of doing this is to look for patterns that are not likely to be seen in legitimate network communications. If another phishing attack becomes popular against a new target, then good candidates for patterns to include within a signature are the IP address associated with the
malicious webserver (although this is always subject to change by the attacker) and any common language or code features (such as the window.status string in the Citibank phishing example).
Backdoors and Keystroke Logging
A backdoor is an executable that contains functionality exposed to an attacker but not to a legitimate user. For example, the Sdbot trojan5 opens a backdoor by using a custom IRC client to connect to an IRC channel where an
attacker is waiting to issue commands, but the backdoor is coded such that the attacker must provide a valid password before any action is taken. This adds a level of authentication to backdoor communications, and helps to ensure that only the attacker who successfully compromised the system is
able to control it.
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 uniquely6 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 "