Attackers must be able to identify the right fuzzing parameters in any given application to find a vulnerability and then exploit it. In this section, we will look at an example of vulnerable server, which was created by Stephen Bradshaw.

This vulnerable software can be downloaded from https://github.com/PacktPublishing/Mastering-Kali-Linux-for-Advanced-Penetration-Testing-Third-Edition/blob/master/Chapter%2010/vulnserver.zip.

In this example, we will be using Windows 7 as the victim running vulnerable server.

Once the application is downloaded, we will be unzipping the file and running the server. This should open up TCP port 9999 for the remote clients to connect to. When the vulnerable server is up and running, you should be able to see the following:

Attackers can connect to the server on port 9999, using netcat to communicate to the server, as shown in the following screenshot:

Fuzzing is a technique in which attackers specifically send malformed packets to the target to generate errors in the application or create general failures. These failures create bugs in the application and find out how it can be exploited to allow remote access by running their own code. Now that the application is accessible and everything is set, attackers can now begin the art of fuzzing.

Although there are a number of fuzzing tools available, SPIKE is the default that was installed on Kali Linux version 2.0. SPIKE is a fuzzing toolkit that's used to create fuzzers by providing scripting capabilities; however, it is written in the C language. The following is a list of interpreters written in SPIKE that can be utilized:

• generic_chunked
• generic_send_tcp
• generic_send_udp
• generic_web_server_fuzz
• generic_web_server_fuzz2
• generic_listen_tcp

SPIKE allows you to add your own set of scripts without having to write a few hundred lines of code in C.

Attackers with access to the application can see multiple options available in the vulnerable server, which they can then play with. This includes STATS, RTIME, LTIME, SRUN, TRUN, GMON, GDOG, KSTET, GTER, HTER, LTER, and KSTAN as part of valid commands that take input. We will utilize the generic_send_tcp interpreter to fuzz the application. The format to use the interpreter is as follows: . /generic_send_tcp host port spike_script SKIPVAR SKIPSTR:

• host: This is the target host or IP
• port: This is the port number to be connected to
• spike_script: This is the SPIKE script to run on the interpreter
• SKIPVAR and SKIPSTR: This allows the testers to jump into the middle of the fuzzing session, as defined in the SPIKE script

Let's go ahead and create a simple SPIKE script for readline, run SRUN, and assign a string value as the parameter:

s_readline(); 
s_string("SRUN |"); 
s_string_variable("VALUE");

The preceding three lines read the first line after connecting to the IP/hostname and then run SRUN, along with a randomly generated value. Now let's save the file as exploitfuzzer.spk and run the SPIKE script against the target, as shown in the following screenshot:

Fuzzing confirmed no server crash or anything similar, so the SRUN parameter is not vulnerable. The next step is to pick another one. This time, we will pick TRUN as the parameter to fuzz:

s_readline(); 
s_string("TRUN |"); 
s_string_variable("VALUE"); 

Save the exploitfuzz.spk file and run the same command, as shown in the following screenshot:

You should now be able to see that the server crashed on the victim's PC. Windows also gives us some useful information on exception offset 41414141 that we can take note of (which is converted as AAAA), as shown in the following screenshot:

Now that we know that the vulnerable TRUN command created the crash, we must now focus on the request that caused it. This can be achieved by running Wireshark, which will provide us the exact request that caused the crash of the server:

1. Run the Wireshark with the right Ethernet adapter.
2. Repeat the exploit using the fuzzer (generic_send_tcp target port exploitfuzz.spk 0 0).
3. Filter the Wireshark with the tcp.port == 9999 filter.

4. Right-click on the packet and follow the TCP stream. You should be able to see the following:

Now let's go ahead and write a simple Python program to crash the server. This will be a simple socket program to connect to the IP and run the command with a buffer of "Z" * 10000. The following code extract provides the first step in fuzzing and debugging an application vulnerability:

import socket 
IP = raw_input("enter the IP to crash:") 
PORT = 9999 
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) 
s.connect((IP,PORT)) 
banner = s.recv(1024) 
print(banner) 
command = "TRUN " 
header = "|/.:/" 
buffer = "Z" * 10000 
s.send (command + header + buffer) 
print ("server dead")

Save the file as crash.py and run it against the target IP. You will see server dead with 10000 as the buffer. This means that having "Z" * 10000 as input crashed the server, as shown in the following screenshot:

Now, the next step is to identify exactly how many characters caused the server crash and what buffer size can be utilized. On the server side, we must debug the application. To perform the debugging, we will download the immunity debugger from https://www.immunityinc.com/products/debugger/. These debuggers are used mostly in finding exploits, analyzing malware, and reverse engineering any binary files.

Focusing on the vulnerable server, let's load vulnerableserver.exe into Immunity Debugger and run the application, as shown in the following screenshot:

The next step is to create a pattern using the MSF by locating to the /usr/share/metasploit-framework/tools/exploit/ folder and running ./pattern_create -l 4000 in the Terminal, as shown in the following screenshot:

You can either output the contents that's generated into a file or copy it from the terminal. Alternatively, you can add to your Python program by adding another variable. This time, we will disable the buffer and use the pattern that was created by exploit tool with a length of 4000:

import socket 
IP = raw_input("enter the IP to crash:") 
PORT = 9999 
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) 
s.connect((IP,PORT)) 
banner = s.recv(1024) 
print(banner) 
command = "TRUN " 
header = "|/.:/" 
#buffer = "Z" * 10000 
pattern = <value> 
s.send (command + header + pattern) 
print ("server dead") 

Again, running crash.py against the target will result in the server crashing again. However, all of the Z characters are being replaced by the pattern that was created. On the vulnerable server, we should be able to see the registers from our Immunity Debugger, which provides the next instruction that will be stored in EIP, as shown in the following screenshot:

That's the end of fuzzing. In the next section, we will focus on creating a Windows-specific exploit.