The Art of Fuzzing Slides

The Art of Fuzzing
© fotolia 41706530
Title: The Art of Fuzzing| Responsible: R. Freingruber | Version / Date: V1.0/2017-11 | Confidentiality Class: public
© 2017 SEC Consult | All rights reserved
Introduction
• René Freingruber (r.freingruber@sec-consult.com)

• Twitter: @ReneFreingruber
• Security Consultant at SEC Consult
• Reverse Engineering, Exploit development, Fuzzing
• Trainer at SEC Consult
• Secure Coding in C/C++, Reverse Engineering
• Red Teaming, Windows Security
• Speaker at conferences:
• CanSecWest, DeepSec, 31C3, Hacktivity, BSides Vienna, Ruxcon, ToorCon,
NorthSec, IT-SeCX, QuBit, DSS ITSEC, ZeroNights, Owasp Chapter, …
• Topics: EMET, Application Whitelisting, Hacking Kerio Firewalls, Fuzzing Mimikatz, …
ADVISOR FOR YOUR INFORMATION SECURITY
Vilnius | LT
Berlin| DE
Montreal | CA Moscow | RU
Zurich | CH
Vienna (HQ) | AT
Wiener Neustadt | AT
Founded 2002
Leading in IT-Security Services and Singapore | SG
Consulting
Bangkok | TH
Strong customer base in Europe and Asia
70+ Security experts
SEC Consult Offices
400+ Security audits per year SEC Consult Clients
Fuzzing
© fotolia 62904980
Fuzzing
Definition of fuzzing (source Wikipedia):
Fuzzing or fuzz testing is an automated software testing

technique that involves providing invalid, unexpected, or
random data as inputs to a computer program. The program is
then monitored for exceptions such as crashes, or failing
built-in code assertions or for finding potential memory
leaks.
Why do we need Fuzzing?
Microsoft Security Development Lifecycle (SDL) Process
Source: https://www.microsoft.com/en-us/SDL/process/verification.aspx
I also recommend fuzzing during implementation

Example: You finished a complex task and you are not sure if
it behaves correctly and is secure
 Start a fuzzer over night / the weekend  Check corpus
Why do we need Fuzzing?
SDL Phase 4 Security Requirements
Where input to file parsing code could have crossed a trust boundary, file fuzzing
must be performed on that code. […]
• An Optimized set of templates must be used. Template optimization is based on
the maximum amount of code coverage of the parser with the minimum number of
templates. Optimized templates have been shown to double fuzzing effectiveness
in studies. A minimum of 500,000 iterations, and have fuzzed at least 250,000
iterations since the last bug found/fixed that meets the SDL Bug Bar.
Source: https://msdn.microsoft.com/en-us/library/windows/desktop/cc307418.aspx
Fuzzing
• Advantages:
• Very fast (in most cases much faster than manual source code review)
• You don’t have to pay a human, only the power consumption of a computer
• It runs 24 hours / 7 days, a human works only 8 hours / 5 days
• Scalable (want to find more bugs?  Start 100 fuzzing machines instead of 1)
• Disadvantages:
• Deep bugs (lots of pre-conditions) are hard to find
• Typically you can’t find business logic bugs
© fotolia 62904980
Successful Fuzzing Examples
Demo Time!
Topic: Real-world EnCase

Imager Fuzzing (Vulnerability
found by SEC Consult
employee Wolfgang Ettlinger)
Runtime: 29 sec
Description: See real-world

