CAPEC-28 - Fuzzing

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 occurred. Fuzzing treats the system as a black box 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.

Severity

Likelihood

Confidentiality

Integrity

Availability

  • Attack Methods 3
  • Analysis
  • Injection
  • Brute Force
  • Purposes 1
  • Reconnaissance
  • Scopes 5
  • Modify memory
  • Integrity
  • Unexpected State
  • Availability
  • Read application data
  • Confidentiality
  • Gain privileges / assume identity
  • Authorization
  • Access_Control
  • Confidentiality
  • Alter execution logic
  • Availability
  • Integrity
  • Confidentiality

Low level: There is a wide variety of fuzzing tools available.

Fuzzing tools.

Step 1 - Observe communication and inputs

The fuzzing attacker observes the target system looking for inputs and communications between modules, subsystems, or systems..

Tecnique ID: 1 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

Network sniffing. Using a network sniffer such as wireshark, the attacker observes communications into and out of the target system.

Tecnique ID: 2 - Environment(s) env-Local env-Embedded

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.

Tecnique ID: 3 - Environment(s) env-Web

Observe inputs using web inspection tools (OWASP's WebScarab, Paros, TamperData, TamperIE, etc.)

Security Control ID: 1

Type: 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.

Security Control ID: 2

Type: Preventative

Some production hardware (for embedded environments) can have debugging disabled on the hardware.

Security Control ID: 3

Type: Preventative

Techniques exist to insert no-ops and other null branches that thwart basic attempts to execute software stepwise in a debugger.


Outcome ID: 1

Type: Success

The attacker creates a list of unique communications packets, messages, inputs, API calls or other actions the software takes.



Step 1 - 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..

Tecnique ID: 1 - Environment(s) env-All

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).

Tecnique ID: 2 - Environment(s) env-Local env-Embedded

Attempt arguments to system calls or APIs. The variations include payloads that, if they were successful, could lead to a compromise on the system.

Security Control ID: 1

Type: Detective

Log unexpected parameters to API calls or system calls.

Security Control ID: 2

Type: Preventative

Profile the software's expected use of system calls. Use a sandboxing technique to restrict its API calls to the expected patterns.

Security Control ID: 3

Type: 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..


Step 2 - 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..


Step 1 - 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..

Tecnique ID: 1 - Environment(s) env-All

Identify and embed shell code for the target system.

Tecnique ID: 2 - Environment(s) env-Web env-CommProtocol env-Peer2Peer env-ClientServer

Embed higher level attack commands in the payload. (e.g., SQL, PHP, server-side includes, etc.)

Tecnique ID: 3 - Environment(s) env-All

Induce denial of service by exploiting resource leaks or bad error handling.

Security Control ID: 1

Type: Detective

Monitor system logs and alert on unusual activity. Most shell code and unusual activity appears in logs.



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.