Linux Firewalls - Michael Rash [47]
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 "
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