Skip Links

Protocol Fuzzing

By JimmyRay on Thu, 04/09/09 - 5:21pm.

I was conducting a hacking 101 security training session at a users group meeting about a month ago. After some Newcastle and Pizza (mando requirement) I had went over a common character overflow limit on a Solaris box I discovered a while back when a skinny dude (for Wisconsin) stood up and said, "How did you figure that out?" I told him that I fuzzed it. At that point, the entire talk shifted from running canned exploits to finding your own via fuzzing. I loved it! A 90 minute presentation went on for over three hours. A new group of Fuzz Warriors were forged that cold day in the tundra of Wisconsin.

Fuzzing is the core of most 0day exploits. Not too many folks actually open up a process and then hit 128 "n's" to crash an application or bug out the stack or even go thru source code line by line (if it is available). With so many Star Trek episodes on now, who wants to do that? Most of us let software do it for us. Whether that is thru reversing binaries or fuzzing it is a way for us security type folks to check out the code at a deeper level. "NaNaNaNaNaNaNaNa Be the code" Caddy Shack one fans give me some love!

Let's lay down a little background here. Fuzzing is the art of feeding a bunch of random crap (You know kinda like the same thing many Analyst do to us only more credible/useful )to a program or protocol to crash it and analyze the results. This is why many vendors want your crash data. It is ULTRA important! A crash tells a code jockey so much about a program. It can also tell a hacker even more... By crashing a program/protocol we can find a possible bug and write a patch or exploit to take advantage of this. Like nearly everything in networking, fuzzing is broken down into specialties. When I say the word specialties I always hear Obi Won Kenobi say "Sith Lords are our speci-E-al-ity" In Star Wars III which is an excellent flick to having playing in the background while your fuzzin'

anyway...

There are Web Fuzzers, Protocol fuzzers, Embedded fuzzers, naval lint fuzzers, etc. I will be focusing on protocol fuzzing. Mainly because I write most of my code in C. Also IA32 Assembly when I need to prepare for a visit from my inlaws to get used to the monotony. Truthfully I read much more Assembly then I ever write...thank goodness. My favorite fuzzer is from Immunity and it is really more of a framework for building a custom fuzzer thru a massive API library. It is called SPIKE, its free and the tarball can be downloaded at http://www.immunityinc.com It only runs on Linux. Spike is a great program but the downside is the documentation sucks. For example, I had a few problems getting it installed but quick error search on Google brought me to Rajat Swarup's blog with the answer. http://rajatswarup.blogspot.com/2008/04/spike-fuzzer-linker-errors.html However, in Spike's defense it comes with many examples and if you are comfortable in C it's template based design really make it a snap to use. Plus Immunity really reaches out to advance the security community immensely. Don't pass up a chance to hear Dave Aitel speak.

Spike is known as a block mode fuzzer which is the best for protocols since it will treat each block of a protocol differently like headers, Checksums, etc. The trick to fuzzing is do not try and reinvent the wheel. Google out to see what other folks know about your target protocol. I always check the Wireshark dissectors directory and search for my protocol to see if a decoder exists. That will really shortcut the process by giving you a ready reference. Start out small with frames from ARP to get used to the process. Then work on your differential analysis skills by fuzzing a pre-2006 VTP frame and then a current VTP frame and look at the differences. If you ever have wanted to work in a research lab or have, then you'll know that a consistently repeatable process is a positive hit. One hit is not a positive. 100+ hits doing the same thing with other like frame samples is. The more comfortable you get in doing this, the more you will tackle more advanced protocols by just loading your frame samples from scratch.

But some protocols, well...just suck to fuzz and require different types of fuzzers when all results fail. For example, I started out trying to fuzz LLDP (Link Layer Discovery Protocol) but I had a major problem with TLV's (Type Length Variables) handling in Spike. The TLV's in LLDP are odd and my thought is there must be something I can use in there. Although I have heard that the fuzzer; Sulley http://code.google.com/p/sulley/ does a good job at it. I just have not tested Sulley yet, but many fuzzers swear by it. There is a canned LLDP fuzzer out there already with good documentation but it is old and I was just looking for some...other things that I am sure are there....

Fuzzing is a great way to get closer to the protocol by running a huge battery of test conditions against many parts of a protocol. To be honest I can not think of a single method that gives you so much valuable information Vs. the set up time quite like fuzzing. Do it once, become a believer for life. I have found many vulns in protocols just by simply loading frames into a Spike templete using s_binary and s_string and letting it run to look for that golden EIP and EBP (Instruction Pointer/Stack Pointer) to be overwrote! It honestly still gives me goosebumps and I cheer like the Colts just beat the Packers! (Hey it can happen!) To be comfortable in fuzzing you should understand C programming to know what you are looking at. I also highly recommend the book; Fuzzing by Addison Wesley Press http://www.fuzzing.org as a fantastic way to get into this awesome field of research.

Jimmy Ray Purser

Trivia File Transfer Protocol
It's possible to have $1.19 and still be unable to make change for a dollar. (50 cent piece, Quarter, x4 dimes and x4 pennies)