fuzzing in action.
Exploitability of the vulnerability
AutoIt
• AutoIt definition (https://www.autoitscript.com):

AutoIt v3 is a freeware BASIC-like scripting
language designed for automating the Windows GUI and
general scripting. It uses a combination of
simulated keystrokes, mouse movement and
window/control manipulation in order to automate
tasks …
AutoIt Demo Source Code
AutoIt
• Another use case: Popup Killer

• During fuzzing applications often spawn error message; popup killer closes them
• Another implementation can be found in CERT Basic Fuzzing Framework (BFF)
Windows Setup files (C++ code to monitor for message box events)
Demo Time!
Topic: CS GO minimize crash
Runtime: 2 min 16 sec
Description: See real-world

example in action.
Recap
• Such straight-forward fuzzing is very often very successful!
• Example success stories:

• Encase http://blog.sec-consult.com/2017/05/chainsaw-of-custody-manipulating.html
• Counterstrike https://hernan.de/blog/2017/07/07/lock-and-load-exploiting-counter-
strike-via-bsp-map-files/
• Many others!
• But can we do better?
• What problems do you see in such fuzzing approaches?

• GUI automation is very slow
• Documentation and Specs must be read to write the fuzzer  Time consuming task!
© fotolia 62904980
Feedback-based Fuzzing
Feedback based fuzzing
• Problem: We need to read the specification / documentation to write

the fuzzer
• Solution: Use feedback from the application
• What do you think is useful feedback?
Consider this pseudocode:
Consider this pseudocode: Fuzzing Queue:

{<empty>}
Random fuzzer action:

Queue is empty, so create a
random input
Full input:
foobar
Full output:
Please enter some command
 New output, store the

associated input in fuzzing queue
(A)

{A}

Take A and modify it (uppercase)
Full input:
FOOBAR
Full output:
 Output already known, so don‘t

add input to Queue

{A}

Take A and modify it (replace it)
Full input:
command
Full output:
You entered command!
 New output, so add input to

queue (as B)

{A,B}

Take B and append random value
Full input:
Command
123
Full output:
 Output already known, do

nothing

{A,B}

Take A and append random value
Full input:
foobar
123
Full output:
 Output already known, do

nothing

{A,B}

Take B and append random value
Full input:
command
subcommand
Full output:
You entered subcommand!
 New output, store input as C
Fuzzing Queue:
Consider this pseudocode:
{A,B,C}

Take C and append random value
Full input:
Command
subcommand
trigger
Full output:
You entered subcommand!
You entered trigger!
 Crash
• I was often successful with feedback based on text-output
• Example:
• SECCON 2016 CTF – Chat binary ; nearly all CTF binaries
• Embedded hardware admin console (text-based applications)
• Pro:
• Very simple & fast to implement
• Normal application runtime during fuzzing (no performance lose)
• Con:
• Not always applicable (application does not give output messages)
• If two different behaviors do not result in different output it‘s useless
Hints for output based fuzzing:
1. Remove default output “unknown command”

• Prevents filling the fuzzing queue with useless commands
2. Removing user-reflected output can sometimes help

• Example: “login MyUser1” => Output: “Hello MyUser1”
 Two different users will have “Hello MyUser1” and “Hello MyUser2”  Two
entries in the fuzzing queue (depends on situation if we want this or not)
 Solution: Hook fprintf (and others) to just print the format string (“Hello %s\n”)
Hooking fprintf:
Without With
• LD_PRELOAD and similar techniques can be used to redirect network traffic

to files for fuzzing
• Many fuzzers only support input via files or stdin (and not network packets)
• Check: https://github.com/zardus/preeny
• But it’s error prone
• Maybe a better alternative: https://github.com/jdbirdwell/afl
• We can also change the heap implementation and other interesting

functions…. But more to this later
• On Windows use Detours or Dynamic Instrumentation Frameworks (see later)
Demo Time!
Topic: Find the flaw(s) in

SECCON CTF binary
Description: Try to find

the flaw(s) which are
triggered during
execution.
 Now consider this pseudocode
 Input „command\n“results in the orange code-coverage output
 Same for „command\nsubcommand\n“
 And so on…
Methods to measure code-coverage
1. Instrumentation during compilation (source code available; gcc or llvm  AFL)
American Fuzzy Lop - AFL
• One of the most famous file-format fuzzers

• Developed by Michal Zalewski
• Instruments application during compile time (GCC or LLVM)

• Binary-only targets can be emulated / instrumented with qemu
• Forks exist for PIN, DynamoRio, DynInst, syzygy, IntelPT, …
• Simple to use!
• Good designed! (very fast & good heuristics)
• Strategy:
1. Start with a small min-set of input sample files
2. Mutate “random” input file from queue like a dumb fuzzer
3. If mutated file reaches new path(s), add it to queue
• Consider this code (x = argc):
• Basic Blocks:
• Just use afl-gcc instead of gcc…
• Result:
Store old
register values
Instrumentation
Restore old
register values
• Instrumentation tracks edge coverage, injected code at every basic block:
cur_location = <compile_time_random_value>;
bitmap[(cur_location ^ prev_location) % BITMAP_SIZE]++;
prev_location = cur_location >> 1;
 AFL can distinguish between

• A->B->C->D->E (tuples: AB, BC, CD, DE)
• A->B->D->C->E (tuples: AB, BD, DC, CE)
• Instrumentation tracks edge coverage, injected code at every basic block:
cur_location = <compile_time_random_value>;
bitmap[(cur_location ^ prev_location) % BITMAP_SIZE]++;
prev_location = cur_location >> 1;
 AFL can distinguish between

• A->B->C->D->E (tuples: AB, BC, CD, DE)
• A->B->D->C->E (tuples: AB, BD, DC, CE)
 Without shifting A->B and B->A are indistinguishable
Without instrumentation just the

first level will be discovered (or it
would take an extremely long time)
Source:
http://lcamtuf.coredump.cx/afl_
gzip.png
Corpus Distillation
• We can either start fuzzing with an empty input folder or with downloaded /
generated input files
• Empty file:
• Let AFL identify the complete format (unknown target binaries)
• Can be very slow
• Downloaded sample files:

• Much faster because AFL doesn‘t have to find the file format structure itself
• Bing API to crawl the web (Hint: Don‘t use DNS of your provider …)
• Other good sources: Unit-tests, bug report pages, …
• Problem: Many sample files execute the same code  Corpus Distillation
Steps for fuzzing with AFL:

1. Remove input files with same functinality:
Hint: Call it after tmin again (cmin is a heuristic)
./afl-cmin –i testcase_dir –o testcase_out_dir
-- /path/to/tested/program [...program's cmdline...]
2. Reduce file size of input files:

./afl-tmin –i testcase_file –o testcase_out_file
–- /path/to/tested/program [...program's cmdline...]
3. Start fuzzing:
./afl-fuzz -i testcase_dir -o findings_dir
-- /path/to/tested/program [...program's cmdline...] @@
Demo Time!
Topic: Fuzzing FFMPEG

with AFL
Description: See the AFL

workflow (afl-cmin, afl-
tmin, afl-fuzz) in action
AFL with CVE-2009-0385 (FFMPEG)
AFL with CVE-2009-0385 (FFMPEG)
• AFL input with invalid 4xm file (strk chunk changed to strj)
• AFL still finds the vulnerability!

• Level 1 identifies correct “strk” chunk
• Level 2 based on level 1 output AFL finds the vulnerability (triggered by 0xffffffff)
LibFuzzer
• LibFuzzer – Similar concept to AFL but in-memory fuzzing

• Requires LLVM SanitizerCoverage + writing small fuzzer-functions
• LibFuzzer is more the Fuzzer for developers
• AFL fuzzes the execution path of a binary (no modification required)
• LibFuzzer fuzzes the execution path of a specific function (minimal
code modifications required)
• Fuzz function1 which processes data format 1  Corpus 1
• Fuzz function2 which processes data format 2  Corpus 2
• AFL can be also do in-memory fuzzing (persistent mode)
• Highly recommended tutorial: http://tutorial.libfuzzer.info
LibFuzzer
Source: http://tutorial.libfuzzer.info
Demo Time!
Topic: LibFuzzer vs.

OpenSSL (Heartbleed)
Runtime: 41 sec
Description: See how

LibFuzzer can be used
to find heartbleed in
several seconds.

2. Emulation of binary (e.g. with qemu)
AFL qemu mode
AFL qemu mode
AFL qemu mode

3. Writing own debugger and set breakpoints on every basicblock (slow, but useful
in some situations)
Demo Time!
Topic: Breakpoint
instrumentation of Adobe
Reader
Description: See how to

use breakpoints and a
debugger to get code-
coverage. See limitations
of this approach.
Code-Coverage via Breakpoints
• Disadvantage:
• It’s very slow
• Statically setting breakpoints can speedup the process, but it’s still
slow because of the debugger process switches
• Only really applicable if we remove a breakpoint after the first hit 
We only measure code-coverage (without a hit-count), edge-
coverage not possible or extremely slow
• On-disk files are modified (statically), which can be detected with
checksums (e.g. Adobe Reader .api files)
Code-Coverage via Breakpoints
• Advantage:
• Minset calculation
• Detection if a new file has new code-coverage is very fast (native
runtime) because we statically set breakpoints for unexplored code
and run the application without a debugger
• If it crashes we know it hit one of our breakpoints and therefore
contains unexplored code
• Often useful during reverse engineering (E.g. dump registers at
every breakpoint, see later demo)

in some situations)
4. Dynamic instrumentation of compiled application (no source code required;
tools: DynamoRio, PIN, Valgrind, Frida, …)
Dynamic Instrumentation Frameworks
• Dynamic runtime manipulation of instructions of a running application!
• Many default tools are shipped with these frameworks

• drrun.exe –t drcov -- calc.exe
• drrun.exe –t my_tool.dll -- calc.exe
• pin -t inscount.so -- /bin/ls
• Register callbacks, which are trigger at specific events (new basic block / instruction which
gets moved into code cache, load of module, exit of process, …)
• At callback (e.g. new basic block), we can further add instructions to the basic block which
get executed every time the basic block gets executed!
• Transformation time (Instrumentation Function): Analyzing a BB the first time (called once)
• Execution time (Analysis Function): Executed always before instruction gets executed
DynamoRIO
Transformation time
Execution time
Source: The DynamoRIO Dynamic Tool Platform, Derek Bruening, Google
DynamoRIO
• For transformation time callbacks can be registered

• E.g.: drmgr_register_bb_instrumentation_event()
• For execution time we have two possibilities

• Clean calls: save full context (registers) and call a C function (slow)
• Inject assembler instructions (fast)
• Context not saved, tool writer must take care himself
• Registers can be “spilled” (can be used by own instructions without losing old state)
• DynamoRio takes care of selecting good registers, saving and restoring them
• Nudges can be send to the process & callbacks can react on them
• Example: Turn logging on after the application started
DynamoRIO
• Example: Start Adobe Reader, load PDF file, exit Adobe Reader, extract coverage data
(Processing 25 PDFs with one single CPU core)
• Runtime without DynamoRio: ~30-40 seconds
• BasicBlock coverage (no hit count): 105 seconds

• Instrumentation only during transformation into code cache (transformation time)
• BasicBlock coverage (hit count): 165 seconds

• Instrumentation on basic block level (execution time)
• Edge coverage (hit count): 246 seconds

• Instrumentation on basic block level (many instructions required to save and
restore required registers for instrumentation code) (execution time)
DynamoRio vs PIN
• PIN is another dynamic instrumentation framework (older)
• Currently more people use PIN ( more examples are available)
• DynamoRio is noticeable faster than PIN
• But PIN is more reliable

• DynamoRio can’t start Encase Imager, PIN can
• DynamoRio can’t start CS GO, PIN can
• During client writing I noticed several strange behaviors of DynamoRio
Demo Time!
Topic: Instrumentation of
Adobe Reader with
DynamoRio
Description: Use
DynamoRio to extract code-
coverage of a closed-source
application using only a
simple command.
Demo Time!
Topic: Determine Adobe

Reader “PDF loaded”
breakpoint with coverage
analysis.
Description: Log coverage

of “PDF open” action to get a
breakpoint address to detect
end of PDF loading.
WinAFL
• WinAFL - AFL for Windows

• Download: https://github.com/ivanfratric/winafl
• Developed by Ivan Fratric
• Two modes:
• DynamoRio: Source code not required
• Syzygy: Source code required
• Alternative: You can easily modify WinAFL to use PIN on Windows
• Windows does not use COW (Copy-on-Write) and therefore fork-like mechanisms are not
efficient on Windows!
• On Linux AFL heavily uses a fork-server
• On Windows WinAFL heavily uses in-memory fuzzing
Demo Time!
Topic: Fuzzing mimikatz on

Windows with WinAFL
Description: See the

WinAFL fuzzing process on
Windows of binaries with
source-code available in
action.
Fuzzing and exploiting mimikatz

in some situations)
5. Static instrumentation via static binary rewriting (Talos fork of AFL which uses
DynInst framework – AFL-dyninst, should be fastest possibility if source code is
not available but it’s not 100% reliable and currently Linux only); WinAFL in
syzygy mode is very useful on Windows if source-code is available!

in some situations)
5. Static instrumentation via static binary rewriting (Talos fork of AFL which uses
DynInst framework – AFL-dyninst, should be fastest possibility if source code is
not available but it’s not 100% reliable and currently Linux only); WinAFL in
syzygy mode is very useful on Windows if source-code is available!
6. Use of hardware features
• IntelPT (Processor Tracing); available since 6th Intel-Core generation (~2015)
• WindowsIntelPT (from Talos) or kAFL
© fotolia 62904980
Areas which influent fuzzer results
Areas which influence fuzzing results
Fuzzer
Results
Fuzzer speed
Fuzzer
Results
Fuzzer Speed
1. Fork Server
2. Deferred Fork Server
3. Persistent Mode (in-memory fuzzing)
4. Prevent process switches (between target application and the Fuzzer) by injecting the Fuzzer
code into the target process
5. Modify the input in-memory instead of on-disk
6. Use a RAM Disk
7. Remove slow API calls
GUI automation – Example HashCalc
Question 1:
What is the maximum MD5
fuzzing speed with GUI
automation?
Question 2:
How many MD5 hashes can
you calculate on a CPU per
second?
WinAFL
• How to find the target function without source code?
1. Measure code coverage (drrun –t drcov) in two program invocations, one should
trigger the function, one not. Then substract both traces (IDA Pro lighthouse)
2. Log all calls and returns together with register and stack values to a logfile. Then
search for the correct input / output combination (IDA Pro funcap or a simple
DynamoRio / PIN tool)
3. Place memory breakpoints on the input
4. Use a taint engine (see later)
Demo Time!
Topic: Identification of target

function address of a closed-source
application (HashCalc).
Description: Using reverse

engineering (breakpoints on function
level via funcap and DynamoRio with
LightHouse) to identify the target
function address.
Demo Time!
Topic: In-memory fuzzing of

HashCalc using a debugger.
Description: Using the identified

addresses and WinAppDbg we
can write an in-memory fuzzer to
increase the fuzzing speed to 750
exec / sec!
Demo Time!
Topic: In-memory fuzzing of

HashCalc using DynamoRio.
Description: Using the identified

addresses and DynamoRio we
can write an in-memory fuzzer to
increase the fuzzing speed to
170 000 exec / sec!
GUI automation
• HashCalc.exe MD5 fuzzing
• GUI automation with AutoIt: ~2-3 exec / sec
• In-Memory with debugger: ~750 exec / sec
• In-Memory with DynamoRio (no instr.): ~170 000 - 200 000 exec / sec
Input filesize
Fuzzer
Results
Input file size
• The input file size is extremely important!
• Smaller files
• Have a higher likelihood to change the correct bit / byte during fuzzing
• Are faster processed by deterministic fuzzing
• Are faster loaded by the target application
• AFL ships with two utilities

• AFL-cmin: Reduce number of files with same functionality
• AFL-tmin: Reduce file size of an input file
• Uses a “fuzzer” approach and heuristics
• Runtime depends on file size
• Problems with file offsets
Input file size
• Example: Fuzzing mimikatz
• Initial memory dump: 27 004 528 Byte

• Memory dump which I fuzzed: 2 234 Byte
 I’m approximately 12 000 times faster with this setup…

• You would need 12 000 CPU cores to get the same result in the same time as my
fuzzing setup with one CPU core
• Or with the same number of CPU cores you need 12 000 days (~33 years) to get the
same result as I within one day
• In reality it’s even worse, since you have to do everything again for every queue entry
(exponential)
Heat map of the memory dump (mimikatz access)
Heat map of the memory dump (mimikatz access) - Zoomed
Fuzzing and exploiting mimikatz
See below link for in-depth discussion how I fuzzed mimikatz with WinAFL:
https://www.sec-consult.com/en/blog/2017/09/hack-the-hacker-fuzzing-mimikatz-on-windows-with-winafl-
heatmaps-0day/index.html
Creation of heatmaps
• For mimikatz I used a WinAppDbg script to extract file access information

• Very slow approach because of the Debugger
• Can’t follow all memory copies  Hitcounts are not 100% correct
• Better approach: Use dynamic instrumentation / emulation

• libdft
• Triton
• Panda
• Manticore
• Own PIN / DynamoRio tool
How my tool for heatmap creation work
1. Inject assembler instructions in front of all relevant application instructions (memory

or register operations); Don’t use clean calls because they are slow!
2. These instructions fill a buffer with “access struct” entries with the source (address
or register id), the destination, the size and the semantic
• Move semantic: mov [0x12345678], eax
• Union semantic: add EAX, [EBX]
• Untaint semantic: mov EAX, 0x12345
• Increment hitcount semantic: cmp, test, …
3. After the (thread-specific) buffer is full, a clean call is made to process the access
data, “timestamps” are used for multi-threaded applications
4. Shadow memory (1 byte to 1 bit) is used to indicate if a byte is tainted or not
5. AVL-like (balanced) tree is used to store a mapping from tainted memory ranges to
the associated file offsets (to count hit counts for file offsets)
Combine Call-Graph with Taint-Analysis
 We can write a DynamoRio/PIN tool which tracks calls and taint status
 Automatically detect target fuzz function
_start
func1 Target
func2 func3
Function func4 func1
to fuzz
access access
func5 func6 func7 func8 func9
access
access access
access
Fuzzing with taint analysis
1. Typically byte-modifications are uniform distributed over the input file

2. With taint analysis we can distribute it uniform over the tainted instructions!
If this sets EFLAGS and can change
Maybe don‘t fuzz this at all
a cc jump, it should give an extra boost…
X2 is maybe a
20 Mutations 20 Mutations
Byte 1 Instruction X1: Read byte 2 copy / search function
Instruction X2: Read byte 1,2,3,4
20 Mutations 50 Mutations Instruction X3: Read byte 2
Byte 2 Instruction X4: Read byte 1,2
20 Mutations 20 Mutations Instruction X5: Read byte 2,3
Input file
Byte 3
(5 byte) 2/10 = 20%
Byte 1 read by 2 instructions
20 Mutations 10 Mutations Byte 2 read by 5 instructions 5/10 = 50%
Byte 4
Byte 3 read by 2 instructions 2/10 = 20%
20 Mutations 0 Mutations Byte 4 read by 1 instruction 1/10 = 10%
Byte 5 Byte 5 read by 0 instructions 0/10 = 0%
The power of dynamic instrumentation frameworks
 Automatically detect target fuzz function

 Taint engine can be used on first fuzz iteration  All writes can be logged with the address to
revert the memory state for new fuzz iterations
 Enable taint engine logging only for new code coverage  Automatically detect which bytes make
the new input unique and focus on fuzzing them!
 Call-instruction logging can be used to find interesting functions
• Malloc / Free functions (to automatically change to own heap implementation)
• Own heap allocator can free all chunks allocated in a fuzz iteration  No mem leaks
• Better vulnerability detection (see later slides)
• Compare functions  Return the comparison value to the fuzzer
• Checksum functions  Automatically “remove” checksum code
• Error-handling functions
 Focus fuzzing on promising bytes
Fuzzer
Results
Mutators
AFL Mutation
• AFL performs deterministic, random, and dictionary based mutations

• AFL has a very good deterministic mutation algorithms
• Deterministic mutation strategies:

• Bit flips
• single, two, or four bits in a row
• Byte flips
• single, two, or four bytes in a row
• Simple arithmetics
• single, two, or four bytes
• additions/subtractions in both endians performed
• Known integers
• overwrite values with interesting integers (-1, 256, 1024, etc.)
AFL Mutation
• Random mutation strategies performed for an input file after

deterministic mutations are exhausted.
• Random mutation strategies:

• Stacked tweaks
• performs randomly multiple deterministic mutations
• clone/remove part of file
• Test case splicing
• splices two distinct input files at random locations and joins
them
Radamsa
• Radamsa is a very powerful input mutator

• If you don‘t want to write a mutator yourself, just use radamsa!
• https://github.com/aoh/radamsa
Radamsa
• Problem of radamsa: External program execution is slow (no library support)

• Already submitted by others as issue: https://github.com/aoh/radamsa/issues/28
• Example: Our SECCON CTF fuzzer for the chat binary
• Test 1: Before every execution we mutate the input with a call to radamsa
• Result: Execution speed is ~17 executions per second
• Test 2: Mutate input with python (no radamsa at all)

• Result: Execution speed is ~740 executions per second
•  Always create multiple output files (e.g.: 100 or 1000) or use IP:Port output
Radamsa
• Testcases as input:
test1.txt test2.txt test3.txt
Radamsa
• Often seen wrong use of radamsa:
Possible output
Only variations of
the current input file
Radamsa
• Correct invocation: Always generate multiple

outputs (100 or 1000; 100 is
recommended by radamsa) Possible output
Combination of
multiple input files!
However, merging of multiple input files is very

unlikely (“send msg + delete user + view msg” will
not be found within 2 hours)
Radamsa
• Correct selection of mutators (Example of the “chat” target):
Radamsa vs. Ni
• Radamsa is written in Owl Lisp (a functional dialect of Scheme)

• Modifying the code is hard (at least for me because I don’t know Owl Lisp)
• Currently no library support  ( Slower than in-memory mutation)
• Good mutation and gramma detection (~ 3500 lines)
• Maintained
• Ni is written in C
• Simple to modify, add to own project or compile as library (and it’s fast)
• https://github.com/aoh/ni (from the same guys)
• Not as advanced as radamsa  (~800 lines)
• Not maintained: Last commit 2014
Ni can also merging multiple inputs
 Other inputs are only used during “random_block()” function
 Merging / Gramma detection not so advanced as with radamsa
Speed comparision
• The following table gives a speed comparison between different test setups for
mutating data
• Numbers in the table are generated testcases per second
• Table does not contain fuzzing or file read/write times (only generation of fuzz data)
• TC stands for number of test cases
• RD stands for RAM disk for files & programs
• Test program was a Python script
• Radamsa fast mode uses the following mutators:
• -m bf,bd,bi,br,bp,bei,bed,ber,sr,sd
• Taken from FAQ from https://github.com/aoh/radamsa
Speed comparision – input small text files
Type of test Radamsa ext. Radamsa fast ext. Ni ext. Ni library (ctypes)
Input stdin (1 tc), output
~ 265 ~ 345 (no stdin support) -
stdout (1 tc)
Input files (3 tc), output
~ 255 ~300 ~775 -
stdout (1 tc)
Input files (3 tc), output via
~1100 ~1930 ~7300 -
files (100 tc)
Input via files (3 tc), output
~1100 ~2150 ~8350 -
via files (1000 tc)
~1220 ~2740 ~7300 -
files (100 tc); RD
~1230 ~3100 ~8400 -
files (1000 tc); RD
Input 3 samples, output
- - - ~4000
one (all in-memory)
The problem of the search space
The following input triggers the second Use-After-Free flaw in the chat binary:
Depth 1
register send_private_message
user1 user2
register Depth 10
content
user2 delete_user
login login
Depth 6
user1 user2
Depth 13
view_messages
empty
<empty>
register user1 user2 login send… register
register
register user1 user2 login send…
user1
register
register user1 user2 login send… user1
register
• We need at least 7 distinct inputs to find the flaw (register, user1, user2, login,
send_private_message, delete_user, view_message)
• During real fuzzing we have way more inputs (all possible commands, special
chars, long strings, special numbers, ….)
• After every input line we can again select one from the 7 possible inputs
• We have to find 13 inputs in the correct order to trigger the bug!
• For 13 inputs we have 7^13 = 96 889 010 407 possibilities
 Runtime of the Fuzzer to find this flaw?

 This is also a huge difference to file format fuzzing! File format fuzzing does not
produce such huge search spaces, because “commands” can’t be sent at every
node in the tree! (Nodes have less children)
 AFL is not the best choice to fuzz such problems
 We must reduce the search space!
• Initial Start-Sequence (Create Users) (This can be seen as our “input corpus”)
• Initial End-Sequence (Check public and private messages of all users)
• Encode the format into the fuzzer
• Example: send_message(username, random_string_msg))
•  Peach Fuzzer
• But that was basically what we wanted to avoid (Fuzzer should work without modification)
• Instead of adding one command per iteration, add many commands (inputs)
• Same when fuzzing web browsers  Add thousands of html, svg, JavaScript, CSS, …
lines to one test case and check for a crash
• Important: Too many commands can create invalid inputs (e.g. invalid command  Exit
application)
• Additional feedback to “choose” promising entries (E.g.: prefer text output which was not
seen yet, prefer fuzzer queue entries which often produce new output, …)
The following input triggers the second Use-After-Free flaw in the chat binary:
register send_private_message
user1 user2
register Depth 4
content
user2 delete_user
login login
user1 user2
view_messages
Demo Time!
Topic: Fuzzing SECCON CTF

