Introduction
Welcome to part 1 of my windows exploit development series. In this post, I will go through the process of finding and exploiting a basic stack overflow in an x86 windows environment. Throughout these tutorials, you will also learn other styles of Windows exploitation.
Since there are lot of good resources out there, I skipped the theories and heading straight to practical.
I will be using vulnserver a vulnerable application specially designed for exploit development and research. You can download vulnserver from here
My goal for this series of posts is to introduce you to the basics of finding and writing buffer-overflow exploits in the Windows environment.
Tools Needed
- Immunity Debugger
- Immunity Mona Module
- Text editor
Target
Our target application is running on Windows 7 Pro SP2. Let’s scan the target IP address and find the vulnerable service.
First, let’s attach the vulnerable server application running on our target to the immunity debugger.
Go to File > Attach and Click the service name to attach.
## Fuzzing
The next step is fuzzing the vulnerable server and monitor for a crash in the Immunity debugger. To automate the fuzzing process I wrote a simple fuzzing script in python.
We can use a fuzzing framework like Sulley, SPIKE or Boofuzz for automating the fuzzing process, but for this tutorials, I will stick with a simple script.
The above code simply makes a connection to the server running on port 9999 and send a bunch of junk. This simple script triggers a vulnerability in the TRUN command of the vulnerable server running on our target.
Run the fuzzing script and monitor it from the debugger for crashes.
Great as you can see we have successfully overwritten EIP with 41414141 since “A”’s hex representation in ASCII is 0x41.
EIP is the register that holds the value of the address of the next instruction. The next step is finding the offset, the exact bytes of data it took to overwrite the return pointer.
There are many ways to find the offset, we will be using pattern_offset and pattern_create of the Metasploit framework.
Finding the offset
Let’s modify our fuzzing script to send a unique pattern created using MSF pattern_create tool and re-run the script. Please note that, before you run fuzzing script, every time you need to restart your debugger and vulnerable application, simply go to Debug from the menu and restart or Ctrl+F2.
First let’s Create pattern with metasploit pattern create tool:
Update the python script with the generated pattern.
Running the script against target:
Great as you can see ESP register is overwritten with a random string, The next step is to find the offset of the EIP register in order to gain full control of it and to obtain code execution. To find offset copy and past the value in EIP registers to MSF pattern_offset.
As we can see from the above output EIP overwrite occurred in 2006 bytes into our data.
Now let’s modify our skeleton exploit to confirm this.
We have modified our skeleton exploits to send 2006 A and then 4 B’s, if everything is working, we should see 42424242 in EIP which is 4 B’s (B * 4).
Great now it is confirmed that we have full control over the instruction pointer. The next step is executing a malicious shellcode in memory to get a reverse shell.
Analyzing Bad characters
Before we go any further, we should identify bad characters or specific characters that could break our payload and cause unintended behavior. ex: null-byte \x00
To identify the bad characters, let’s generate a byte array containing all possible characters. We will use !mona for this task.
Let’s modify our buffer once again and see what happens! so we will keep our 2006 “A”s and 4 “B”s, and then add all of our characters after that.
Once again run the exploit and monitor from debugger.
Right-click and follow the dump
Heads up there are no bad-characters in vulnserver except “\x00”, We can see every single character from “\x01” to “\xFF” in the memory dump.
I will write about how to find and deal with bad-characters in a separate post.
Jumping to the Shellcode
Why jump ESP?
JMP ESP gives a more reliable exploit than repeatedly trying to guess a return address every time. JMP ESP will make the program start executing the code that is pointed by ESP.
We need to find JMP ESP from a module without ASLR and DEP enabled and also it should not contain bad characters within the memory address.
DEP and ASLR are used to protect against buffer-overflow attacks. Bypassing these protections is out of scope for this post.
To list all modules information type the following command in immunity debugger command windows.
!mona modules
To list all executable loaded with the program, click Alt+E in the immunity debugger.
From loaded modules, we can see most of the modules Adress-Space Layout Randomization (ASLR) is enabled, except essfunc.dll which comes with our vulnerable program and it does not contain any bad characters.
We can see 9 JMP ESP pointers essecfun.dll which we can use, it doesn’t really matter which one we use since none of them have bad characters. I will select the first one 0x625011af (\xaf\x11\x50\x62) we need to write this address in reverse order due to endianness.
We can verify if this is indeed a JMP ESP by simply going to that memory address from the immunity debugger.
Intel JMP ESP has machine or opcode of ffe4. Using NASM we can determine the HEX code for JMP ESP instruction.
Generate shellcode with the following command, keeping in mind that we need to exclude the identified bad characters if there is any.
Add the generated shellcode to the script and update. This shellcode will spawn a reverse_shell back to the attacker machine.
Before firting the exploit, start netcat listener on port 443. we should get a reverse shell back from our victim machine.
Great, we successfuly exploited the bufferoverflow vulnerability in the application.
Full Exploit:
Conclusion
That’s it for Part 1 of this series. I hope you enjoyed this initial intro to exploit development. Until next time, happy hacking.
All code for this post available from my github repo https://github.com/d3b4g/WindowsExploit-dev