Welcome back guys. I’ve been knee-deep in (attempting) to learn exploit development and prepare of OSCE. Once you understand assembly you’re on your way to actually developing your first exploit & it’s usually this flavor.
For this post I’ll be using a Windows XP SP3 VM running on VMWare Fusion (blah) and the vulnerable application will be Blaze DVD version 7.0. As an aside if you’re new to this area of study I’ll outline how this process usually flows:
- An application accepts some user input
- Give it an insane amount of malformed input
- Notice a crash
- Craft an exploit
I’ll include a few extra details here since I assume you’re a total beginning and I plan on using this as a prerequisite for more difficult BoF post (in the future). I won’t bombard you with a ton of background, I elect to reveal the relevant details at the appropriate times in the post. So let’s jump right into & have some fun along the way!
Here’s a visual of the application
To crash it we’ll feed it a malformed playlist file with the extension .PLF. Here’s the Python code to do create that file:
#!/usr/bin/env python
#
# Developed by Stacktrac3
# blazedvd_poc1.py generates a PLF file that will crash BlazeDVD Pro 7.0.
#
import sys
from struct import pack
def main():
filename = “poc.plf”
buf = “A” * 2000
f = open(filename, “wb”)
f.write(buf)
f.close()
print “[+] %s file created!” % filename
return
if __name__ == “__main__”:
main()
Once we attempt to open this file we notice the program crashes. Time to investigate! We restart the application, open Immunity, attach it to the Blaze DVD process and replay the crash. This time noticing with our 2,000 A’s we overflowed our buffer and overwrote the instruction pointer EIP. Which in exploit development is the most critical register, because it controls the program execution and always holds the address of the next instruction to execute. If we can control the EIP we control execution and if we’re clever can do what we want. See image below, note: \x41 is the hex equivalent of upper case letter A.
The next step is determining exactly how many bytes it would take to reach EIP. Before going any further here’s a breakdown of what’s about to follow. The step are generally the same for all vanilla overflows:
- Determine exact EIP offset
- Find a jmp instruction to a register where your payload inside one of the program DLLs
- Overwrite EIP with the address of the jmp instruction
- Execution will go to your jmp instruction which will take execution to the register holding your shellcode
- Game Over
The preferably way to determine the exact offset is with Metasploit pattern_create or with Mona Immunity script. I’ll use the latter.
!mona pattern_create 2000 This creates a file named pattern.txt in the Immunity folder, open this file, copy the ASCII version and replace our 2000 A’s in our script w/ it. Your once clean payload will transform into a monster similar to below:
We compile, generate the file, open Blaze attach Immunity and replicate the crash once more.
Now we record what value EIP was overwritten with in from our unique pattern:
EIP 37694136
Now again we have choices, we could use Metasploit pattern locator but I prefer to do everything in Immunity since we have Mona.
!mona pattern_offset 37694136
Mona kindly responds with Pattern 6Ai7 (0x37694136) found in cyclic pattern at position 260. Just a recap in case you’re lost in the sauce. It’s easy to get lost in all the details and forget your objective. We were able to crash the program, overflow the buffer, and overwrite the Instruction Pointer register (EIP) originally a ton of A’s. We replaced our payload (2000 A’s) with a unique pattern and leveraged Mona to tell us exactly how many bytes the offset to EIP was.
Let’s continue. Now let’s verify what Mona just told us, that it take 260 bytes to overflow our buffer and get to EIP. Our script looks like the following:
Let’s explain the changes. Since we know it takes up to 260 bytes we fill it w/ A’s. If we’re correct the next four bytes will overflow EIP so we fill it with four B’s and we should see this in EIP once we reproduce the crash. We maintain the original size of the payload 2000 bytes, and simple fill it with C’s using Python to do the math for us lol.
Excellent! /x42 is hex for B – so Mona we trust you forever you will not lie to us. Anyways we control EIP now & additionally we can see the other part of our payload C’s insides the ESP register. This is great news, this is where we’ll put our shellcode at in a second. If we can overwrite EIP with the address of a JMP ESP and instead of C’s inject our shellcode we’ll successfully hijack execution, jmp to our shellcode and pwn this app!
Let’s leverage Mona (for the zillion’th time) to find the correct instruction:mona! jmp -r esp Mona return in a minute with a bunch of potential instructions, we could anyone so long as it’s wasn’t compiled with ASLR DEP and preferably not an OS module. Another big point is that the address shouldn’t contain a null byte. We find one jmp esp 0x60349b63 Note: Normally at this point you would use a method (Mona could help of course) to find all the bad characters, we already know that the null byte is always bad. In this process you use a byte array for the part of the payload that contained the C’s. It’s an iterative process but for this post I’ve identified the other 2 characters already being \x0a \x1a.
Ok life is good, we’re done. We just need to generate our favorite shellcode and replace it where the C’s used to be, still remembering to maintain our original buffer size. Final payload:
