An Autonomous Zone

So I’ve been wanting to play with some fuzzers for a bit and get some fuzzers going on some boxes that I have laying around (they might as well be doing something – right?).

After reading “Fuzzing – Brute Force Vulnerability Discovery” http://www.amazon.com/Fuzzing-Brute-Force-Vulnerability-Discovery/dp/0321446119 (which I highly recommend if you want to get into fuzzing anything) I think I have a little bit clearer idea (at least a start) on what it is I want to fuzz and how to go about it a bit.

I decided that on my spare time I’ll play with fuzzing file formats / media files. I chose file formats for a few different reasons – the ones that come to the top of my head are:

• I wanted to play with / discover some client side vulns. I used to think that there was a big push discovering client side bugs recently (I guess mostly starting last year with all of the office and browser exploits) because there was simply less low-hanging server side vulns to be discovered. Since most systems have firewalls and extraneous services turned off there is less attack area – which means less chance to find remote (and not reliant on a dumb user) bugs. However, I think there is something that client side bugs can offer that remote exploits can’t – chiefly a targeted attack to a system inside an organization in one hit. If I was going to attack a corporation for data / internal access I’d totally start with some client side exploit to compromise a system that’s already inside of the internal network and install a rootkit. Do that to an HR, IT or similar department or a C-level guy and game over.

• There are many different applications that open the same type of file. For example, consider a zip file – there’s a ton of applications that open a zip file. On my box I generally have winrar, winzip and 7-zip and the default windows unzipper. They all do the same thing – so we can use one test case (a malformed or malicious zip file) and test it against a ton of applications. I think this way we have an easier chance to find some bugs, if one application is not vulnerable to the malicious zip file maybe another one is.

• A lot of file formats are OS independent. Going back to the point above – we can generate one malformed test case and test it against numerous OS’s. If we had a .rar file we could test it against all the windows apps that take .rar files along with, let’s say linux apps (like unrar) and even antivirus scanners.

Anyways, the main reason I think I’m choosing file formats is more bang for my buck. As long as I can generate a large number of effective test cases I’m bound to find a vuln. if I test it against a ton of applications

Generally the method is going to be the following (from “Fuzzing – Brute Force Vulnerability Discovery”):

1. Prepare a test case (malformed file).
2. Launch the target application and load the test case file.
3. Monitor the target application for faults, typically with a debugger.
4. In the event a fault is discovered, log the finding. Alternatively, if after some period of time no fault is uncovered, manually kill the target application.
5. Repeat.

So at this moment I’m kind of leaning toward starting my testing on windows apps / platform (although not exclusively). One of the main reasons I am picking windows to start with is simply the large user base and impact of a finding. Plus, I just feel a bit more comfortable writing exploits on newer windows platforms vs. newer varied unix ones. Considering the point of fuzzing is to find vulnerabilities using low effort and getting a high payoff – I’m (at least for the moment) thinking the same of exploits. With unix exploits there is generally more factors when considering writing an exploit that will work on a ton of boxes (kernel version, compilation flags, aslr, etc.).

Before I go into the tools I’m thinking of using I should go into some specifics really quick. Generally there is two types of file format fuzzing:

• Brute force or mutation-based fuzzing: This is where we get some sample files of the file type and the fuzzer generator creates mutations of them. For example it could replace data byte for byte. An example would be replacing every byte (or multiple bytes) with 0xff. You can also insert data into the file as opposed to just overwriting bytes. This is useful when testing string values. However, when inserting data into the file, we have to be aware that we might be upsetting the offsets within the file. This can severely disrupt code coverage as some parsers will quickly detect an invalid file and exit. There’s also things like checksums that can foil brute force fuzzers. Generally it’s a simple method but can be really inefficient (Although this method has been used to find high profile bugs in apps like office). An example of these types of fuzzers are FileFuzz and ufuz3.

• Intelligent Brute Force or generation-based fuzzing: With intelligent brute force fuzzing we actually have to research the file specification. An intelligent fuzzing engine is still brute force attacking, but it relies on configuration files from the user, making the process more intelligent. Think of templates that the fuzzing engine will use that has a list of data structures, positions relative to each other, and possible values. An example of this kind of fuzzer is SPIKEfile.

Besides the importance of the fuzzing generator (for heuristics) we can’t forget the importance of an automated way to load test cases in an application and monitor them for faults. What good is shoving 10,000 malicious test cases or files at an app and it crashes 4 times – if we don’t know the specifics of when/where/how it crashed? In the end the better the details we have for how the application crashed and what exactly made it crash, the easier it will be to develop an exploit for it (if it’s an exploitable bug).

So almost of equal importance to a fuzzing generator is some sort of framework for automating and monitoring the actual fuzzing.

I’m thinking that I’m going to start off with using FileFuzz from iDefense. It’s ok for what it does I guess – which is generally brute forcing file formats. It has a pretty limited functionality for a fuzzing engine – but it does have a easy-to-get-started automation and debugging/monitoring engine. Right now I’m thinking of using some other intelligent fuzzing generator to generate a shit-ton of test file cases then kick off FileFuzz to automate the loading/monitoring of the application. The drawback of FileFuzz is that the generation engine sucks and it’s not capable of muti-threading the apps that it’s testing (at least it come with the source so we can change that later if it turns out that it works well).

The other things I’m currently in the process of trying to figure out are exactly what fuzzing engine I want to use to generate test files and what file format to start on.

If anyone is interested in getting in on this buy the book and shoot me an email (anautonomouszone [at] gmail [dot] com). I’d really like to get more people on this stuff to bounce ideas off of each other.

Cheers,

Chuck B.