binary (text feedback)
Description: See how we can

enhance the Fuzzer to find the
3rd (deep) use-after-free bug!
Chat CTF Fuzzer
• Runtime to find the deep second UAF (Use-After-Free) vulnerabiltiy…
• UAF1 was removed from patched binary because UAF1 would trigger before UAF2
• This fuzzer also works for any other CTF binary!!
Fuzzer
Results
Detection rate
Detecting not crashing vulnerabilities
 Did you notice, that we triggered 3 (!) not crashing vulnerabilities during the „chat“
introduction demo?
 And we didn‘t really see one of the bugs!
 Our Fuzzer would also not see the bugs…
 Other real world example: Heartbleed is a read buffer overflow and does not lead
to a crash…
 We (the Fuzzer) need a way to detect such flaws / vulnerabilities!
Heap Overflow Detection
Page (4096 byte), read- & write-able
Meta Meta
Heap Data 1 Heap Data 2
Data Data
Heap Overflow
Heap Overflow Detection
Page (4096 byte), read- & write-able Page (4096 byte)

NOT read- & write-able
Meta
Heap Data 1
Unused (special pattern) Data
Heap Overflow

Meta
Heap Data 2
Use-After-Free Detection

Meta
Heap Data 1
FREE
Use-After-Free Detection
Page (4096 byte) Page (4096 byte)

