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.

Tuesday, April 7, 2009

SANS Forensics and Incident Response Summit 2009

I'm psyched to attend (and participate in) the SANS Forensics and Incident Response Summit 2009.

I've been editing and contributing to the SANS Forensics Blog since its inception in 2008, which has kept me in frequent contact with Rob Lee, Principal Consultant for MANDIANT, SANS Faculty Fellow and lead author for SANS' forensics track. As a result, I've known about the Summit for some time and knew there were some good things brewing. Needless to say, I was thrilled to be asked to participate.

I'll post additional information at a later date. It's late, I'm tired and need to be up way too early in the morning.

Wednesday, April 1, 2009

Computer Forensics Course in Kansas City

If you live in the Kansas City area and would like to learn or increase your existing knowledge of computer forensics, I'll be teaching SANS' Security 508: Computer Forensics, Investigation and Response at the KU Med Center, two hours a week for 10 weeks beginning May 14 through July 16.

I have taken many information security courses from a variety of vendors and SANS is by far my favorite. Their course are jam packed with useful information that even experienced professionals will be able to immediately apply and 508 maybe one of the most densely packed courses in the SANS curriculum.

Here's a list of some of the items covered:
  • NTFS, FAT32/16 and Ext2/3 file systems in depth
  • Acquisition and analysis of memory for responding to live systems
  • Acquisition of disk images, local and across the network
  • Timeline acquisition and analysis
  • A look at the different layers of information on a disk drive
  • Registry analysis
  • Application footprinting
  • A review of legal aspects relating to forensics and investigations
  • A comprehensive framework of the forensics process
  • And of course, much more
In addition the course comes with the SANS Investigative Forensics Toolkit, a VMWare image with all the best open source tools you need to conduct forensics investigations and of course the course books.

It's a great course. You're sure to learn loads of useful techniques and meet other info sec professionals from your area. Covering the material over 10 weeks gives you a great chance to digest the material over time. If you're interested, I encourage you to head over to the SANS web site and register. If you have any questions, please don't hesitate to contact me. And if you are interested, but can't take the course, check out the blog (see below) and join the community.

As for myself, I've been conducting incident response and forensic investigations for more than five years. I'm a regular contributor to and editor of the SANS Forensics Blog. I've taught this course before and received high marks from the students. I'll bend over backwards to make myself available outside of class time and invite all students to contact me with questions any time, even after the course is over. I want you to be successful, to learn and to have fun and I won't be satisfied unless those objectives are met.

Friday, March 13, 2009

I must remove this log from my eye



Yes, apparently, I'm selling snake oil. I wish I could sell more of it or at least find out where all the payments are going.

If you don't know what this is about, well, this is the kind of "beat down" one gets for speaking one's mind on the internet. More details can be found over at Mubix's Room362.com and here.

Mubix is a great guy and a big contributor to the information security community. He is the one behind The Podcaster's Meetups and single-handedly brought us the fire talks at this year's Shmoocon.

I had reservations about contacting Rob to begin with and if I had it to do over again, would choose a different path.

Thursday, February 19, 2009

Steven Branigan has a great blog post about how to pick a pen tester. Branigan's point is that the trustworthiness of the pen testing team should be the number one criteria. I agree, I applaud his post and it prodded me to follow up with this post about something that's been bugging me for the last few years.

I'm amazed at some of the highly regarded people in the information security arena who have publicly bragged about exploiting systems that they clearly did not have permission to exploit. They usually consider these exploits to be harmless pranks on systems of little import, but even the least important systems (kiosks seems to be a popular target) are still maintained by someone in IT somewhere and when those systems are compromised, they still have to pulled, re-imaged and redeployed, this takes time and costs money and there's an opportunity cost and these costs are passed along to the consumers.

As info sec professionals it is our job to defend information systems. During the course of our work, we learn how systems can be compromised. We have a responsibility to use that knowledge for good. If we take that knowledge and use it for pranks or to show off, then we become the very thing we are fighting against. We become a house divided.

It has been said many times before that the difference between a white hat and a black hat is permission. If you don't have permission and you're going around messing with vulnerable systems so that you can brag to your friends about it, then you've crossed the line and it gives a bad name to the entire industry. If you wanna play 733t hax0r and break into things, then you don't belong in the ranks of information security professionals.

All of this is not to say there is not a need for legit vulnerability research, but there is a difference between original research to discover new vulnerabilities, or even non-original research in a controlled environment where you are working with permission to learn a new exploit and the types of "bob stories" I'm referring to above. I'll even grant that there are some "bob stories" that demonstrate a vulnerability without going so far as to exploit the system in question and I have no issue with that. But if your "bob story" involves exploitation without permission, do yourself a favor and keep it to yourself, or better yet, think twice and exercise a little self-control, a little professional ethics and don't cross the line no matter how harmless you think your actions may be.

I'll get off my soap box now.

Sunday, February 8, 2009

Shmoocon remix

Last Friday my alarm woke me up a 3:30 a.m. I rolled out of bed, got dressed and hit the road for destination Shmoocon 2009. This is the first hacker con I've been too since a former employer sent me to Black Hat back in 2006.

Shmoocon exceeded my expectations. Here's a roundup of my experience at the con, no this list of talks attended is not in chronological order, it's been recompiled from my notes, the program and a post-con report I put together for my employer.

I attended a talk by Arshan Dabirsiaghi and Jason Li about AntiSammy. It's an OWASP project that offers an API for validating "rich" user input for sites that allow users to input HTML and CSS, but don't want to be vulnerable to XSS.

They briefly mentioned a tool that they were also releasing called Scrubbr. DBAs can point Scrubbr at MS SQL or MySQL databases and it will find fields that contain persistent XSS.

