Fuzz testing or fuzzing is a software testing technique, which consists of finding
implementation bugs using random data injection. Fuzz scripts generate malformed data and pass it to the particular target entity to verify its overflow capacity. Metasploit provides several fuzzing modules that can be helpful in exploit development. Let us explore more about the basics of fuzzing and how Metasploit modules can be used as potential fuzzers.
Getting ready
Before we jump to the Metasploit fuzzer modules, let us have a brief overview of fuzzing and its types.
Fuzzing is treated as a black-box testing technique, where we test for the maximum overflow capacity of the software. Fuzzing is actively used to find bugs in applications.
Fuzzers can be used to test software, protocols, and file formats. Fuzzers automate the process of data generation and injection. We can control the size of the data or the packet to be injected.
A fuzzer would try combinations of attacks on:
f Numbers (for example, signed/unsigned integers, floats, and so on)
f Chars (URLs and command-line inputs)
Depending on the type of application or protocol that we are targeting, we can set up our fuzzer to generate data/packets to test its overflow. Metasploit contains several fuzzer modules that can be used to test the applications and protocols against black-box testing.
These modules can be located at modules/auxiliary/fuzzers. Let us analyze the implementation of these modules.
How to do it...
Let us experiment with a protocol-based fuzzer module. Metasploit has an FTP module named client_ftp.rb, which acts as an FTP server and sends responses to the FTP client:
msf > use auxiliary/fuzzers/ftp/client_ftp msf auxiliary(client_ftp) > show options
Module options:
Name Current Setting Required Description ---- ---- ---
CYCLIC true yes Use Cyclic pattern instead..
ENDSIZE 200000 yes Max Fuzzing string size.
ERROR false yes Reply with error codes only EXTRALINE true yes Add extra CRLF's in..
FUZZCMDS LIST.. yes Comma separated list..
RESET true yes Reset fuzzing values after..
SRVHOST 0.0.0.0 yes The local host to listen on.
SRVPORT 21 yes The local port to listen on.
SSL false no Negotiate SSL for incoming..
SSLVersion SSL3 no Specify the version of SSL..
STARTSIZE 1000 yes Fuzzing string startsize.
STEPSIZE 1000 yes Increment fuzzing string..
How it works...
Fuzzers create different test cases according to the application we want to fuzz. In our example, the FTP server can be fuzzed by sending random data packets and then analyzing their response. The data packets can fuzz the following attributes over a network:
f Packet header: Fuzzers can insert random data packets of arbitrary length and value
f Packet checksum: The checksum values can be manipulated under specific conditions using fuzzers.
f Packet size: Data packets of arbitrary length can also be sent to the network application in order to determine a crash.
Once a crash or overflow has been reported, the fuzzer can return its test case to provide the overflow data.
As you can see there are many interesting parameters available to us. Let us find out what functionality each parameter holds:
f CYCLIC : This option is used to set up a cyclic pattern as fuzz data. This is done to determine offsets as every fourth byte of string is unique. If it is set to false, then the fuzzer will use a string of A's as the fuzz data.
f ENDSIZE: This option defines the maximum length of fuzz data to send back to the FTP client. By default, it is set as 20,000 bytes.
f ERROR: This option, if set to true, will reply to the FTP client using error codes.
f EXTRALINE: This option is a fuzz test for directory listing. Some FTP clients can crash if a very large directory name request is sent to the client.
f FUZZCMDS: This option allows us to define which response needs to be fuzzed.
The possible requests are LIST, NLST, LS, RETR. We can also set* to fuzz all commands.
f SRVHOST: This option is the IP address where the fuzzer will bind with the FTP server.
For a local machine, we can use 0.0.0.0.
f SRVPORT: This option is the FTP server port, which is 21, by default.
f STARTSIZE: This option is used to define the initial data length of the fuzz data.
f STEPSIZE: This option is used to define the increment each time the overflow fails.
One should be careful when working with fuzzers. If the right parameter values are not passed, then fuzz testing might fail. You can always refer to the module source code to understand the fuzzer deeply. Let us run our FTP client fuzzer and see what output is returned:
msf auxiliary(client_ftp) > run
[*] Server started.
[*] Client connected : 192.168.56.102 [*] - Set up active data port 20
[*] Sending response for 'WELCOME' command, arg [*] Sending response for 'USER' command, arg test
[*] Sending response for 'PASS' command, arg test [*] - Set up active data port 16011
[*] Sending response for 'PORT' command, arg 192,168,0,188,62,139 [*] Handling NLST command
[*] - Establishing active data connection [*] - Data connection set up
[*] * Fuzzing response for LIST, payload length 1000 [*] (i) Setting next payload size to 2000
[*] - Sending directory list via data connection
The output has several things to note. First of all, the FTP server is started on the attacking machine. Then, it connects back with the FTP client. Next, it starts sending different response commands to the client machine. The fuzzing process starts with the NLST command. Then, it moves on to LIST, and so on.
This was a small demonstration of how fuzzer modules work. In the next recipe, we will take a deeper look into protocol fuzzing by building our own fuzzing module.