I have been considering running a basic level of protocol fuzzing on some known/unknown services for some recent projects. These are mostly penetration tests, but with particularly locked down or limited points of entry. I look at fuzzing as a way to both demonstrate more value in the penetration test and to potentially find new holes in an environment where known vulnerabilities don’t work or don’t exist.
“Fuzz testing” or “Fuzzing” is the process of taking an expected input or output and mux’ing it up with unexpected data. It began as a software testing method, but is now commonly used to detect potential security problems. It’s easiest to understand protocol fuzzing when testing Web applications:
In a typical web application login process you submit a username and password over the network. Fuzzing this communication would likely involve replacing a normal username/password pair with random data of random (and often long) lengths, but might also involve changing other HTTP response data.
The goal is to discover checks in the services programming which don’t parse the data they receive correctly. Under typical expected conditions they work fine, but in the process of fuzzing you try and discover conditions under which they do not work fine. These can lead to the discovery of new buffer overflows, cross site scripting, and other vulnerabilities.
There are a lot of fuzzing tools and frameworks out there, most of them targeting the web application space (I’ll be dedicating a later post to these). Here are a few which can be used in arbitrary protocol fuzzing:
- ProxyFuzz – A python based proxy which will will randomly change the contents of either side of a communication stream.
- Taof – A python based GUI proxy with a somewhat easy to use interface to select which parts of a communication are fuzzed. It can also bind itself to a locally running process to better determine when a process is having issues with fuzzed data.
There are many advantages to fuzzing:
- You can discover interesting vulnerabilities without having a clear understanding of a protocol
- Fuzzing can operate at all levels of the OSI model. Most fuzzers are built at the application, network, and transport levels, but fuzzing principles can work on any level.
- Applicable to both the server and client ends of a protocol.
- Many of the vulnerabilities discovered through fuzzing are buffer overflows and can lead to the execution of arbitrary machine code.
And several disadvantages:
- If you don’t have much knowledge of the protocol structure, it becomes a more or less a brute-force approach.
- Encrypted protocols are difficult to fuzz. Most fuzzer’s operate as intermediary or proxy applications and would need to either decrypt communications on the fly or have the client program’s cooperation in mux’ing the traffic.
- As an automated method of attack, there is often a lot of work involved in finding out what exactly went wrong when an anomaly is detected and how to exploit it in a controlled manner.
Fuzzing is a big topic and an area I’ll be exploring more later.
Tags: fuzzing, penetration test