Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Buffer overflow tools facilitate application testing

Web applications are the conduit for buffer overflow attacks on the Web server. As such, it's imperative to make sure your applications cannot be exploited. These tools can help you out.

This article is an excerpt from the book Professional Pen Testing for Web Applications published by Wiley Publ...


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.

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:

Content-Type: application/x-www-form-urlencoded
Proxy-Connection: Keep-Alive
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;)
Content-Length: 18
Cookie: JSESSIONID=5396FA44D38F8EE14906FCBAA7680C55
Authorization: Basic Z3Vlc3Q6Z3Vlc3Q=


And the "command" file as:


BOU will iteratively attack until the final attack request looks like this:

Content-Type: application/x-www-form-urlencoded
Proxy-Connection: Keep-Alive
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;)
Content-Length: 563
Cookie: JSESSIONID=5396FA44D38F8EE14906FCBAA7680C55
Authorization: Basic Z3Vlc3Q6Z3Vlc3Q=


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. Document your findings; the attack request gets spit out to STDOUT so grab it there.

Pen testing tools and techniques
Learn more about attack simulation tools and techniques for Web applications in Chapter 6 of Professional Pen Testing for Web Applications, a free excerpt provided by Wiley Publishing.

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."

Dig Deeper on Topics Archive