NOT read- & write-able NOT read- & write-able
Meta
Heap Data 1
Data
Access attempt
Access attempt
Heap Library
• Libdislocator (shipped with AFL) implements exactly this
One extra page

which is not RW
• We can also set AFL_HARDEN=1 before make (Fortify Source & Stack Cookies)
Libdislocator catches heap overflow
Libdislocator catches Use-After-Free
Demo Time!
Topic: Mimikatz vs.

GFlags & Application
Verifier with PageHeap on
Windows
Description: See how to

find bugs by just using the
application and enabling
the correct verifier settings.
• LLVM has many useful sanitizers!

• Address-Sanitizer (ASAN)
• -fsanitize=address
• Out-of-bounds access (Heap, stack, globals), Use-After-Free, …
• Memory-Sanitizer (MSAN)
• -fsanitize=memory
• Uninitialized memory use
• UndefinedBehaviorSanitizer (UBSAN)
• -fsanitize=undefined
• Catch undefined behavior (Misaligned pointer, signed integer overflow, …)
• DrMemory (based on DynamoRio) if source code is not available
 Use sanitizers during development !!!
• During corpus generation don’t use sanitizers  performance

• After we have a good corpus, start fuzzing it with sanitizers / injected libraries
• I prefer heap libraries because they are faster and run after the first fuzzing
session the corpus against binaries with sanitizers for some days
• I don’t use heap libraries for the master fuzzer (deterministic fuzzing must be fast)
• AFL performance example; one core; no in-memory fuzzing:

