A couple of days ago, I found an interesting bug during a fuzzing session that led to me creating a 0-day exploit for it. I’ve been asked a few times about the methods I use to find bugs and write exploits, so I’ve decided to take this opportunity to describe one particular workflow I use. In this post, I’ll take you through finding a bug, analzying it, and creating a functional exploit.
In order to benefit from this post, you should be familiar with basic fuzzing and exploit development.
Peach Fuzzer and WinDbg. Peach will run a series of test cases against an application and uses WinDbg to record any crash that occurs. After a record of the crash has been made, Peach will restart the application and continue with the next test case. Because of this, Peach can usually find different categories of bugs, some of which are exploitable, and others that might not be.
SocketSniff. This is a lightweight tool that captures packets flowing in and out of a process. The data captured by SocketSniff is helpful when writing a Peach Pit.
The Target: Easy File Sharing Web Server
I’ve selected EFS Software’s Easy File Sharing Web Server 6.8 as the application to analyze. This is the latest release at the time of writing. I’ll also be referring to it as EFSWS from here on because Easy File Sharing Web Server is a bit of a mouthful.
EFSWS runs as a web server on port 80 and allows users to upload and download files using any web browser. Its main purpose is to allow users to share files with one another.
Analyzing the application
I installed EFSWS on a Windows XP Professional SP3 virtual machine that I downloaded from modern.IE. modern.IE provides evaluation releases of Windows, from XP to 8.1, making it great for testing exploits. I used Windows XP for two reasons; lack of ASLR, and opt-in DEP. This makes writing exploits easier, and you can always port it over to more recent Windows releases later.
When I first started EFSWS, I was greeted by a popup message asking if I wanted to buy the software or just run it as a trial.
As it turns out, this pops up every time EFSWS is started and blocks EFSWS from starting its web server until it’s closed. Fortunately, Peach is capable of looking out for these popup windows and closing them so that it can continue automating its test cases without us having to close the popup window manually.
EFSWS has several options to customize its features. I decided to leave them at their default setting.
At this point, EFSWS is listening on port 80, ready to serve requests from web browsers.
Before launching my web browser, I attached SocketSniff to it so I could capture the messages sent between the web browser and EFSWS. Once that was done, I used Firefox to navigate to EFSWS.
I was greeted with a login screen. The first thing that caught my eye was a hyperlink under the login button that said “login as a guest”. I clicked on it and was presented with some virtual folders:
I explored a little bit more and after a while, decided to see what SocketSniff had captured. One of the earlier captures was for the vfolder.ghp request:
I noticed that the cookie contained key/value pairs called UserID and PassWD. These keys had no values assigned to them, probably because I had logged in as a guest. It looked like an interesting target to fuzz, so I decided to start with that.
Creating the Peach Pit
Peach uses XML files that describe how it should fuzz a target. These XML files are called Peach Pits. Using the capture from SocketSniff, I created a Peach Pit to fuzz UserID and PassWD when requesting vfolder.ghp:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97
One of the new features of Peach 3 is the PopupWatcher Monitor. I’m using this Monitor to close the popup window asking us to purchase EFSWS whenever it’s started. I’m also using the placeholders ##HOST## and ##PORT## so I can specify the target’s IP address and port on the command line instead of hardcoding it in the Peach Pit.
Ready, set, fuzz!
I shutdown EFSWS and SocketSniff and went ahead and started the fuzzing session using the following command:
Peach immediately launched EFSWS, closed the popup window, and started throwing test cases at the server. Within a few minutes, it started reporting crashes:
At this stage, I typically just let it do its thing for a few more minutes, or hours, depending on what crashes it’s found so far.
Picking an exploitable bug
When I came back to it, I looked into the Logs directory to see what crashes had been reported:
Three of the directories created were labeled EXPLOITABLE, so those should get higher priority in examination. After going through some of the exploitable crash information, I settled on test case EXPLOITABLE_0x020c616f_0x021e756f\518.
This is the data Peach sent to the server which triggered the crash:
1 2 3 4 5 6 7 8 9
The payload Peach used in this test case was a long string of “A”s, and it was assigned to UserID. At this point, PassWD isn’t even being fuzzed yet. I looked at the corresponding WindowsDebugEngine_description.txt file to see the state of the registers and the instruction that caused the crash:
1 2 3
EDX was the only one that had been overwritten by the payload. EIP was intact, so what caused the crash? The faulting instruction provided the answer:
It was attempting to call a function pointed to by EDX+28, and it was crashing because EDX+28 resulted in an invalid address of 0x41414169. This meant I could redirect the execution flow anywhere I wanted to because I controlled the value stored in EDX!
The beginning of a proof-of-concept exploit
I needed to take this test case used by Peach and convert it into a proof-of-concept (PoC) exploit. I created the following Python script which sent the same request as the test case:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Now that I could replicate the test case, I needed to examine what was happening in memory when the crash was triggered.
Examining the crash with Immunity Debugger
I stopped the fuzzing session, restarted EFSWS, and attached Immunity Debugger to it. According to WindowsDebugEngine_description.txt, the faulting instruction was at address 0x0045c8c2, so I set a breakpoint there.
I executed the PoC and the execution stopped at the breakpoint. A quick look at the stack showed that my payload hadn’t been received yet, so I hit F9 to continue execution. The breakpoint was hit a second time, and still, the payload hadn’t been received. I hit F9 once more, and this time, I noticed that EDX had been overwritten with 0x41414141 and the payload was visible in the stack.
ECX, ESI, and EDI were all pointing to locations in the payload, and the payload itself was located on the stack starting at address 0x19f68a8
I hit F9 to continue execution and an exception handler got triggered due to an access violation when attempting to read 0x41414169. I took a quick peek at the SEH chain hoping to see an overwrite, but there was none:
I went ahead and hit Shift-F9 several times to pass the exception to the application and it eventually recovered and waited for the next request. The server itself didn’t crash, so I didn’t need to restart it and reattach it to the debugger.
Before continuing further, I increased the size of the payload to 400 bytes. 90 bytes is pretty small and you need at least 300 bytes for a bindshell shellcode. I made the following change and reran the PoC
Much like before, the payload made it into the stack and EDX was still being overwritten. It was time to take control of the application.
Hijacking execution flow
To hijack the execution flow, I needed to overwrite EDX, but before I could do that, I needed to figure out what offset EDX was being overwritten at. I used Metasploit’s pattern_create.rb to create a 400 byte cyclic pattern and used it as my payload.
I executed the PoC and continued execution until EDX was overwritten with part of the cyclic pattern:
I ran this value against pattern_offset.rb and it returned the offset 80. To verify this, I updated the payload to write 0x42424242 80 bytes into the payload.
I ran the PoC again and sure enough, EDX was overwritten with 0x42424242
Now that I knew EDX’s offset, I needed to make it such that EDX+28 pointed to an address that contained a pointer to a set of instructions I wanted to execute. The easiest location to point to was on the stack. Windows XP doesn’t come with ASLR, so the stack addresses aren’t randomized. Looking at the stack, I noticed the payload started at 0x019F68a8 and ended at 0x019F6a34. All I needed to do was have EDX+28 fall somewhere in between that range.
What instructions should the pointer in that location point to? ECX, ESI, and EDI all point to a location in the payload, so if I could find a JMP or CALL instruction to one of those registers, it would redirect execution into the payload and start executing whatever instructions I had in there.
After a bit of searching, I found a CALL ESI at 0x10023701 in EFSWS’s ImageLoad.dll.
All I needed to do was to put 0x10023701 somewhere on the stack that EDX+28 would resolve to. I decided to place it at 0x019F6968, which was 108 bytes into the buffer of “C”s.
That meant EDX needed to be set to 0x019F6940, since 0x019F6940 + 28 = 0x019F6968. The payload was updated to reflect this:
1 2 3 4 5
I executed PoC again and hit F9 until the payload was received. EDX had now been set to 0x019F6940 and the CALL instruction showed that it was pointing to 0x10023701, an address in LoadImage.dll. I hit F7 to step into the function and it took me to the CALL ESI instruction as expected.
ESI was pointing to 0x019F68E8, which was 64 bytes into the payload:
There were only 16 bytes to work with here, but there was plenty of space in the buffer of “C”s starting at 0x019F68FC.
Since I had put the address of CALL ESI in 0x019F6968, I wanted to store my shellcode past that address. That was too far from my current location, so a short jump wouldn’t work.
Fortunately, I could reuse ESI again by adding a value to it, and then doing a JMP ESI to jump to that new location. Adding 90 bytes to ESI was sufficient to sail over 0x019F6968:
1 2 3 4 5 6 7
I ran the PoC once again, and stepped through the instructions. Everything worked as before, and after CALL ESI was executed, the execution went to the SUB ESI,-90 and JMP ESI instructions:
SUB ESI,-90 sets ESI to 0x019F6978, 12 bytes past 0x019F6968. This is where the shellcode will be placed.
Let’s pwn this thing!
When working on a PoC, I prefer to stick with launching calc.exe for my shellcode. It’s simple, small, fast, and easy to see in action. I used the calc shellcode from https://code.google.com/p/win-exec-calc-shellcode/ and removed the characters 0x00 and 0x20.
0x00 is a null byte, which would truncate the payload, and 0x20 is space, which would also truncate the payload as it’s being treated as a value assigned to UserID.
1 2 3 4 5 6 7 8 9 10 11 12 13
I updated the payload one more time to include a NOP sled and the shellcode:
1 2 3 4 5 6 7 8 9 10
I executed the PoC and stepped through each instruction until it got to the JMP ESI. I hit F7 to step through and it landed in the middle of the NOP sled:
Confident that everything should work from here on, I hit F9 to continue execution, and calc.exe popped up! The exploit worked.
Here’s the PoC after all the changes:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46
We’ve just gone through an account of how I found a bug through fuzzing, examined it, and wrote an exploit to take execute arbitrary code on the server. There is currently no patch that addresses this vulnerability, making this a 0-day exploit. You’ll also recall that we never even finished the fuzzing session. There could be more vulnerabilities waiting to be discovered in this application.
Usually at this point I refine the exploit a little more, test it against other versions of Windows to see how portable it is, and so on. I tested this exploit against Windows XP Professional SP2 and SP3. The one thing that changes are the stack addresses. Although XP has no ASLR, you would need to know the first four bytes of the address you want to jump to on the stack, and that would require testing it on other Windows machines. Additionally, since it references a stack address, the exploit won’t work against Windows Vista and higher which have ASLR. Although the program is technically vulnerable, you would need to find another way to exploit it.
You can find the final version of the exploit I submitted to Exploit-DB here. This version works with both Windows XP Professional SP2 and SP3 by guessing the stack address containing the pointer to CALL ESI.
I hope this post was informative and interesting. If you have your own workflow and favorite tools, I’d love to hear about them in the comments.