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
1
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
1
fuzzotron
dir and compile that with radamsa support.
Generating testcases
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
1
.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
1
crash/
.
Conclusion
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.