This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Fuzzing"

From OWASP
Jump to: navigation, search
(Fuzzing tools (mostly open sourced))
(Fuzzing tools (mostly open sourced))
Line 79: Line 79:
 
[http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]
 
[http://www.hacksafe.com.au/blog/2006/08/21/fuzz-testing-tools-and-techniques/]
  
A generic parser: could be quite a good starting point [http://www.hachoir.org]
+
Hachoir, a generic parser: could be quite a good starting point [http://www.hachoir.org]
  
 
== Commercial products ==
 
== Commercial products ==
  
 
Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]
 
Codenomicon's product suite: [http://www.codenomicon.com/products/all.shtml]

Revision as of 17:23, 11 December 2006

Fuzz testing or Fuzzing is a software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection: it's a type of Black Box Testing, which means testing a closed system on the comportemental point of view.

A trivial example:

Lets's say there's a integer variable in a program, which results of a user's choice between 3 questions. When the user picks one choice, the choice will be transmitted to the program under a variable, say 0, 1 or 2. Which makes 3 practical cases. But what if we transmit 3, or 255 ? We can, because integers are stored in values which allow them to take a lot of cases (often more than necessary).

If the programmer was lazy, he may have taken no/less attention to the default switch case.

If so, the program may crash, which leads to "classical" security issues: (un)exploitable buffer overflows, simple DoS, ...

In these perspectives, Fuzzing is the "art" of automatically finding this type of implementation failures, eventually being able to measure the found vulnerability dangerosity, and of course locate it (in order to exploit it).

Fuzzer implementations

A fuzzer is a program which will inject semi-random data into a program/stack and detect problems.

The data-generation part is made of generators, and the error detection relies on debugging tools.

A quite "efficient" fuzzer is:

- protocol/file-format dependant

- data-type dependant

Why? Because a program only understands structured-enough data. If you connect to a web server in a raw way, it will only respond to listed commands such as GET (or eventually crash). If you try totally random inputs, it will in most cases respond with a "non-implemented method" error.

Take a 10 chars long string, supposed to fuzz a webserver: we generate all the possible strings doable within this string. It makes a lot of possibilities, right? What are the odds that you find the ones that start with "GET " ?

That's why a fuzzer has to understand at least the basics of a protocol / file format.

About explorable solutions space: comparison with Cryptanalysis

The number of possible tryable solutions is the explorable solutions space.

The aim of Cryptanalysis is to reduce this so called space, which means finding a way of having less keys to try than pure bruteforce to decrypt something.

In this regard, Fuzzers try to reduce the number of unuseful tests: the values we already know that here's little chance they'll work.

There's a big difference with Crypto though: the more "intelligent" your fuzzer is, the less weird errors it will find: you reduce impredictibility, in favor of speed. That's a compromise.

Attack types

A fuzzer would try combinations of attacks on:

- numbers (signed/unsigned integers/float...)

- metadata : text-valuable information (mostly text)

- the protocol/file format itself (field size attacks...)

A quick way (and common approach) to fuzzing is, for each types of data defined here, to define lists of "known-to-be-dangerous values" (fuzz vectors), and to inject them in place of the classical values, see [1] for real-life examples.

Protocols and file formats imply norms, which are sometimes blurry, very complicated or badly implemented : that's why developers sometimes mess up in the implementation process (because of time/cost constraints).

Take a norm, look at all mandatory features and constraints, and try all of them: forbidden/reserved values, linked parameters, field sizes (a lot of implementations are said not to verify field sizes). That would be hand-fuzzing.

Fuzzers limitations

Fuzzers usually tend to try one-level-imbrication-level attacks, which means changing only one parameter at a time. A highly intelligent fuzzer would detect/know linked parameters, and play on them.

Fuzzing tools can detect trivial errors quite easily, but are less gifted with complex ones (in terms of imbrication level).

Technical resources on OWASP

Fuzzing vectors [2]

Sources

Wikipedia article [3]

Fuzzing-related papers [4]

Fuzzing tools (mostly open sourced)

The ultimate fuzzers list @ infosec [5]

Another list @ hacksafe [6]

Hachoir, a generic parser: could be quite a good starting point [7]

Commercial products

Codenomicon's product suite: [8]