Taof is a Python generic network protocol fuzzing framework. It has been designed for minimizing set-up time during fuzzing sessions and employs graphical user interface to make it intuitive and easy. Even though it is a generic protocol framework, it is not designed as a library and no programming skills are necessary. It is especially useful for fast testing of proprietary, undocumented or unknown network protocols.

Data retrieval

Taof aids the user by automatically retrieving the data by a man-in-the-middle approach. Man-in-the-middle is a scenario in which an attacker can eavesdrop on the traffic between two parties without either of the parties knowing that the traffic has been intercepted. In addition this attack also allows the attacker to modify, inject and delete traffic, but that does not apply here. In this scenario the fuzzer transparently forwards requests from the client to the server and replies from the server to the client. During that process, the fuzzer logs the requests for later use.

The figure above represents the data retrieval process using a man-in-the-middle approach. This technique eliminates the need of sniffing network traffic for later inclusion in the code. This represents an important achievement over current fuzzing approaches, not only because it speeds up the setup process, but also because it greatly simplifies it. In order to forward the connections the fuzzer needs to know the remote location, IP and port, where the requests are going to be forwarded.

Figure 2 shows the required settings for the man-in-the-middle operation. ‘Local settings’ is the IP address and port where the fuzzer waits for requests from the client. The client should be pointed to that location. ‘Remote settings’ refers to the location of the real server that needs to be fuzzed.

After entering the settings information it is possible to set the fuzzer in ‘Forwarding mode’ to start learning the protocol. The following screenshot shows the main dialog for data retrieval.

After setting the forwarding values, the actual retrieval phase starts.

The log displayed in Figure 4 shows that the fuzzer is forwarding connections. This simple process is enough to log all the communications from the client to the server.

Field analysis

Having the network traffic retrieved during the previous process provides an important advantage: It can be effectively presented to the user for his analysis. The fuzzer presents, in a graphical interface, a list of requests made by the user, along with the content of each one. The researcher can then analyse the protocol. The next screenshot shows the list of requests forwarded by the fuzzer. At this point, the researcher can set up as many fuzzing points as necessary on the requests.

As many times as he wishes, the researcher can choose a request to be fuzzed. When doing this, a new window will be opened for the boundaries of the fuzzed buffer to be chosen, as shown in the next screenshot.

In this request two fuzzing points have been already set, from byte 603 to 607 and from 617 to 621. It is important to note that in this example ASCII data is presented, but the fuzzer is also capable of treating binary data. This approach eliminates the tedious tasks of analysing the protocol from a network sniffer output and inputting fuzzing points onto the fuzzer logic. The graphical interface helps the user to select the fields prone to being vulnerable, totally eliminating the need of programming during the setup process.

Fuzzing

After setting up fuzzing points, now the engine will send the requests to the server. Debugging information for further analysis is available in the working folder “debugging” file.