In this tutorial, we will be targeting vulnerable software called “vulnserver.” It is a Windows-based threaded TCP server application designed for exploitation purposes. This product is intended for the most part as a tool for learning how to discover and use buffer overflow bugs. Each of the flaws it contains is inconspicuously unique concerning the others, requiring somewhat different methods to deal with when writing the exploit. To download this software, visit the following web page: “http://www.thegreycorner.com/2010/12/introducing-vulnserver.html“. From the bottom of the page, click on the “vulnserver.zip” file.
Navigate to the “Downloads” folder and extract the Zip file. Locate the “vulnserver.exe” executable and run it as administrator.
The “vulnserver” will start the active session and wait for incoming connections.
Another essential tool that we need to download is called “Immunity Debugger.” It is a straightforward application worth having when you need to write exploits, analyze malware, and reverse engineer Win32 binaries.
The software comes with an intuitive graphical interface and with a command-line, as well. To download Immunity Debugger, visit the “https://www.immunityinc.com/products/debugger/” website and click on the “Download Immunity Debugger Here!” link.
Once you install the software, run it as administrator.
From the Immunity Debugger main window, click on the “File” tab and select the “Attach” option.
A small window will pop up asking you to select a specific process that you want to inspect. From that window, find the “vulnserver” process and click on the “Attach” button.
It will embed the running process of the vulnerable software into the debugger interface. To start running the debugger, click on the play button.
Spike is a part of the Kali distribution. It is a program that sends created packages to an application to make it crash. Spike can send both TCP and UDP packages, and with the assistance of Spike, we can find vulnerabilities in applications. In this part, we will demonstrate the usage of Spike against “vulnserver.”
Start “vulnserver” on Windows machine, and On Kali Linux, connect to “vulnserver” with “netcat.” By default, “vulnserver” runs on port 9999.
Ex: (root@kali:~# nc -nv 10.10.10.4 9999).
Then type “HELP” to list the available commands.
To send TCP packages, we use the “generic_send_tcp” command. The proper form to use this command is as follows: (generic_send_tcp <IP address> <port number> <spike_script> <SKIPVAR> <SKIPSTR>).
Ex: (root@kali:~# generic_send_tcp).
In the event that the template contains more than one variable, we can test each one if we specify different values for “SKIPVAR.” In our case, this is always zero. Spike sends packages with alternating strings in place of variables. We can begin from a specific point in the test if we indicate a value for “SKIPSTR.” If the value is zero, then Spike starts from the beginning.
Spike scripts portray the package configurations of the communication. So we can tell Spike, which parameters should test first. We need to check every command in the “vulnserver” to see whether we can crash it or not.
For instance, the following template will try to send the “STATS” command with various parameters.
Open up the text editor and type the following lines to test the “STATS” command and save it as a “stats.spk” file.
Now we are ready to send our first packages with Spike. While our debugger is running, type the following command with the spike script we created to test the “STATS” parameter.
Ex: (root@kali:~# generic_send_tcp 10.10.10.4 9999 stats.spk 0 0).
Watch Immunity debugger and wait until the application crashes. If within a minute or so it doesn’t crash, stop spiking the “STATS” parameter and try other commands.
For the sake of time, we have tested some of them and found that the “TRUN” parameter is vulnerable, and it crashes within seconds. Open up the text editor and type the following lines to test the “TRUN” command and save it as a “trun.spk” file.
Before we start sending packages, we have to set the environment. First, run the “vulnserver” and Immunity debugger on the Windows machine as an administrator. Then attach the “vulnserver” running process to Immunity and run the debugger.
Now we can send TCP packages to spike the “vulnserver” and make it crash.
Ex: (root@kali:~# generic_send_tcp 10.10.10.4 9999 trun.spk 0 0).
Within a few seconds, we can see that the Immunity debugger has paused, and an access violation occurred. It means that we have overwritten the “EIP,” “EBP,” and “ESP” parts of the memory and can perform any buffer overflow from now on.
The fuzzing method is very similar to spiking in the sense that we are going to be sending multiple characters at a specific command and trying to crash it. The difference is, with spiking, we were trying to do that to various parameters to find what’s vulnerable. Now that we know the “TRUN” parameter is not configured correctly, we are going to attack that command specifically.
Before we start fuzzing the “vulnserver,” we have to set the environment. First, run the “vulnserver” and Immunity debugger on the Windows machine as an administrator. Then attach the “vulnserver” running process to Immunity and run the debugger.
Run your favorite text editor and type the following lines:
— — — — — — — — — — — — — — — — — — — — — — — — — — —
import sys, socket
from time import sleep
buffer = “A” * 100
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.send((‘TRUN /.:/’ + buffer))
buffer = buffer + “A” * 100
print “Fuzzing crashed at %s bytes” % str(len(buffer))
— — — — — — — — — — — — — — — — — — — — — — — — — — —
Once you have done it, save it as “Fuzzing1.py” and change the mod to an executable.
Ex: (root@kali:~# chmod +x Fuzzing1.py).
So, we are telling the python script to run specific modules and make a connection to our Windows machine, which is in 10.10.10.4 on port 9999. Then we will send a vulnerable “TRUN” command appending 100 “A” characters to it, and this will continue doing it until it crashes.
Let’s run our python script and monitor the Immunity debugger.
Ex: (root@kali:~# ./Fuzzing1.py).
Once it crashes, terminate the script and note the approximate bytes size where it crashed. In our example, it happened at 2200 bytes.