SEH Based Buffer overflow
First, I would like to thank one of our brightest candidate Najam Hassen for Creating the awesome POC of Minishare 1.4.1. He is a CISSP, CISM, CEH, CCSP, CPTE Certified Profesional. If you are a beginner in buffer overflow concept then it highly recommended to go back and first explore the stack-based buffer overflow series. So here are some of the details about the buffer overflow
Victim: Windows XP with Service Pack 3 (192.168.8.105)
Vuln App: MiniShare 1.4.1 running on port 80
For Debugging: Immunity Debugger Installed on Victim.
Attacking machine : Kali Linux (192.168.8.102) ( 4.15.0-kali2-amd64 #1 SMP Debian 4.15.11-1kali1 x86_64 GNU/Linux)
Through Exploit-DB, we found that the service mindshare 1.4.1 is vulnerable when sending an oversized HTTP GET request.
This can also be verified using Burpsuite as well.
Let’s try to crash the application and verify using Fuzzing python script to smashing the stack
Start the application minishare 1.4.1.exe and attach it to Immunity Debugger and press “F9” to start the application, make sure application is running and not paused.
Using below python script try to crash minishare 1.4.1,(GET request is vulnerable here as there is no input validation)
File name: 1-fuzz-minishare.py
#!/usr/bin/python import socket s=socket.socket(socket.AF_INET,socket.SOCK_STREAM) s.connect(( '192.168.8.105', 80)) buffer = "GET " buffer += "A" * 4000 buffer += " HTTP/1.1\r\n\r\n" s.send(buffer)
On Attacker Machine Lets fire the script:
Check in Immunity Debugger if the application has paused, means it has crashed.
We can see;
ESP register is having all A`s
EIP register is over written by A`s
Application status is paused (indicating application has crashed), BOF is confirmed
Note: Make sure to attach and execute minishare 1.4.1.exe on each step, this can be done in a fast manner by using option “Debug” and selecting Restart
Now we want to calculate the exact address of EIP register at crash, for that we will create a uniqu pattern of characters and send it to minishare and try to find its offset address Its important to understand below 3 concepts before we continue further.
- Why we want to calculate the exact address of EIP register ?
The CPU decides which instruction to execute next by reading the value of the EIP register and executing the instruction that is located at that memory address. we need to overwrite the EIP register with a memory location that contains a machine language instruction that will in turn point the EIP register to an area in which we can place our own code.
- Why we want to know exact location referred by ESP register ?
The exact address of the memory location that we control via the buffer that we send is not known, but we do know from checking the register values at the time of the crash that the ESP register points to a location within this buffer. Consequently, if we can redirect code execution to the memory location referred to by ESP, and if we place our own machine language instructions into the buffer location pointed to by ESP, then we will have successfully exploited the application to run our own code.
- Why JMP ESP command ?
If the EIP register contains the address 0x77daaf0a, and that memory address stores the codes \xff\xe4 (which are the machine language opcodes for the assembly instruction JMP ESP) then the CPU will execute that instruction, causing it to “jump” execution to the memory location stored in the ESP register. The value of the EIP register will then be set to the value of the ESP register, and the CPU will execute the instruction located in the memory address referenced by the ESP register.So JMP ESP command is fit for our purpose.
in short EIP (using JMP ESP command) will point to ESP, ESP will direct CPU to code location, and CPU will execute the code.
So enough theory for this Lets discuss Practical stuff in our Next Blog