Buffer overflow tools facilitate application testing

ishing.

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:

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.

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