Application Security Checklist

After the 2009 CWE/SANS Top 25 Most Dangerous Programming Errors was released, I started adapting it into a checklist that developers could use during the software development life cycle to facilitate the development of more secure code.

I had reviewed the Top 25 document when it was first released and thought it was pretty good, however, after really diving into it while creating the checklist, I came to appreciate it even more. It's more than a list of the top 25 errors, the document includes guidance for different phases of the software development life cycle, from the design phase through implementation and testing. Some of the entries include code samples clearly demonstrating the errors. It's very comprehensive and any developer would be well served by studying it.

In my seven years as a full time developer, I never worked in an environment that relied on checklists, so I did some searching and happened across an excellent blog post by Brian St. Pierre on the subject.

When creating a checklist, it's important that it be structured such that questions are "yes/no" with affirmative answers indicating a secure situation. Negative answers indicate a problem. This permits reviewers to quickly scan the list for negative answers and follow up on only those issues.

Of course checklists don't guarantee secure software. Developers can lie, or misunderstand, etc. But I've seen firsthand there is value in having developers put their names on a checklist and go through it. Obviously the hope is that they will fully understand the issues and answer truthfully, but just by reading the document, they may learn about the issues and improve their code.

With that, here's the checklist. Please let me know what you think and feel free to use it as you see fit. I owe special thanks to Steve Christey of MITRE for allowing this derivative work.

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.

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.

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.