Deep Diving into Buffer Overflows
The plain and simple definition of a buffer is space or a memory location to store a set of characters. Since this is a logical space inside the physical memory, when it is not sanitized appropriately, experienced programmers can easily tweak the code to overflow these memory locations.
Consider the below diagram.
In the above tabular diagram, what we can see is the array of type character is defined and considering this program doesn’t sanitize any input, hence it can overflow if more data is pushed into the array which is outside the capacity of the defined array size.
When this happens it will first fill the character array and then will overwrite the saved pointer and return address as shown below.
The above representation shows a simple concept of how a buffer overflows and what goes into memory once the buffer space overflows.
Buffer Overflows & Vulnerability Triggering
A buffer overflow is basically a type of vulnerability. When any buffer overflow is detected it means that there is vulnerability triggered which could lead to the compromise of the application in which the vulnerability is triggered.
Question: But the question is how to trigger this buffer overflow vulnerability?
Now, the above question gives the direction to another important concept in the field of hacking or cyber security.
Answer: Fuzzing is the common practice used to discover buffer overflow vulnerabilities in the software code or simply in any application.
What is Fuzzing?
Fuzzing is basically a logical way in which security researchers test the possibility of discovering weaknesses in any application. In this method, security researchers send malformed data in an automated manner to find bugs in software or you can say the bugs in the software code.
Buffer overflow vulnerability is among those vulnerabilities that are discovered by means of fuzzing logic. There are other ways of discovering buffer overflows but the most commonly used method is fuzzing.
Since fuzzing is an automated mode of discovering and testing for buffer overflows you need a tool to perform this activity.
Fuzzers
Fuzzers are basically security testing tools that perform the task of fuzzing that we explained above. Fuzzers perform fuzzing and there are different types of fuzzers available on the internet for your quick usage.
You can find fuzzers available in Metasploit framework for fuzzing FTP servers or you can write your own code if you are a good programmer
Exercise 1 – Hacking Ability FTP Server 2.34
We will present a live demonstration on the Ability Server version 2.34 running on Windows XP Machine in a virtual environment.
● Tools Required: Metasploit
● Application: Ability Server 2.34
● Debugger: Immunity Debugger
● Method of Testing: Automated Fuzzing
This server is running in our lab environment and now we will start the fuzzing process in order to find out if there are any buffer overflows that exist in this simply coded server.
To achieve this, we logged into Kali Linux and used Metasploit FTP pre-post fuzzer to discover any available vulnerability. This is how to fuzz any FTP Server and discover underlined vulnerability if exists.
Your vulnerability FTP server should be running as shown above, then go to Metasploit and run the auxiliary FTP pre-post scanner. Below is the complete scanner configuration.
What will happen?
Basically, this fuzzer will start sending crafted packets to cause this application to behave abnormally by sending sequential patterns of data. First it will try to fuzz the login and password commands, which is pre fuzzing, and if this fuzzer can not generate any errors or find any bug, the post fuzzing will start.
Below you can see the fuzzer in action without using any post commands.
To see what is happening in the background we have attached the Ability Server with Immunity debugger and you can notice that so far nothing is discovered as the server is running normally and nothing abnormal has happened.
Our fuzzer reaches a stage where it starts fuzzing the different FTP commands and below is the stage where it was fuzzing the ALLO command. However, nothing has happened yet that can give us confidence that this server has buffer overflows. It might not have any buffer overflows, however, we are just fuzzing and researching if we can at least generate any errors.
Our fuzzer is configured to test the following commands as shown below in the figure.
It will take a while to complete the fuzzing phase on this server as we have comprehensive list of commands that has to be tested in order to complete the fuzzing phase.
In the background, this fuzzer is basically trying to overflow the buffer while sending these commands one by one. If any command that is coded in this FTP server doesn’t care for input validation then we will see a server crash or any errors generated. However, we are not aware of the outcome and we are just busy fuzzing this server. How stupid this looks! Hey, it is not and that’s how researchers spend tons of time discovering any security holes in the applications and we only see the outcome as zero-day.
One thing I forgot to mention is that we haven’t configured a pre-configured user and password as post authentication fuzzing requires authentication session. I realized this when our fuzzer completed fuzzing and no successful outcome was achieved. Hence I have created a normal user and password as “ftp” and re-ran the fuzzing to see the results. Now, we see that when our fuzzer reached a certain command, the server crashes as shown below.
You can notice that the fuzzer stops responding as it is not receiving any communication from the server, which is obvious as you can see that the server is crashed and the EIP register value is changed.
What we have achieved?
We have successfully fuzzed the Ability FTP Server and were able to crash the application at a certain point with our FTP server fuzzing tool available in the Metasploit Framework.
What does this mean?
This is a sign that there is a buffer overflow vulnerability somewhere when our fuzzer sends the data of size 1000 in a cyclic pattern and with the APPE command after successfully authenticating itself with pre-configured user.
What’s Next?
Okay, we now understand that the buffer overflow vulnerability is detected in this Ability FTP Server. However, all the fuzzing logic was performed by the Metasploit Framework Pre-Post Auxiliary Fuzzing Module and we have simply configured the module as per our need and executed the fuzz on the FTP server. This is automation, now its time for some manual play.
Information in Hand
We know that buffer overflow exists and where this could be successfully exploited (in an authenticated session) by exploiting one of the FTP commands.
We now need to control the flow and write our small piece of code to test this manually. We will use python scripting to connect to this FTP server and then we will send an evil buffer to again crash the application and see the results in the Immunity Debugger.
Exercise 2 – Coding working exploit
Proof of Concept
Below is our proof of concept code with which we are just testing the discovered buffer overflow vulnerability.
In the above PoC we are sending “evilbuffer” which is nothing but 2500 “A” right after sending the “APPE” command. Let’s test and see the results in Immunity Debugger.
We have sent the bulk of “A” after the APPE command as shown in above figure and you can notice that the server has crashed and the EIP register is overwritten with our 2500 “A”s we sent as evil buffer.
Seems good so far, at least we have Denial of Service attack exploit ready with us as you can see that above PoC code can easily crash the service. However, we are not controlling the Ability FTP Server as per our requirements.
Now it’s time to add some fun into our PoC code - let’s do something funny rather than simply crashing the application.
We are quickly moving towards coding a working exploit. Meanwhile, we are explaining what is happening in the background. We will explain the core concepts thoroughly at a later stage, here we want to present the sequence of how to discover buffer overflow vulnerabilities and then write a working exploit for the discovered vulnerability.
Working Exploit
Now, what is required to write a working exploit for this discovered vulnerability?
There are two main requirements for completing a working exploit for this vulnerability.
- Shell Code
- Controlling EIP
Shell code can easily be found on the internet and you can also generate shell code by using Metasploit. Controlling the EIP is bit more difficult, however, we will let you know the steps that you can follow in order to control the EIP.
Fun Begins Here!
As you have noticed, the EIP value was “41414141” when we crashed the application by sending 2500 “A”s. This means that out of 2500 “A”s, four of them got written into EIP but we don’t know which ones they were among the 2500, which is quite a big size. So what we want to know is after how many bytes the EIP got overwritten by our evil buffer.
To achieve this we need to send a set pattern as an evil buffer of an equal size and then we will see what is written into EIP.
Once we know what is written into EIP then we will find the location of those four bytes contained in our evil buffer. For this to be achieved we will again use two scripts available in Metasploit Framework as follows:
Now, we will send these patterns of 2500 bytes in length as shown in below PoC.
Now, notice the change in EIP Value after crashing the application with above PoC Code.
We will now take the value of EIP register which is “33674232” and use Metasploit script to find the exact number of bytes after which EIP value is overwritten; this is called offset value as shown below in the figure.
Okay, offset is discovered as 968 bytes, which means exactly after 968 bytes of overflow EIP will be overwritten. Now we will send 968 bytes of raw data, which would be “A” s, and then we will send 4 “B”s, which in total makes 972 bytes.
Buffer overflow would go like this in sequential order.
So we have now following PoC code based on above logic.
We have added couple of NOPS (no operations before writing ESP) just to clear any garbage values. Shell code is basically what we are writing into ESP where we will be storing our shell code. Now we will run this PoC exploit code and see if the values we are sending are actually reflecting in memory to see control over application as shown below.
You can see EIP value as 42424242 which are four Bs and exactly what we have written into EIP; after that you can notice 20 nops which are actually 909090 values in memory and you can count as they are exactly 20 in count as we sent and after that you can see values as 43434343 and that is what we sent into ESP.
So here we can confirm that we are controlling the application flow and buffer overflow is successfully exploited but we haven’t sent any shell code and this is the point where the fun actually begins, as we don’t want to simply write raw data into the memory. We want some action to happen, like opening a command shell on this remote machine.
Now for us to achieve this we need to do things as follows:
- Shell code written in python as we are coding in python
- ESP address location
- How much space we can have in memory to store our shell code
Getting shell code written in python is as easy as eating a burger but finding a memory location is not that easy. No, it’s not.
Now, we need a shell code here, which you can get via Google or generate by using Metasploit; however, if you cannot we will cover it in coming modules. Below is a shell code generated by Metasploit module in python for opening up a CMD shell connection on port 9988.
Select user32.dll and find instruction JMP ESP as shown below; we have used the following location for our shell code to store and then saved it in the EIP register.
JMP ESP location “7E429353” and to save it in memory you need to use the format as shown below in our PoC Code.
Once we exploited, Ability Server was happily running and no crash happened but you can notice that our exploit is waiting for Ability Server to respond and this is because our shell code binds a CMD connection via port 9988 and is still in memory. So let’s check the victim machine for open ports and then connect to the machine via our shell code. The below figure shows open and listening ports on the victim machine and I have highlighted the port 9988 waiting for connection, which means our exploit works and we have successfully opened a backdoor to get into system via Windows command prompt.
Lets try connecting to this victim machine on port 9988.
Here you get the backdoor access into the Windows machine by exploiting the buffer overflow vulnerability, which we discovered in the beginning of this module. You can play with the commands shell and do whatever you can via a local command prompt access as you got the admin access.
This is the live learning session of how you can detect buffer overflows and then write your own exploit to get into the remote system via a backdoor access. In the next module we will be learning egg hunters.