Tuesday, June 7, 2011

The 3 phases of fuzzing

This post is going to be the first of a few discussing the art and science of fuzzing.

Sooner or later we all fuzz something. When we do it is important to us (or at least to me) to spend time wisely to maximize results with a minimal effort. Some people think that only fuzzing dumbly and quickly is the way to go, while others think that only smart fuzzing will bring results against targets that had any prior fuzzing done on. I think both are wrong. For those that support dumb fuzzing I will point out MS SAGE work that found a ton of stuff after they ran dumb fuzzing on their applications. For those supporting only smart fuzzing I'd point the Adobe 1-byte bug found by a dumb fuzzer not too long ago.

So, here is my take on the question of dumb, smart or in-between fuzzing:
  1. In every project we should start with dumb fuzzing - making sure we don't miss the obvious by making our fuzzer too smart. This should happen in day one, as soon as we have a minimal understanding of the project we should write some dumb fuzzer and start running it - this is CPU cycles well spent. Usually we'll find something this way. We must also keep adjusting our
  2. As we go on we start gaining a more in-depth understanding of the project we're working on. This is the time to start developing a smarter fuzzer. It is important to start from a slightly "dumb" smart fuzzer. Meaning one that has a minimal knowledge of the protocol or implementation details. We should have some hints on how to focus this fuzzer from our initial dumb fuzzer and what we found (or didn't find) there.
  3. Finally it's time to bring out the big guns - we must build our "ultra smart" fuzzer. This one should be an evolution of the initial slightly "dumb" smart fuzzer we wrote. It should be based on our findings during the project - from fuzzing an other stuff we did. 

    Well, that was my general view on fuzzing. Next post or posts will discuss why I'm tired of !exploitable or the question of monitoring while fuzzing and share a small tool / python code I'm working on whose purpose to make a "somewhat context aware" fuzzer for context free grammars. The final aim of this tool is to be able to fuzz stuff immediately from the BNF description found in many RFCs.

    -- Gal

    BlackHat USA & Defcon 19

    It's been a while since I last wrote something here. I've been busy with work and working on conference stuff. I've been accepted to give a workshop on DBI in BlackHat and Defcon (my workshop is not listed yet on Defcon website) in August.

    This means a lot of work making the workshop and preparing to talk. Couple it with being busy at work and having to go on reserve duty in the IDF for two weeks starting next week and you will understand why I barely have time to write something. Anyways I've decided to post some thoughts and incomplete works here soon so it doesn't get boring so stay tuned.

    Since I'm giving a workshop on DBI I'm now looking for all works published to review the existing art known in the market and probably reference. If you have anything you did, read or know of that uses DBI for security - using PIN or any other DBI engine - please share those with me here or on Twitter  you are also welcome to send me an email (if you can't figure out an address, you probably shouldn't reach me by email).

    -- Gal