Protocol Fuzzing With the Mu-4000

I recently had a demonstration of the Mu-4000 Service Analyzer by Mu Dynamics. This device provides the type of security testing capabilities difficult to duplicate with any other single product (hardware or software). The Mu-4000 is an appliance that integrates the testing capabilities and methodologies of a Spirent or Ixia solution with the fuzzing, vulnerability testing and DoS capabilities typically only found in specialized software applications. I will focus on the Mu-4000’s protocol fuzzing capabilities, since this is the most interesting to me.

The Mu-4000 supports over 50 protocols including the basic ones you would expect (HTTP, FTP, SSH), but more interesting and less well known ones as well (SIP, VRRP, DHCPv6). For any protocol, the Mu-4000 can attack a device with thousands and even millions of different mutations in a effort to find weaknesses in the protocol’s implementation on the targeted device. Let’s take a look at HTTP as it is fairly simple and familiar to most.

The goal of any protocol fuzzer is to examine how a device responds to unexpected input. As we all know, the bad guys do not always play by the rules and will take advantage of any weakness they can find in a system. And many times these weaknesses are the result of incorrect error handling of unexpected inputs. This is why fuzzing is useful to a security practitioner. It helps you find those weaknesses before the bad guys do.

A typical HTTP client request looks something like below:

GET / HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/
jpeg, image/pjpeg, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE
5.01; Windows NT)
Connection: Keep-Alive

The Mu-4000 will send many different mutations for each variable in the protocol transaction in an effort to deliberately break the device. Frequently, these mutations violate the protocol by sending more data than is allowed or sending a different type of data than is allowed. If the protocol calls for a 8 bits, the Mu will send 9 to see how the device responds. Occasionally, this type of protocol fuzzing will uncover an error in the way the device handles anomalous input and this is the value that this type of testing brings to the table. By finding the weakness before the system is put into production, you eliminate the need to fix it after the system is put into production when it is much more costly to do so. And additionally, you make the system more resistant to those with malicious intent.

Comments are closed.