../vulnserver1-fuzzing

Vulnserver: Setting up and fuzzing

This is going to be the first post in a series on exploiting Vulnserver, here we will talk about what software do we need to get started and later we will find some crashes in Vulnserver by using a fuzzer.

Setting up

The different software we will need in this journey is the following:

We can obtain Vulnserver from Github in the link above and run it in our Windows VM. To do so we just need to have the executable provided in the same folder as the dll and double click it.

Immunity Debugger is going to be our debugger in Windows to analyze the crashes and we will use the mona.py plugin developed by Corelan to help us in the process of exploitation, both can be obtained from the links above.

And we can obtain Spike from the repositories provided by Kali by simple running a apt install spike in the terminal.

Initial reconnaissance

Before we can start fuzzing we need some information on how our victim expects to receive the data. So first of all let's run Vulnserver and try to communicate with it, once we have it running we can test it by connecting to it using netcat from our Kali VM. We just need to provide it the ip of our Windows VM and the default port is going to be 9999.

As you can see in my case the ip of the Windows VM is 192.168.1.46, once connected we are greeted with a welcome message. If we run the HELP command indicated we obtain all the possible commands accepted and if we give it an invalid command we are just answered with UNKNOWN COMMAND. Now that we've gathered enough information on it we can start the fuzzing process.

Fuzzing Vulnserver

As I said we are going to use Spike to fuzz the victim but I lied about Spike being a fuzzer it is actually a fuzzer creatin kit so we will need to do some simple coding to start fuzzing. If you want to learn a bit more about Spike Infosecinstitue has a good introduction on it in this link.

To create our fuzzer we will have to write a .spk file, which are called spikes, for each command. In it we basically will tell Spike to read the welcome message and then send one of the valid commands we saw earlier followed by some random data generated by the fuzzer. In the following code we can see an example of the file to fuzz the TRUN command and we will create similar files for each command.

s_readline(); // Read the welcome message
s_string("TRUN "); // Send command followed by a space
s_string_variable("ANYTHING CAN GO HERE"); // Send random data generated by the fuzzer

The string in s_string_variable() is the one that's going to change every execution in hopes of finding a crash. To test our spike we are going to use the tool provided by Spike called generic_send_tcp, to run it we have to provide it with an ip address, a port, the spike file we created and follow it with two 0s separated by a space. Now, make sure you have Vulnserver running on your Windows VM and let's run the fuzzer.

We can see how it seems to be sending different data and after a while it stops receiving the welcome message from Vulnserver. If we look at vulnserver we will be greeted with this lovely message.

This is really nice since it means that we found a string that caused a crash but we have no clue what string it was so we can not reproduce it. To be able to obtain said string we have different methods, in my case, I'm going to run Vulnserver with Immunity Debugger to be able to check the state once the program crashes but you can also use Wireshark to analyze the packets send. We execute Immunity Debugger and open Vulnserver by pressing F3 and selecting it, we press F9 to continue execution, since it starts on a paussed state, and now we can fuzz it again and check the status once it crashes.

In the screenshots we can see how the program crashed when trying to executed the instruction in the adress 41414141, which is A in hexadecimal, meaning we overwrote EIP with As. And if we look at the Registers window we can see how EAX is pointing at an ASCII string which is the command that caused the crash.

So we found our crash for the TRUN command, if we repeat the fuzzing steps for each command we are going to find crashes for the following commands:

In the next posts we are going to talk about different ways to exploit each of them and we will see how each one needs a different approach.

Goodbye!