One method of finding unknown vulnerabilties is simply shooting a bunch of trash data at a program to see how it reacts, and trapping any error codes. We can fuzz TCP or UDP services with a combination of Fuzzotron and Radamsa. I’ve also written a Python script that will take pcap data, strip the packet header information (Layer, IP address, port numbers, etc) leaving you with the packet data segment only, saving this to a testcase directory. This can later be fed into Radamsa, which will mangle the data (by flipping bits, shifting data, adding or removing random data, etc), which is taken by Fuzzotron and sent to the service.
First you’ll need to install some prerequisite development headers so you can compile Radamsa and Fuzzotron properly.
Then you’ll want to create a working directory for your fuzz, move into it, and clone the git repos you’ll need.
Now move into the radamsa directory (you’ll need to compile and install this beforehand, or fuzzotron will complain about missing dependancies), and compile it.
You can now move into the fuzzotron dir and compile that with radamsa support.
Feel free to generate a pcap on the port of the service you’ll be fuzzing. For this writeup I’ll be using port 80 HTTP, just as an example.
Now go and do some work for a few minutes, using the server you’ll be fuzzing normally to generate some realistic datasets to build off of. Don’t leave it on all night though, it’s tempting, but the Python script we use next could potentially OOM when trying to generate the testcases if there are too many packets to analyze.
The script I wrote looks like this:
If you cloned all the earlier git repos, you can now start generating testcases like this:
Once it finishes, it will have made a directory called ‘testcases’ with a directory tree within, each numbered dir cooresponds to the destination port number of the packet, and inside is each packet’s data in a .dat file. You can view it to make sure it looks about right by doing:
You should see something similar to:
It will differ a bit.
Fuzzing the service
Now that our setup is complete, it’s time to start actually fuzzing the service!
You should see something like:
Now you should be able to just let it run, and if/when the service crashes, it should drop a log file of the data that made it crash in the directory crash/.
Generation of a reasonable amount of quality initial data is important. This gives radamsa something to work with. You may need to let this run for a couple days to a week before it even finds a crash. It is afterall, brute force vulnerability research, and it takes a lot of time. Because of this, I usually run this kind of thing in a virtual machine, so I’m not tying up the rest of my workstation in the meantime. This also makes it simple to pause/resume a lengthy fuzz test.