• x64 binary: 1400 exec / sec
• x86 binary: 1200 exec / sec
• x86 hardened binary: 1150 exec / sec
• x86 hardened binary + libdislocator: 600 exec / sec
• x86 binary with Address Sanitizer: 200 exec / sec
• Change the heap implementation to check for dangling pointers AFTER a

free() operation! (similar to MemGC)
• Check all pointers in data section, heap and stack if they point into memory
• Check must only be performed one time for new queue entries
send_private_message
Free() user2
Detection here! content
delete_user
login
Use after free user2
view_messages
Overview: Areas which influence fuzzing results
Fork-server
AFL-tmin & AFL-cmin
Faster instrumentation code
Heat maps via
Static vs. Dynamic
Instrumentation
Fuzzer speed Input filesize Taint Analysis and
Shadow Memory
In-memory fuzzing
…
No process switches
… Fuzzer
Results
Page heap / Heap libs Application aware mutators

Sanitizers (ASAN, MSAN, Detection Generated dictionaries
rate Mutators
SyzyASan, DrMemory, ..) Append vs. Modify mode
Dangling Pointer Check Grammar-based mutators
Writeable Format Strings Check Use of feedback from application
… …
© fotolia 62904980
Some public fuzzing numbers
• Example: Talk by Charlie Miller from 2010 „Babysitting an Army of Monkeys“
• Fuzzed Adobe Reader, PPT, OpenOffice, Preview
• Strategy: Dumb fuzzing

