This article is an excerpt from the book Professional Pen Testing for Web Applications published by Wiley Publ...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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:
POST http://192.168.1.200:8080/WebGoat/attack HTTP/1.0 Referer: http://192.168.1.200:8080/WebGoat/attack 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;) Host: 192.168.1.200:8080 Content-Length: 18 Cookie: JSESSIONID=5396FA44D38F8EE14906FCBAA7680C55 Authorization: Basic Z3Vlc3Q6Z3Vlc3Q= account_number=102
And the "command" file as:
key=account_number values=12345678900000 times=40
BOU will iteratively attack until the final attack request looks like this:
POST http://192.168.1.200:8080/WebGoat/attack HTTP/1.0 Referer: http://192.168.1.200:8080/WebGoat/attack 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;) Host: 192.168.1.200:8080 Content-Length: 563 Cookie: JSESSIONID=5396FA44D38F8EE14906FCBAA7680C55 Authorization: Basic Z3Vlc3Q6Z3Vlc3Q= account_number=12345678900000123456789000001234567890000012345678900000123456789000 00123456789000001234567890000012345678900000123456789000001234567890000012345678900 00012345678900000123456789000001234567890000012345678900000123456789000001234567890 00001234567890000012345678900000123456789000001234567890000012345678900000123456789 00000123456789000001234567890000012345678900000123456789000001234567890000012345678 90000012345678900000123456789000001234567890000012345678900000123456789000001234567 890000012345678900000123456789000001234567890000012345678900000
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.
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:\
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."