How to see results of protocol fuzzing

Question

Had a class today about protocol fuzzing whereby my professor explained fuzzing in a lot of detail, but neglected to explain how someone would actually measure a fuzzing process.

So how would you actually do this? Would a simple Wireshark capture showing any malformed packets be a result of a successful fuzzing attempt? I've had a look at Sulley and that needs to be installed on both machines (attacker/victim), but what options are available if you are the attacker and you want to see the results of your fuzzing session and how successful it is (i.e. where the crash happened)?

Answer 1

depending the case of fuzzing a black or a white box , but reading the code from a simple fuzzer you can easily find out how its done IMAP Fuzzer Metasploit metasploit-unleashed this example will print a line when the server stop responding , and the buffer length used by that instance, that "log" and any debugger (like ImmunityDebugger) on the "victim" machine will be enough to reproduce the crash

in case of a blackbox before try some "blind" fuzzing you should try to set up a lab trying to reproduce the "victim" scenario , remember fuzzing will crash or damage the system. if you cant reproduce the victim system i think setting a log to the sent buffer and wireshark will we ok, but should monitor the protocols timeouts and other network considerations- for more details give this gide a try fuzzing in 15 minutes

Answer 2

I am jealous that you get to have a class on fuzzing.
Ideally, you have set up your own installation of the victim software and can install tools on the victim to monitor it. If you are fuzzing a service that you don't control, then your options are more limited to variations on, as Sarastro says, "print a line when the server stops responding"

Fuzzing frameworks like Sulley have ways to define and then instrument your target to better monitor its health. So, the answer to your question will change depending on your target.

Real simple example: You are fuzzing a ftp login sequence on a remote host. You might define that no reactions from the server are expected except in response to USER and PASS, that the server respond within x seconds, that it doesn't take longer for usernames that aren't found and usernames that are found. Then you let the fuzzer rip and see if you get any unexpected responses or timeouts. Your framework would record these unexpected results and that would be your answer.

(this scenario adapted from sulley-fuzzing and sulley-101)