• Download many input files (PDF 80 000 files)
• Minimal corpus of input files with valgrind (PDF 1515 files)
• Measure CPU to know when file parsing ended
• Only change bytes (no adding / removing)
• Simple fuzzer in 5 LoC
Fuzzer:
Source: Charlie Miller „Babysitting an Army of Monkeys“
Results:
• 3 months fuzzing
• 7 Million Iterations
Crashes with unique EIP: Source: Charlie Miller „Babysitting an Army of Monkeys“
Other numbers from Jaanus Kääp:
• https://nordictestingdays.eu/files/files/jaanus_kaap_fuzzing.pdf
• Code coverage for minset calculation (no edge coverage because of speed)
• PDF  initial set 400 000 files  Corpus 1217 files
• DOC  initial set 400 000 files  Corpus 1319 files
• DOCX  initial set 400 000 files  Corpus 2222 files
Google fuzzed Adobe Flash in 2011:
„What does corpus distillation look like at Google scale? Turns out we have a
large index of the web, so we cranked through 20 terabytes of SWF file
downloads followed by 1 week of run time on 2,000 CPU cores to calculate the
minimal set of about 20,000 files. Finally, those same 2,000 cores plus 3 more
weeks of runtime were put to good work mutating the files in the minimal set
(bitflipping, etc.) and generating crash cases. “
The initial run of the ongoing effort resulted in about 400 unique crash signatures,
which were logged as 106 individual security bugs following Adobe's initial triage.
• Source: https://security.googleblog.com/2011/08/fuzzing-at-scale.html
Google fuzzed the DOM of major browsers in 2017:
https://googleprojectzero.blogspot.co.at/2017/09/the-great-dom-fuzz-off-of-2017.html
Rules for fuzzing
© fotolia 62904980
Fuzzing rules
1. Start fuzzing!
2. Start with simple fuzzing, during fuzzing add more logic to the next fuzzer version
3. Use Code/Edge Coverage Feedback
4. Create a good input corpus (via download or feedback)
5. Minimize the number of sample files and the file size
6. Use sanitizers / heap libraries during fuzzing (not for corpus generation)
7. Modify the mutation engine to fit your input data
8. Skip the “initialization code” during fuzzing (fork-server, persistent mode, …)
9. Use wordlists to get a better code coverage
10. Instrument only the code which should be tested
11. Don’t fix checksums inside your Fuzzer, remove them from the target application (faster)
12. Start fuzzing!
A last hint…
Fuzzing can show the presence bugs

