Often, as part of the exploit development process, we will want to test an application for vulnerabilities, especially buffer overflows. One of the ways we can do that is to send random, varying length, invalid data at the application and see what happens. If we can get the application to crash, this often is a sign of a vulnerability that we can then develop an exploit for later.
The process of sending this random, varying length, invalid data is known as “fuzzing”. There are numerous fuzzers on the market, some good, some bad, some ineffective and some effective. Just like exploit development, there is an ongoing war between security and hackers and this war includes fuzzers. Once a fuzzer is effective at finding vulnerabilities, the software developers adapt and close those types of vulnerabilities. Then, the fuzzers must adapt with a new type of data to attempt to exploit the vulnerabilities. Fuzzers that are easily adaptable and customizable then are highly desirable.
Spike is a fuzzer that, despite being poorly documented and less than intuitive, has proven to be adaptable. In fact, adaptability is Spike’s strongest suit. Spike is an API that enables the hacker/security researcher to quickly develop protocol stress tests. Since many protocols are built around similar data primitives, Spike enables us to create those primitives and then vary them in ways that will hopefully crash the protocol or application.
Spike is built into Kali Linux, so there is no need to download any new applications or files. Its goals are to make it easy for us to quickly and easily reproduce a binary protocol and “mess” with it. It also was developed to create a base of knowledge about different bug classes that affect similar protocols. Finally, it can also be used to test old vulnerabilities in new programs and applications.
Step #1 Download and Install vulnserver.exe
In this lesson, we will use Spike to attempt to crash a vulnerable server to demonstrate its use. We will need our Kali Linux machine, but also a Windows system with vulnserver. You can download and obtain vulnerserver at:
http://sites.google.com/site/lupingreycorner/vulnserver.zip.
When you have downloaded and extracted it, simply click on the executable vulnserver.exe or type vulnserver.exe in the command prompt. When you do, it will start vulnserver as shown below. By default, vulnserver listens on port 9999, but this can be changed by simply typing the port you want it to listen on after the executable such as;
c:\vulnserver.exe 888
Now that we have the vulnerable server up and running on our Windows box, let’s try connecting to it via netcat.
kali > nc 192.168.181.129 9999
As you can see, vulnserver displays its welcome banner and tells us to type HELP if we need help. When we do so, we get a list of commands like in the screenshot below.
Step #2 Fuzzing with Spike
Spike enables us write “scripts” that can be used to test various protocols and applications. These scripts are referred to as “Spikes” and these script files are usually appended with a .spk. To find some of the ready made Spikes, simply type;
kali > locate .spk
This will locate all the files that end with .spk as seen in the screenshot below.
These “spikes” are in directories based upon the protocol that they can be used to test. They are in /usr/share/spike/audits directory. Let’s navigate there and take a look.
As you can see, there are ready built “spikes” to test;
(1) Compaq
(2) MS Exchange2k
(3) Oracle
(4) Microsoft’s SQL Server
(5) POP3
(6) SMTP
(7) FTP
and many others. Each of these directories contains numerous scripts that we can use to test that particular protocol.
Since we will be fuzzing a server, we probably want to test or fuzz with TCP based applications. Spike has built in a TCP script interpreter generic_send_tcp and generic_send_udp. Each of these is capable of sending data via that particular protocol to a particular IP address and port. They are located at /usr/bin , meaning that we can run them from any directory in Kali as /usr/bin is in our PATH variable.
Let’s try typing generic_send_tcp to see whether we can get a help screen.
kali >generic_send_tcp
When we run it, it comes back with some very basic help on how to use it. Notice that we need to follow the command with the target host and port, then the spike script and then SKIPVAR and SKIPSTR. So a sample command might look like this;
kali > ./generic_send_tcp 192.168. 1.101 80 somespikescript.spk somevariable somestring
I think all of the parameters are relatively self-explanatory, except the last two. The SKIPVAR and SKIPSTR allow us to move into the middle of a fuzzing session defined by the Spike script. In our case here, we will be using 0 and 0 for these variables as we will be starting each script from the start.
Let’s first try using one of these already built scripts against our vulnserver. Let’s try using the SMTP scripts against our server and see whether we get it to crash.
We can run the SMTP audit against our vulnserver by typing;
kali > generic_send_tcp 192.168.181.129 9999 usr/share/spike/audits/SMTP/smtp1.spk 0 0
As you can see above, this starts Spike sending random sized inputs to the SMTP server testing whether this protocol can maintain operation with these inputs. If we go back to the Windows system running vulnserver we can see that it has survived our onslaught of random data!
Although the server has withstood this onslaught, there are many more spikes we can throw at it in an attempt to get it to fail. In a real world scenario, we would likely try ALL of these pre-built spikes before moving on to the next step of building a custom spike script.
Step #3 Creating our own fuzzing script in Spike
Now, let’s try creating our own Spike script to test the TRUN command supported by our vulnerable server (when we connected to the server via netcat, it had displayed its valid commands after typing HELP). Let’s open any text editor to create our script. I will be using Leafpad from Kali, but you can use any text editor that you feel comfortable with. They will all work.
We are creating a short three (3) line script that;
(1) reads the banner that the server sends;
(2) simulates that the user put TRUN in a shell as their command; and
(3) randomizes the user input sent with the TRUN command.
Please see the script below with the respective commands to do each of these things. Basically, we are simply reading in the banner from the server, then running the command TRUN with randomized input to test whether we can crash the server with the this unexpected and invalid input.
After completing the Spike script, save it as spiketrunaudit.spk in the /usr/share/spike/audits directory (actually, the name of the file and the directory can be whatever pleases you, but to make your first Spike script easier to do, you are recommended to simply follow my instructions verbatim).
Once we completed and saved the script, let’s now run it against our vulnerable server.
kali > generic_send_tcp 192.168.181.129 9999 /usr/share/spike/audits/spiketrunaudit.spk 0 0
Where:
192.168.181.129 is the target IP
9999 is the target port number
/usr/share/spike/audit/spiketrunaudit.spk is the absolute path to our script
0 is the SPKVAR value
0 is the SPKSTR value
When hit Enter, Spike will begin to send this data at our vulnerable server as seen below. Eventually, we see the following message “Couldn’t tcp connect to target”. Something has obviously gone wrong!
Let’s go back to our Windows 7 system running our vulnerable server. As you can see below, our vulnerable server has stopped running. Our fuzzing has crashed the server and that is why we received the message on Kali that it could no longer connect.
Conclusion
Spike is framework for creating fuzzing scripts that gives it flexibility and adaptability. Some standard fuzzing scripts are included in the default installation that we can test for known vulnerabilities in some common protocols. The real strength of Spike, though, is its ability to generate custom scripts that can be used against various protocols in order test whether we can get a variable to overflow or fail. In this way, we would then have a fundamental clue as to the vulnerability of the protocol/application after which we can work to develop an exploit to use this vulnerability. In another lesson, we will examine this vulnerability and try to decipher what it tells us about how to construct an exploit for it.
