Insinuator.net

I was at the hack.lu conference in Luxembourg this year and attended the fuzzing workshop, held by René Freingruber from SEC Consult. I have been curious about this topic for some years now, but besides doing some manual fuzzing and web-fuzzing, I never looked into the whole topic that much.

The workshop lasted for around four hours. Before the workshop started each student got two VMs (Linux/Windows) where everything necessary was already set up. The VMs included 23 exercises, with step-by-step explanations, source code and exploits. René started out with an introduction to fuzzing, listing popular fuzzers and showing an example on how to fuzz with afl.

Thereafter he explained the whole process of file format fuzzing, in a clear and easily adoptable manner. Examples were shown for Linux and Windows. The differences and difficulties as for fuzzing on Windows were explained. It was also shown how to find exploitable vulnerabilities from the previously acquired crashes.

After a short break René introduced DynamRIO and PIN. Both tools are used for dynamic instrumentation. Two demos of the tools were shown, followed by a real-world example where he fuzzed mimikatz, the all beloved password recovery tool. To avoid running mimikatz on the compromised host, one can just dump the process memory of lsass.exe and load it into mimikatz to get credentials. Any idea where this is heading? Exactly, file format fuzzing!

eip=41414141, looks like IP control to me ;D. A detailed writeup can be found over here.

The rest of the workshop René explained and discussed the areas which influence the fuzzing results. These can be divided into mutators, detection rate, input filesize and fuzzer speed. Instead of going into much detail myself I will just refer to his slides, which cover the topic way better than if I try to break it down in a few sentences.

René showed a lot of practical examples, although unfortunately there was not enough time to finish all of them while attending the workshop. Quite some time was spent on how to speed up the whole fuzzing process. Still I think it would be nice if more time could be spent on the practical examples.

The first exercise to introduce fuzzing and afl had the following source code. This code was then compiled with afl-gcc to add the instrumentation code with the following command:
afl-gcc -o main_afl main.c

Additionally, input file(s) are needed, which in this case were created with the following command:
python -c ‘print “\x00″*100’ > inputs/input

Then the fuzzer can be started with the following command:
afl-fuzz -i inputs -o output — ./main_afl @@

The -i flag specifies a directory where the input files are located and the -o flag specifies a directory where the crash files should be stored. Now afl will run and fuzz the binary. For fuzzing a “real” (instrumented) binary, one would go through the following process:

1. Generate input files or download them.
2. Instrument the source code (if possible)
3. Remove input files with same functionality
4. Reduce file size of input files.
5. Start fuzzing

Removing the input files which trigger the same functionality is done before reducing their file size. One might guess, that this should be done the other way around, but reducing the file size can take a long time and should therefore be executed on the reduced file set.

To summarize the overall workshop:

• I got a good understanding of the topic, what tools to use and how the process of fuzzing works.
• The workshop could easily have been a three days workshop.
• The students got awesome resources to start out their fuzzing journey, the slides are very good as are the VMs/demos.

So, I finally started to fuzz some binaries and have great fun doing so! Thanks very much for the workshop, René.

Cheers, Simon

—
Slides and demos can be found here.

Continue reading