This article is an excerpt from the book Professional Pen Testing for Web Applications published by Wiley Publishing.
Some of the automated tools you will see, mainly the fuzzers, perform buffer overflow testing for you. But you have some manual options as well. This is important because like most things you will be testing, you are probing for susceptibility of buffer overflows in the blind. It is very useful, but rare, to be on the inside of the app resources at the time of the attack. The fact that it is rare cannot stop you. One key point to note is that the typical target of a buffer overflow is the Web server, and deeper than that it could be the target OS, but the conduit into these targets is the Web app in the cases shown here.
BOU
Imperva puts out a free tool called BOU (Buffer Overflow Utility), which is excellent at testing Web apps for buffer overflow conditions. It is written in Java and is straightforward to use. You need to alter the provided "request" file with a legitimate request grabbed via one of your favorite Proxy servers. Then you tell it what to attack with and how much of it in a file called "command." It will spit out all of the activity to STDOUT based on the level of verbosity you specify. It is your job to analyze the results. Because it is iterative in its attack pattern, it does a great job of detecting if your target is susceptible to buffer overflows and establishing where the threshold is.
For example, if the "request" file is set up as follows:
And the "command" file as:
BOU will iteratively attack until the final attack request looks like this:
You need to focus on the responses. If they keep coming as Status Code 200s, then the app is OK, but if you start at 200s and then start getting 500s, for instance, then you have discovered a susceptibility to buffer overflows.
To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
Document your findings; the attack request gets spit out to STDOUT so grab it there.
Another popular tool for audits of buffer overflows susceptibility with a given target is NTOMax. This tool is one of the free tools put out by the excellent team over at Foundstone Inc. The concept is quite similar to BOU. All of the documentation is included with the executable once you download it.
Regardless which tool you decide to use, blind buffer overflow testing is critical. If you are fortunate enough to get on the inside of the app server during testing, then closely watch the web and app server logs with tail -f ... on *NIX systems. For Windows-based targets you will want to get the GNU utilities port for Win32 (http://unxutils.sourceforge.net/) and watch the relevant IIS logs typically located under c:\\system32\LogFiles\W3SVC1\. You will be looking for any anomaly in the server response or a crash altogether. A good tactic is to start with data you know will not cause a problem so as to establish a baseline. With the baseline of positive behavior established, you can attack until you detect a change in the behavior. This typically means the buffer overflow worked and you have your negative condition detected. You will document this finding.
-------------------------------
About the author: Andres Andreu, CISSP-ISSAP, GSEC operates neuroFuzz Application Security LLC and has a strong background with the U.S. government. Andreu specializes in software, application and Web services security, working with XML security, TCP and HTTP(S) level proxying technology, and strong encryption. Other articles he's written include "Using LDAP to solve one company's problem of uncontrolled user data and passwords" and "Salted Hashes Demystified."
