| Table of Contents |
|---|
Overview
The default configuration of CERT BFF will find as many unique crashes as possible. The simplest way to use BFF is to start a fuzzing campaign, and when the results start rolling in, run tools/drillresults.py to check for easily-exploitable crashes. If you get a score of a 10 or a 5, you'll probably have a relatively-easy time creating a proof-of-concept exploit (PoC). Luckily, BFF has some features that can help take the guesswork out of determining which crashes are exploitable.
...
Assuming you have Cygwin installed on your Windows fuzzing VM, crashes that appear to have a controllable EFA can be found with these commands:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
C:\BFF>find . -name "*78*msec" | grep --color 78 fuzz@UbuFuzz:~$ find ~ -name "*.gdb" | xargs egrep "^si_addr.*78*" | grep --color 78 |
Digging Into BFF Results
drillresults.py is a simple script to tease out the crashes that are most likely to give you control of the instruction pointer. But with the above two options set, we can get better insight into which crashes are interesting.
...
When testing out fuzzing strategies, it can be effective to target old software. The assumption here is that older software is more likely to crash when fuzzed. This assumption turns out to be quite true:
| Code Block | ||||
|---|---|---|---|---|
| ||||
0x2cb0f334.0x4bb3d30a - Exploitability rank: 10 Fuzzed file: results\TARGET\crashers\EXPLOITABLE\0x2cb0f334.0x4bb3d30a\sf_7d7bb89974213e3de4d2b9289fa0caba-4257-0x00130000-minimized.EXT exception 0: ExceptionHandlerCorrupted accessing 0x00130000 0040eaec f3a5 rep movs dword ptr es:[edi],dword ptr [esi] Code executing in: image00400000 exception 1: ReadAVonIP accessing 0x6e4e99dd *** Byte pattern is in fuzzed file! *** 6e4e99dd ?? ??? Instruction pointer is not in a loaded module! exception 2: ReadAVonIP accessing 0x6e4e99dd *** Byte pattern is in fuzzed file! *** 6e4e99dd ?? ??? Instruction pointer is not in a loaded module! exception 3: ReadAVonIP accessing 0x6e4e99dd *** Byte pattern is in fuzzed file! *** 6e4e99dd ?? ??? Instruction pointer is not in a loaded module! exception 4: ReadAVonIP accessing 0x6e4e99dd *** Byte pattern is in fuzzed file! *** 6e4e99dd ?? ??? Instruction pointer is not in a loaded module! exception 5: ReadAVonIP accessing 0x6e4e99dd *** Byte pattern is in fuzzed file! *** 6e4e99dd ?? ??? Instruction pointer is not in a loaded module! exception 6: ReadAVonIP accessing 0x6e4e99dd *** Byte pattern is in fuzzed file! *** 6e4e99dd ?? ??? Instruction pointer is not in a loaded module! |
This looks quite promising! The first thing we will do is take this crash and do a Metasploit string minimization on it:
| Code Block | ||||
|---|---|---|---|---|
| ||||
C:\BFF>tools\minimize.py -s -k -f results\psp501-x\crashers\EXPLOITABLE\0x5b334a69.0xae9fae70.0x58787878_0xe6b39f75.0x28e42113.0x7878787c\sf_1f25044e863e7b1bef5ae42d968fe27f-siv0qq-0x58787878.wpg |
After this is done, we will have a number of files in the minimizer_out directory. The one I'm interested in has -min-mtsp appended to the file name. We can run tools\repro.py to reproduce the crash:
| Code Block | ||||
|---|---|---|---|---|
| ||||
C:\BFF>tools\repro.py minimizer_out\sf_1f25044e863e7b1bef5ae42d968fe27f-siv0qq-0x58787878-0x58787878-min-mtsp.wpg -p immunitydebugger |
Assuming that immunitydebugger.exe is in our PATH, this will reproduce the newly-string-minimized crash in Immunity Debugger:
...
Other old target that I looked at was FastStone MaxView 1.6. After a short amount of fuzzing, this crash came up:
| Code Block | ||||
|---|---|---|---|---|
| ||||
0x3eda38dc.0x5ce6d1f9.0x00cc0000_0x3eda38dc.0x3e7d918a.0x7878787c_0x3eda38dc.0x7095d__ - Exploitability rank: 50 Fuzzed file: results\maxview-x\crashers\EXPLOITABLE\0x3eda38dc.0x5ce6d1f9.0x00cc0000_0x3eda38dc.0x3e7d918a.0x7878787c_0x3eda38dc.0x7095d__\sf_540cee04253030f363f7902b6edc732d-aikdpf-0x00cc0000.tga exception 0: WriteAV accessing 0x00cc0000 004fd19c 880416 mov byte ptr [esi+edx],al ds:0023:00cc0000=?? Code executing in: image00400000 exception 1: WriteAV accessing 0x7878787c *** Byte pattern is in fuzzed file! *** 004022c2 894104 mov dword ptr [ecx+4],eax ds:0023:7878787c=???????? |
Here we have a crash that is ranked as a 50. What makes this crash interesting is that we have a WriteAV exception, and the faulting address looks to be under our control (due to the 78's). Let's look in Immunity Debugger:
...