1.0 beginning
In this article, I will talk about how to make a simple Buffer Overflow attack. Buffer Overflow is a situation that occurs when more data is loaded into the amount of memory allocated. Cyber attackers use this situation as a vulnerability and can run it by installing malicious code on systems.
Actually, this article can be considered a tutorial on how to do it. If you’re here to learn more about the environments where the Buffer Overflow attack happens, you’re in the wrong place :(
But I’m leaving a few links anyway.
- Owasp — Buffer Overflow
- WikiPedia — Buffer Overflow
- TCM — Buffer Overflows Made Easy (This video also includes everything I’ve done here)
- PwnLabMe — Buffer Overflow (TR)
I will use an attacker and a victim VM’s for this attack.
As Victim, I am using a Windows 10 Enterprise x86 architecture of course with real-time protection turned off. Because the vulnerable server we will use is blocked by defender. we don’t need so much realism today. As Attacker, I am using Kali Linux but doesn’t matter whatever you use.
Here we install vulnserver and Immunity Debugger. I leave the links.
We use the Debugger to assist in the exploit development process. We can say that Debugger acts as a proxy between Application and CPU. It allows us to stop at any time to inspect the recordings and the execution flow. You can find more debugger tools online.
If we have done all the installations and adjustments, we can start by running vulnserver.exe and debugger as Administrator.
Running vulnserver opens a terminal waiting for us for a connection. At first, I connect with netcat from my attacker machine to see what the program is doing.
nc -nv <ip addr> 9999 (server is using this port)
A terminal welcomes us where we can get various outputs with various commands. We’re skipping this for now. back to our windows machine.
1.1 fuzzing
We open the debugger and attach to examine the vulnserver from the current processes.
(If you do not run the debugger as administrator, you may not see all processes.)
When we complete all the steps, the debugger interface greets us. It is paused here, as can be seen at the bottom right. We run the program with F9 or the start button in the upper left.
now its running…
Now what we’re going to do here is, we saw that the server received some commands when we connected before. Using a spike script to find which of these commands is vulnerable. I will use “generic_send_tcp” fuzzer for this. This is the usage :
…and this is the spike script.
To put it simply, the method we will use here is to try to detect vulnerabilities by sending many iterations for the variable we give in the script. Here, the “STATS” value we give for the “s_string” variable corresponds to the commands in the server interface that we have seen before. (I found a little article about spike scripting here)
To remember:
Now that we have everything set up(also the debugger is up and we watch what happens lol), we can run it.
What we see when we run it; The server is receiving commands but nothing of interest. As we can understand from here, “STATS” does not contain any vulnerabilities.
I don’t think I need to show the other options one by one because we will get the same result.
I switch directly to vuln command.
When we run the same steps again for the “TRUN” command, the debugger seems to want to tell us something. What it’s saying here is that he found something vulnerable. Executing “41414141” as a hex value results in an Access violation.
If we do hex to ascii, the value of “41" is “A”.
Here we have succeeded in overwriting the EIP as can be seen in the screenshot.
Great, we found a door to set off.
We now know that the TRUN command is vulnerable. Here is some information we should get. this information is how many of the “A” values we send break the transaction. for this, to do a simple extraction by determining the addresses of the values we send via hexdump.
Then we determine where it starts and ends and we take note of the address values.
When we do the subtraction, we understand that the program crashes especially at 2992.
With the information we have obtained, we can now start developing our own exploit.
1.2 exploitation
Here we need a script that can generate and send data. You can find it online or write your own. Actually it doesn’t matter. I am using this.
What we are doing here is doing everything we did before with python. When we run it, we see that it crashed successfully just like we did before.
We overwrite EIP. but we don’t know which 4 chunks caused this. To detect this, instead of sending a data consisting of exactly the same values, we will send a data containing different chunks in groups of 4, so that we can determine the point we will check specifically.
I will use “msf pattern_create” to do this. All I need to do is to specify the pattern length with the “-l” parameter. It’s easier for us to detect now as it’s a pattern instead of random values or identical values.
We add the values we get to our script as bytes.
Now that we have set and saved everything, we can restart the server with CTRL + F2 over the debugger and run the script. When we run it, we see that now EIP has a different value.
We return to the terminal again and find which offset the EIP overwritten value corresponds to in the pattern we use with “msf pattern_offset”.
We give the pattern length and the EIP value we get from the debugger as a query.
and boom! we have exact match. From here on we need to improve our exploit a bit. We give “BBBB” for our new EIP value after offset 2002.
We will send 2992 characters again, but after 2002 we send a different character. so simply we will send 2992–2002 = 990 “C” characters.
We were able to fill the ESP register after the offset I wanted with the “C” value I defined.
At this point, of course, we are starting to investigate if there is a way we can add and control and maybe take a shell and control the system. Because we know that we have filled the ESP register with the characters we want and we can control it.
So, Here is the plan; getting a reverse shell by focusing on the points we can control.
We will use the JMP ESP instruction for this. this will allow us to run commands to the program. At least we hope so.
I will use mona for this. (for mona installation → click)
Below is the output we get when we run this query with mona.
What we see here is nice because we see that some addresses use ASCII values. We copy one of the addresses and assign it to the “new_eip” variable we gave for our exploit that we created earlier.
Then we determine the expression to follow.
After that, we add a breakpoint to our address.
When we set everything up and run our script again, we successfully assigned the address we wanted for the EIP register.
For now everything is fine. We just have to see if the program includes any badchar protection to prevent us from getting a reverse shell as we planned earlier.
For this, we change our script a little bit and examine the hexdump manually and see if any characters are blocked.
What we do here is send all ascii characters.
As we can see here, the characters are sent in order, let’s examine this.
right click — > follow in dump — > selection
I guess we are lucky because there is no bad char protection here.
To understand this, you can simply follow the last lines of the hex values to see if the pattern is broken.
As can be seen, the “TRUN” function running on the “vulnserver” does not use any bad character checks.
Now at this point we can create the payload to get the shell. I use “msfvenom” for this.
and add it to exploit.
We have everything set up and we can run a listener.
I run vulnserver again with debugger and then all I have to do is run exploit.py and BOOMM!
Thanks for reading… (on something i’m totally ignorant of…) (｡◕‿◕｡)
