Modern Windows Buffer Overflows and Techniques
Most Windows applications are complied using Data Execution Prevention (DEP) or Address Space Layout Randomization (ASLR) support, which makes the exploitation process a lot harder as we will have to bypass these internal security mechanisms.
These memory protections were implemented in Microsoft Windows 7, (DEP) is a set of hardware, and software, technologies that perform additional checks on memory, to help prevent malicious code from running on a system. The primary benefit of DEP is to help prevent code execution from data pages, by raising an exception, when execution occurs.
ASLR randomizes the base addresses of loaded applications, and DLLs, every time the Operating System is booted.
For us to successfully buffer overflow an application we have to take control of the Extended Instruction Pointer (EIP) register. Let’s say we are exploiting a vulnerability in serv-u FTPD which crashes when we send 3000 A’s to the daemon and we end up overwriting EIP with our input buffer of A’s (the hex equivalent of the letter A is \x41). The EIP register controls the execution so this is the most important aspect for this to work.
We can use a simple python script to connect to the FTP server and send the A’s to create the crash:
# Create an array of buffers, from 1 to 5900, with increments of 200.
while len(buffer) <= 30:
for string in buffer:
print “Fuzzing PASS with %s bytes” % len(string)
s.send(‘PASS ‘ + string + ‘\r\n’)
This means that if we craft our exploit buffer carefully, we might be able to divert the execution of the program to a place of our choosing, such as a into the memory where we can introduce some reverse shell code, as part of our buffer. We also need to pay particularly close attention to the value of Extended Stack Pointer (ESP) at crash time.
While fuzzing the application you will want to launch Immunity debugger and monitor the value of these registers as we fuzz the application.
We know that the program will crash and EIP will be overwritten when we send 3000 A’s to the program so we much locate those 4 As that overwrite our EIP register in the buffer. There are a few ways of doing this, the first one would be:
Binary Tree Analysis
Instead of 3000 A’s, we send 1500 A’s and 1500 B’s. If EIP is overwritten by B’s, we know the four bytes reside in the second half of the buffer. We then change the 1500 B’s to 750 B’s and 750 C’s, and send the buffer again. If EIP is overwritten by C’s, we know that the four bytes reside in the 2250–3000 byte range. Continue splitting the specific buffer until we reach the exact four bytes that overwrite EIP. Mathematically, this should happen in seven iterations.
Sending a Unique String
The faster method of identifying these four bytes is to send a unique string of 3000 bytes, identify the 4 bytes that overwrite EIP, and then locate those four bytes in our unique buffer. pattern_create.rb is a Ruby tool for creating and locating such buffers, and can be found as part of the Metasploit Framework exploit development scripts.
root@computersecurity:~# find / -name pattern_create*
root@computersecurity:~# /usr/share/metasploit-framework/tools/exploit/pattern_create.rb 3000