but can’t prove the absence of bugs!
Thank you for your attention!
Source: Twitter
For any further questions contact
your SEC Consult Expert.
René Freingruber
@ReneFreingruber
r.freingruber@sec-consult.com
+43 676 840 301 749
SEC Consult Unternehmensberatung GmbH

Mooslackengasse 17
1190 Vienna, AUSTRIA
www.sec-consult.com
SEC Consult in your Region.
AUSTRIA (HQ) GERMANY SWITZERLAND
SEC Consult Unternehmensberatung GmbH SEC Consult Deutschland SEC Consult (Schweiz) AG
Mooslackengasse 17 Unternehmensberatung GmbH Turbinenstrasse 28
1190 Vienna Ullsteinstraße 118, Turm B/8 Stock 8005 Zürich
12109 Berlin
Tel +43 1 890 30 43 0 Tel +41 44 271 777 0
Fax +43 1 890 30 43 15 Tel +49 30 30807283 Fax +43 1 890 30 43 15
Email office@sec-consult.com Email office-berlin@sec-consult.com Email office-zurich@sec-consult.com
LITHUANIA SINGAPORE CANADA

UAB Critical Security, a SEC Consult company SEC Consult Singapore PTE. LTD i-SEC Consult Inc.
Sauletekio al. 15-311 4 Battery Road 100 René-Lévesque West, Suite 2500
10224 Vilnius #25-01 Bank of China Building Montréal (Quebec) H3B 5C9
Singapore (049908)
Tel +370 5 2195535 Email office-montreal@sec-consult.com
Email office-vilnius@sec-consult.com Email office-singapore@sec-consult.com
RUSSIA THAILAND
CJCS Security Monitor SEC Consult (Thailand) Co.,Ltd.
5th Donskoy proyezd, 15, Bldg. 6 29/1 Piyaplace Langsuan Building 16th Floor, 16B
119334, Moscow Soi Langsuan, Ploen Chit Road
Lumpini, Patumwan | Bangkok 10330
Tel +7 495 662 1414
Email info@securitymonitor.ru Email office-vilnius@sec-consult.com