Julia Wolfe of Fire Eye spoke about the company's work to bring down the Srizbi botnet. It was obvious from her slides that they had done some really great analysis of the malware and inner workings of the botnet, very cool stuff.

Shane Lawson gave a hilarious presentation about defeating Kwikset's SmartKey. This one made me want a lock pick set to call my own.

I also introduced myself to Paul Asadoorian and Larry Pesce of PaulDotCom fame. Larry and David Lauer of the Security Justice Podcast showed off their ShmooBall Launchers.

After the days talks were over, I headed over to hear the Podcasters Meetup. It was a great time and lots of prizes were given out. I introduced myself to Mubix, he did a great job arranging the meetup and the after hours talks. I hope this can become a regular part of Shmoocon.

Following the fire talks, HacDC hosted a great after hours party that was around two miles from the hotel. I'm a regular walker. I try to get out for at least a three mile walk every day so I knew walking to the party would be a snap, navigating the whacked out streets of DC was a bit of an adventure. I live in a part of the country where the streets are on a nice east/west, north/south grid.

The party was in an old church and featured an open bar in exchange for donations at the door. Of course the highlight for me was meeting CrucialCarl, gattaca, rybolov and myrcurial at the bash. Rybolov brought his didgeridoo and flabongo to the party.

Walking home from the party was far more adventurous than walking to the party. I tried to walk back without the aid of my iPhone. Of course I missed a turn and ended up going a few blocks too far to the south, but I quickly got back on course and found the hotel without incident. To walk a city is to know a city.

On Saturday I sat through another great list of talks. Enno Rey and Daniel Mende of ERNW gave a pair of great talks. The first was on novel ways to build botnets. One technique involved finding and taking advantage of all the ignorant fools who have snmp devices unprotected on the internet with private strings exposed.

Their second talk of the day was on attacking internet backbone protocols. It's amazing how the same kinds of security issues that plague software development also affect core internet protocols and they are all based on misplaced assumptions about trust.

Shawn Moyer and Nathan Hamiel gave a hilarious talk about problems they've found in social networking sites. These two obviously love what they do, are good at their work and could likely make a second career in stand-up.

There was a lot of hallway talk and online bitching about Jay Beale's and his vaproware, Middler (yes it's out now so stop complaining). His talk was good and it was awesome to see this tool has finally been released, even if it is a bit rough around the edges. I have downloaded the code and have been working through it.

Prior to Jay's talk, I finally met hevnsnt and surbo from i-hacked. We had a nice lunch at the Indian restaurant a block from the hotel. Great couple of guys and I hope I can get more involved in all the stuff they are doing in the Kansas City area. If you haven't purchased a raffle ticket to help them cover the rent for their hacker space and possibly win yourself a MacBook, well, what are you waiting for. Go do it now!

I attended a few other talks, but am too exhausted now to keep going. I met a bunch of interesting and wicked smart folks that I've only known virtually and saw some old friends including Ed Skoudis and Kevin Johnson of InGuardians. I introduced myself to Johnny Long early on Sunday morning when he was setting up. He's everything everyone has ever told me he is, approachable, friendly and seems genuinely interested in what others have to say. I hope to get more involved with Hackers for Charity.

I paid my own way to Shmoocon and used vacation to cover my time off. I took good notes and when I returned to work, I wrote up a little two page report for my boss of all the things I learned or thought might help out our office. As a result, she rejected my time sheet and told me to replace my vacation days with non-project training. It would have been nice to get reimbursed for my travel and lodging, but I wanted to go to Shmoocon for myself and I'm glad I did and I'm looking forward to next year.

Friday, November 7, 2008

Incident Response

Photo courtesy of tiarescott at http://www.flickr.com/photos/tiarescott/
Canadian expat, published info sec author and Bermudan beachcomber, Andrew Hay recently posted a question over at Michael Santarcangelo's Security Catalyst Community Forums asking about a framework for incident response for a bank of several hundred employees.

I gave my answer largely based on Ed Skoudis' outstanding SANS Security 504: Hacker Techniques & Incident Handling course.

I won't rehash that answer here, but I will provide some additional insights. I mentioned in my post that I used to work in info sec on a large, unprotected higher ed network. Enterprise uniformity was non-existent. The academic freedom that makes universities vibrant and interesting makes life hell for info sec personnel. If managing developers is herding cats, running an info sec program in higher ed is like being the poop-scooping clown at the back of the cat herder's parade. Hm, need a better metaphor.

Given the nature of our environment and the constraints placed on info sec, incident response was a regular activity. During my time working in academia, I responded to hundreds of incidents, thank you Blaster, Sasser, Zotob and the countless number of postcard.gif.exes.

If you're creating incident response policies and procedures, you want to be careful that they are not overly specific. Since incidents vary widely, you don't want to be constrained by a short-sighted plan that didn't account for this specific incident. If your plan states you won't pull the plug on a system without approval of the system's owner and an incident is occurring where plug pulling is needed, but the owner is unreachable, you're damned if you do and damned if you don't. Your policies and procedures need the right amount of flexibility.

If you're an info sec manager, you'll want to run interference for your incident response team. Send your IR folks out in pairs or larger teams. While one person works the incident at the keyboard, another can talk to the system's owner or the manager of the affected department. The handler at the keyboard is going to need to concentrate and that can be difficult with people walking all over you.

On a technical note, if you're going to image the system(s) in question, by all means make an image of the RAM for later analysis. There's more and more evidence of malware that remains memory resident only and if you don't grab the contents of RAM, you may not find all the evidence you need from a hard drive image only.

There's much more to be said about IR. It's a big and constantly changing field requiring practitioners to stay current.

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