Showing posts with label pen test. Show all posts
Showing posts with label pen test. Show all posts

Sunday, April 12, 2009

Fuzzy Wuzzy WebScarab

I've spent the better part of the last year working on application security issues, including a major effort to implement a secure development life-cycle. I split my days between reviewing source code, application pen testing and developing materials for the SDL initiative.

My primary tools are WebScarab, Burp Suite, RatProxy, a commercial static code analysis tool, a variety of fuzzers, InGuardians' Samurai, Cygwin and some other minor tools.

WebScarab includes a fuzzer plugin that accepts regular expressions or file input for fuzz values and allows you to specify the inputs that you want to fuzz. As an example, let's look at how this works against OWASP's WebGoat, a deliberately vulnerable web application designed for training purposes.

You can use the fuzzer in WebScarab to fuzz POST or GET request parameters. In this example, we'll look at fuzzing a simple POST request. The following screenshot shows the page in WebGoat that we'll be using for this example:

This page has a web form that takes a single search term as input. Nevermind the instructions on the WebGoat page, we're not working the exercise for this example, I'm merely using it to demonstrate WebScarab's fuzzer plugin.

When we enter a search term and submit it to the web server, we can view the request that is sent to the server using WebScarab as shown below:

The top portion of the WebScarab screen shows our request. In the middle pane you can see the search parameter, called "Username" for some reason is being submitted with a value of "lesson".

From the Summary tab in WebScarab, we can right-click on this particular POST request and select "Use as fuzz template" as you can see in the next screenshot:


Once you've selected the "Use as fuzz template" option, switch over to the Fuzzer tab in WebScarab. In the Fuzzer tab, you'll see you can fuzz more than just the POST parameters. Take a look at the next screen shot to see what I'm talking about:

Notice we can fuzz cookies, GET and POST parameters. For this example, we're going to try the Username parameter. The first thing to do is pick our fuzzing Source. We do this by clicking the "Sources" button which brings up the following window:

Notice you can select a file, or enter a regular expression as fuzz sources. Using regular expressions is great for instances when you've got a numeric ID in an input and you want to try a range of other values. Say for instance you submitted a page in the app you're testing and you saw a UID=0013301 in the request. You could create a RegEx entry of [0-9][0-9][0-9][0-9][0-9][0-9][0-9], give it a description (i.e. "0000000 - 9999999"), click Add, then Close and use that regular expression to submit requests to the web server using all possible seven digit UID values. Yes, that's going to take some time.

In this example, however, we're not dealing with numeric input, so this doesn't really apply. Let's choose a file for input. A good file to use for this is All_attack.txt from www.neurofuzz.com. You'll want to run this file through awk to strip out the descriptions of the attacks contained in the file. Here's what the file looks like without being stripped:

A:::Meta-Character Injection
TRUE:::Meta-Character Injection
FALSE:::Meta-Character Injection
0:::Meta-Character Injection(Integer)
00:::Meta-Character Injection(Integer)
1:::Meta-Character Injection(Integer)
-1:::Meta-Character Injection(Integer)
1.0:::Meta-Character Injection(Integer)


It's nice to see what the different types of attacks are, but that's a lot of extraneous data to be carrying around during a pen test. No worries, fire up the following awk command:

awk -F: {'print $1'} All_attack.txt > all_attack
You'll now be left with a file that has one attack per line without the description of the attack. Adding this to your Sources in WebScarab is fairly intuitive so I won't cover it here. Once you've added the source, you can select that source as shown in the following screenshot:

After selecting the fuzz source, click the Start button on at the bottom of the window and WebScarb will start POSTing using your regular expressions or lines from your file as inputs. Yes, you can fuzz more than one field at a time, you can also set the priority so that you can different fuzz inputs for different fields and you can specify multiple sources.

What you won't see in WebScarab, is the response back from the server. For that, specify a save location for your WebScarab session data, open a terminal window in the "conversations" directory where the request and response data is saved and start parsing through the requests and responses using your favorite tools and techniques (grep is your friend) to see what inputs have what effect on the responses from the server. One quick way to isolate these is to look at file sizes for the responses. If you see big variations, you may have something interesting going on.

Sometimes WebScarab gets confused about the number of items it needs to fuzz. For example, the All_attack.txt file contains 362 lines as of this writing. But sometimes the fuzz template will submit a single request and quit. When that happens, reset the fuzz source in the drop down window for that parameter, click in the parameter field and then reselect the fuzz source. I've found that usually fixes the problem.

There are of course other fuzzing utilities available, some stand alone, some not. Burp Suite Pro has a built in fuzzer as well and it may very well be superior to the one in WebScarab. I have more experience with WebScarab so that's what I chose to use for this post. After I get some time in with Burp Suite Pro (gotta buy the Pro version), I'll post an entry on how it works.

Wednesday, August 13, 2008

Blended attacks for pen testers

Blender -- Photo courtesy of revolutionarygirl at flickr.com (http://flickr.com/photos/revolutionarygirl/)When Dan Kaminsky microblogs about a security advisory, CVE-2008-3280 and says "brainmelt", you have to think it's something particularly good. He did destroy the internet after all.

If you haven't read CVE-2008-3280 it discusses findings by Ben Laurie and his team at Google in cooperation with Dr. Richard Clayton. In short, the advisory discusses awesomely powerful blended attacks that leverage Kaminsky's DNS findings and the entropy issues Debian suffered earlier this year and the lack of CRL checking by browsers. See (CVE-2008-0166).

Will this be the year of the blended attack? Recall CVE-2008-2540, the blended attack that relied on Safari's saving downloaded files to the desktop and the way Windows desktop deals with executables.

Along these lines, I am looking forward to the insights Ed Skoudis and Kevin Johnson will share at SANS Network Security 2008. Skoudis and Johnson are teaming up to deliver the keynote titled "The Ultimate Pen Test: Combining Network and Web App Techniques for World Domination."

In my own experience conducting web app pen tests, I've found command injection flaws that allowed me to execute arbitrary system commands as the Apache user. Granted running commands with Apache's privilege level isn't as good as being root (unless the box is misconfigured), but the Apache user can cat /etc/passwd, see who frequent users are via the last command, or depending on egress filtering, may be able to run traceroute from the web server to help map the network from the inside out, or download a pen tester's agent to facilitate deeper penetration. Ahem.

Or consider a web application that contains a Cross Site Request Forgery (CSRF or XSRF depending on who you ask) vulnerability. If such a flaw exists in the web based management interface for a network security device, we have a pen testing situation that will benefit from the skills of both the web app pen tester and the traditional pen tester. Sharpen your spears for a little targeted phishing. Use Google to find postings by the firewall administrator for the organization. What are the odds that admin will be logged into the firewall web gui for hours at a time each day? Craft a good email message with a tempting link for that admin, get him to click it while logged into the vulnerabe web app and you're way.

If someone like me with limited pen testing experience can think up simple ways like this to use a web app pen test as a force multiplier for a network pen test, imagine what Skoudis and Johnson, both experts in the field will have to say on the subject. Their keynote in Vegas will be one of the best infosec talks of the year.

Grand Canyon Rim to Rim: New Gear and Best Intentions

I pulled my late 1980s backpack out of storage. My first thought was that it was heavier than I remembered, just over seven pounds empty. Ba...