The Art of Fuzzing Slides

Uploaded by

Copyright:

Available Formats

The Art of Fuzzing Slides

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

The Art of Fuzzing Slides

Uploaded by

Copyright:

Available Formats

The Art of Fuzzing

• René Freingruber (r.freingruber@sec-consult.com)

Definition of fuzzing (source Wikipedia):

Fuzzing or fuzz testing is an automated software testing

Microsoft Security Development Lifecycle (SDL) Process

I also recommend fuzzing during implementation

SDL Phase 4 Security Requirements

Topic: Real-world EnCase

Description: See real-world

• AutoIt definition (https://www.autoitscript.com):

• Another use case: Popup Killer

Topic: CS GO minimize crash

Runtime: 2 min 16 sec

Description: See real-world

• Such straight-forward fuzzing is very often very successful!

• Example success stories:

• But can we do better?

• What problems do you see in such fuzzing approaches?

• Problem: We need to read the specification / documentation to write

• Solution: Use feedback from the application

• What do you think is useful feedback?

Consider this pseudocode:

Consider this pseudocode: Fuzzing Queue:

Random fuzzer action:

 New output, store the

Consider this pseudocode: Fuzzing Queue:

Random fuzzer action:

 Output already known, so don‘t

Consider this pseudocode: Fuzzing Queue:

Random fuzzer action:

 New output, so add input to

Consider this pseudocode: Fuzzing Queue:

Random fuzzer action:

 Output already known, do

Consider this pseudocode: Fuzzing Queue:

Random fuzzer action:

 Output already known, do

Consider this pseudocode: Fuzzing Queue:

Random fuzzer action:

 New output, store input as C

Random fuzzer action:

• I was often successful with feedback based on text-output

Hints for output based fuzzing:

1. Remove default output “unknown command”

2. Removing user-reflected output can sometimes help

• LD_PRELOAD and similar techniques can be used to redirect network traffic

• We can also change the heap implementation and other interesting

• On Windows use Detours or Dynamic Instrumentation Frameworks (see later)

Topic: Find the flaw(s) in

Runtime: 1 min 16 sec

Description: Try to find

 Now consider this pseudocode

 Input „command\n“results in the orange code-coverage output

 Same for „command\nsubcommand\n“

1. Instrumentation during compilation (source code available; gcc or llvm  AFL)

• One of the most famous file-format fuzzers

• Instruments application during compile time (GCC or LLVM)

• Consider this code (x = argc):

• Just use afl-gcc instead of gcc…

• Instrumentation tracks edge coverage, injected code at every basic block: