Fuzzing is a software testing method that feeds randomly constructed input
to the system and looks for an indication that a failure in response to that
input has occured. Fuzzing treats the system as a blackbox and is totally
free from any preconceptions or assumptions about the system.
An attacker can leverage fuzzing to try to identify weaknesses in the
system. For instance fuzzing can help an attacker discover certain
assumptions made in the system about user input. Fuzzing gives an attacker a
quick way of potentially uncovering some of these assumptions without really
knowing anything about the internals of the system. These assumptions can
then be turned against the system by specially crafting user input that may
allow an attacker to achieve his goals.
Attack Execution Flow
Explore
Observe communication and
inputs:
The fuzzing attacker observes the target system
looking for inputs and communications between
modules, subsystems, or systems.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Network sniffing. Using a network sniffer
such as wireshark, the attacker observes
communications into and out of the target
system.
Monitor API execution. Using a tool such as
ktrace, strace, APISpy, or another debugging tool,
the attacker observes the system calls and API
calls that are made by the target system, and the
nature of their parameters.
env-Local env-Embedded
3
Observe inputs using web inspection tools
(OWASP's WebScarab, Paros, TamperData, TamperIE,
etc.)
env-Web
Outcomes
ID
Type
Outcome Description
1
Success
The attacker creates a list of
unique communications packets, messages, inputs,
API calls or other actions the software
takes.
Security Controls
ID
Type
Security Control Description
1
Detective
Alert on promiscuous
mode. Some network devices (switches, hubs) or
monitoring stations (e.g., IDS) can detect and
alert when a station in the network is passively
eavesdropping.
2
Preventative
Some production
hardware (for embedded environments) can have
debugging disabled on the
hardware.
3
Preventative
Techniques exist to
insert no-ops and other null branches that thwart
basic attempts to execute software stepwise in a
debugger.
Experiment
Generate fuzzed
inputs:
Given a fuzzing tool, a target input or protocol,
and limits on time, complexity, and input variety,
generate a list of inputs to try. Although fuzzing
is random, it is not exhaustive. Parameters like
length, composition, and how many variations to try
are important to get the most cost-effective impact
from the fuzzer.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Boundary cases. Generate fuzz inputs that
attack boundary cases of protocol fields, inputs,
or other communications limits. Examples include
0xff and 0x00 for single-byte inputs. In binary
situations, approach each bit of an individual
field with on and off (e.g., 0x80).
env-All
2
Attempt arguments to system calls or APIs.
The variations include payloads that, if they were
successful, could lead to a compromise on the
system.
env-Local env-Embedded
Security Controls
ID
Type
Security Control Description
1
Detective
Log unexpected
parameters to API calls or system
calls.
2
Preventative
Profile the software's
expected use of system calls. Use a sandboxing
technique to restrict its API calls to the
expected patterns.
3
Preventative
SSL or other
link-layer encryption techniques (VPN, 802.11x,
etc.) can impair simple observation and require a
would-be attacker to work much harder to get
information about the operation of the
software..
Observe the outcome:
Observe the outputs to the inputs fed into the
system by fuzzers and see if anything interesting
happens. If failure occurs, determine why that
happened. Figure out the underlying assumption that
was invalidated by the input.
Indicators
ID
Type
Indicator Description
Environments
1
Positive
The software produces an indicator that the
attacker can see (error message, altered error
state in a protocol, etc.).
env-All
2
Positive
The previous step led to plausible,
practical fuzz inputs.
env-All
Outcomes
ID
Type
Outcome Description
1
Success
If the software's indicators
(error messages, etc.) vary clearly based on the
attacker's input, then the attacker has a
sufficient starting point for customizing his
attack.
2
Failure
The attacker is unable to
induce unexpected failures or output based fuzzed
inputs.
Exploit
Craft exploit
payloads:
Put specially crafted input into the system that
leverages the weakness identified through fuzzing
and allows to achieve the goals of the attacker.
Fuzzers often reveal ways to slip through the input
validation filters and introduce unwanted data into
the system.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Identify and embed shellcode for the target
system.
env-All
2
Embed higher level attack commands in the
payload. (e.g., SQL, PHP, server-side includes,
etc.)
Induce denial of service by exploiting
resource leaks or bad error handling.
env-All
Security Controls
ID
Type
Security Control Description
1
Detective
Monitor system logs
and alert on unusual activity. Most shellcode and
unusual activity appears in
logs.
Typical Likelihood of Exploit
Likelihood: High
Methods of Attack
Analysis
Injection
Brute Force
Examples-Instances
Description
A fuzz test reveals that when data length for a particular field
exceeds certain length, the input validation filter fails and lets the
user data in unfiltered. This provides an attacker with an injection
vector to deliver the malicious payload into the system.
Attacker Skills or Knowledge Required
Skill or Knowledge Level: Low
There is a wide variety of fuzzing tools available.
Resources Required
Fuzzing tools.
Indicators-Warnings of Attack
Description
A lot of invalid data is fed to the system. Data that cannot have been
generated through a legitimate transaction/request. Data is coming into
the system within a short period of time and potentially from the same
IP.
Obfuscation Techniques
Description
Take pauses between fuzzing attempts (may not be very practical).
Spoof IP addresses so that it does not look like all data is coming from
the same source.
Solutions and Mitigations
Test to ensure that the software behaves as per specification and that
there are no unintended side effects. Ensure that no assumptions about the
validity of data are made.
Use fuzz testing during the software QA process to uncover any surprises,
uncover any assumptions or unexpected behavior.
Description
