29

I've heard of these tools and from what I understand, they just send tons of random data at different services and observe their reaction to it.

What is the purpose of a fuzzer? How can it be applied during a pentest?

NlightNFotis
  • 1,130
  • 1
  • 10
  • 18
Digital fire
  • 3,126
  • 5
  • 31
  • 44

4 Answers4

36

What is the purpose of a fuzzer?

A fuzzer tries to elicit an unexpected reaction from the target software by providing input that wasn't properly planned for. It does this by throwing "creatively constructed" data as input to software. Expecting a phone number? Ha! I'm going to give you 1,024 characters of 0x00! Random hex! Unicode! A zero-width field! Just the punctuation: "()-"

The goal is to get an error response that isn't clean... extra access, a buffer overflow, etc. Improperly handled input is essentially the crux of just about every security problem, whether by extending into unwanted memory ranges or any number of other reactions. An SQL error came back from the phone number field? SQL Injection time!

So, for all that, fuzzers are useful in finding flaws, and particularly during a pentest for using those flaws as a point to try and launch exploits from.

Jeff Ferland
  • 38,090
  • 9
  • 93
  • 171
20

A fuzzer is a (semi-)automated tool that is used for finding vulnerabilities in software which may be exploitable by an attacker. The benefits include, but are not limited to:

  • Accuracy - A fuzzer will perform checks that an unaided human might miss
  • Precision - A fuzzer provides a kind of benchmark against which software can be tested
  • Speed - A fuzzer may preform many checks in a relatively short time

Positional downsides include, but are not limited to:

  • A false sense of security - Like all software, a fuzzer can/will be flawed, and will not catch every possible vulnerability
  • Obscured technical details - The automated nature of a fuzzer may discourage one from actually learning the techniques that it uses
Sean W.
  • 835
  • 4
  • 14
  • What property or result makes it useful for that? – Jeff Ferland Oct 08 '12 at 20:27
  • @JeffFerland Updated. Please reassess. – Sean W. Oct 08 '12 at 21:03
  • I disagree that the nature of fuzzing may discourage further learning. You can't really interpret fuzzer results without learning exactly how its input lead to a crash. Furthermore, you often need to become rather familiar with the codebase you are fuzzing for many targets, since they don't all accept input as a single file right at application start (e.g. fuzzing libraries, graphical applications, browsers, etc). – forest Feb 14 '18 at 07:58
8

from what I understand, they just send tons of random data at different services and observe their reaction to it

This is partly true, depending on what you mean by "random". Fuzzers can be used that way for the purpose of identifying memory leaks in a program, but they can also be useful in pen-testing (by making the program crash). If you can crash the program with a fuzzer, you can probably hijack it.

From a pen-testers perspective, fuzzers are most useful for identifying input validation errors.

Maybe it's best explained with a simple FTP fuzzer, assuming you can read source code.

A typical FTP fuzzer might try to execute various FTP commands like cd, put, etc., with "random" arguments. Often, fuzzers will bruteforce sending strings of increasing length, which could be used to identify buffer overflow errors, which may be exploitable (ASLR and other technologies mitigate this somewhat).

In this regard, a fuzzer would be most useful while running the server application in a debugger, so you can see exactly how/where it crashes. Then shellcode could be constructed to hijack the application.

Fuzzers that don't send random data are probably more useful here, e.g. sending patterns like "ABBCCCDDDD..." could be more useful in pin-pointing the exact size of the buffer needed to overflow, since they could employ something akin to a binary search for faster results.

Daniel Hanrahan
  • 181
  • 3
7

Responses from a network service should fall into one of a few well defined and broad categories. If you send random data to, for example, an HTTP service, you expect to get back a lot of HTTP 400 results and perhaps a few other HTTP 4XX results. If anything ELSE happens, such as a timeout or a different response, then that anomalous result is worth noting and investigating further afterwards.

Sparr
  • 595
  • 2
  • 6