Fuzzing, as we discussed in the previous chapter, is a technique used to discover bugs in applications that make the application crash when presented with an input that was not anticipated by the application.

To start off this exercise, let's set up VirtualBox, and use Windows as the operating system. In the lab Windows 7 machine, let's go ahead and install vulnerable software called vulnserver. If you do a Google search for vulnserver download, you will get the link to the vulnerable server.

Let's now load the vulnserver in VirtualBox and run it as shown here:

Let's now try to connect the Linux host machine to the Windows machine to connect to the vul server.

The tool we can use for fuzzing is zzuf, which can be used with Linux-based systems. To check whether the tool is available, run the following command:

Let's see whether it crashes when we enter a long string. We can check this by passing the aaaaaa string to the code and can see that it does not break. The other way is to run the help command, where we pass the help command and return back to the Terminal, so that we can recursively do it in a loop. This is shown here:

It should be noted that if we wish to execute a command with echo, we can put that command in backticks <command> and the output of that command will be appended to the echo print string, for example: echo 'hello' `python -c 'print "a"*5'`.

We will use this technique in order to crash the target server, as the output of the command executed will be appended to the output of echo, and the output of echo goes as an input to the server through Netcat. We will execute the following code to see whether the vulnerable server crashes for a really long string:

We can clearly see that on executing the preceding command, the program prints UNKNOWN COMMAND. Basically, what's happening here is that aaaaaa is getting split across multiple lines and the input is sent to Netcat as follows: echo hello aaaaaaaaaaaaaaaaaaa | nc …. In the next line, the remaining aaaa are printed, which throws the UNKNOWN COMMAND error.

Let's try to redirect the printed output to some text file and then use zzuf with it to actually crash or fuzz the target vulnerable software.

Zzuf is a tool that takes a large string as an input, such as aaaaaaaaaaaaaaaaaaaaaaaaa. It randomly places special characters at various places in the string and produces an output such as ?aaaa@??aaaaaaaaaaa$$. We can specify as a percentage how much of the input should be modified, for example:

Let's use zzuf with the produced file, fuzz.txt, and see what the outcome is:

We can specify the percentage as follows:

Note that it is not the HELP command of the vul server that is vulnerable, it is the GMON ./:/ command. We don't want our zzuf tool to change the GMON ./:/ part of the command, so we specify -b (the bytes option) with zzuf to tell it to skip the initial 12 bytes as shown in the following screenshots:

Let's try to give this file content as an input to the vul server and see what happens:

It can be seen that the output produced by the zzuf tool crashed the vul server at the other end. Note that the special characters that the zzuf tool generates are well known attack payload characters that are commonly used for fuzzing:

We will now see how can we use a script in order to try to crash the vul server. We will also use the Olly debugger on our Windows machine in order to see where exactly the code breaks.

Start the Olly debugger as admin, as shown here:

We will now attach the running server with the Olly debugger. Go to File | Attach. This will open all the running processes. We must go to vulnserver and attach it. Once we click on Attach, we get the following:

Now, let's go back to the Linux machine and launch the script that we created:

The moment we execute the python fuzz.py command, we don't see anything on the Python console.

However, in the attached process in the Olly debugger, at the bottom right, we see a yellow message saying Paused, which means that the execution of the attached process/server is paused:

Let's click on the play button. This executes some code and pauses at another breakpoint:

It should be noted that at the bottom of the screen it says Access violation when writing to the location 017Dxxxx. This means that an exception was encountered and the program crashed: