Home > CAPEC List > CAPEC-215: Fuzzing for application mapping (Version 3.9)

CAPEC-215: Fuzzing for application mapping

Attack Pattern ID: 215
Abstraction: Detailed
View customized information:
Description
An attacker sends random, malformed, or otherwise unexpected messages to a target application and observes the application's log or error messages returned. The attacker does not initially know how a target will respond to individual messages but by attempting a large number of message variants they may find a variant that trigger's desired behavior. In this attack, the purpose of the fuzzing is to observe the application's log and error messages, although fuzzing a target can also sometimes cause the target to enter an unstable state, causing a crash.
Extended Description

By observing logs and error messages, the attacker can learn details about the configuration of the target application and might be able to cause the target to disclose sensitive information. In applications that return a stack trace along with the error, this can enumerate the chain of methods that led up to the point where the error was encountered. This can not only reveal the names of the methods (some of which may have known weaknesses) but possibly also the location of class files and libraries as well as parameter values. In some cases, the stack trace might even disclose sensitive configuration or user information.

Likelihood Of Attack

High

Typical Severity

Low

Relationships
Section HelpThis table shows the other attack patterns and high level categories that are related to this attack pattern. These relationships are defined as ChildOf and ParentOf, and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as CanFollow, PeerOf, and CanAlsoBe are defined to show similar attack patterns that the user may want to explore.
NatureTypeIDName
ChildOfMeta Attack PatternMeta Attack Pattern - A meta level attack pattern in CAPEC is a decidedly abstract characterization of a specific methodology or technique used in an attack. A meta attack pattern is often void of a specific technology or implementation and is meant to provide an understanding of a high level approach. A meta level attack pattern is a generalization of related group of standard level attack patterns. Meta level attack patterns are particularly useful for architecture and design level threat modeling exercises.28Fuzzing
ChildOfStandard Attack PatternStandard Attack Pattern - A standard level attack pattern in CAPEC is focused on a specific methodology or technique used in an attack. It is often seen as a singular piece of a fully executed attack. A standard attack pattern is meant to provide sufficient details to understand the specific technique and how it attempts to accomplish a desired goal. A standard level attack pattern is a specific type of a more abstract meta level attack pattern.54Query System for Information
Section HelpThis table shows the views that this attack pattern belongs to and top level categories within that view.
Execution Flow
Explore

  1. Observe communication and inputs: The fuzzing adversary observes the target system looking for inputs and communications between modules, subsystems, or systems.

    Techniques
    Network sniffing. Using a network sniffer such as wireshark, the adversary 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 adversary observes the system calls and API calls that are made by the target system, and the nature of their parameters.
    Observe inputs using web inspection tools (OWASP's WebScarab, Paros, TamperData, TamperIE, etc.)
Experiment

  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.

    Techniques
    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).
    Attempt arguments to system calls or APIs. The variations include payloads that, if they were successful, could lead to a compromise on the system.

  2. Observe the outcome: Observe the outputs to the inputs fed into the system by fuzzers and see if there are any log or error messages that might provide information to map the application

Exploit

  1. Craft exploit payloads: An adversary usually needs to modify the fuzzing parameters according to the observed error messages to get the desired sensitive information for the application. To defeat correlation, the adversary may try changing the origin IP addresses or client browser identification strings or start a new session from where they left off in obfuscating the attack.

    Techniques
    Modify the parameters in the fuzzing tool according to the observed error messages. Repeat with enough parameters until the application has been sufficiently mapped.
    If the application rejects the large amount of fuzzing messages from the same host machine, the adversary needs to hide the attacks by changing the IP addresses or other credentials.
Prerequisites
The target application must fail to sanitize incoming messages adequately before processing.
Skills Required
[Level: Medium]
Although fuzzing parameters is not difficult, and often possible with automated fuzzing tools, interpreting the error conditions and modifying the parameters so as to move further in the process of mapping the application requires detailed knowledge of target platform, the languages and packages used as well as software design.
Resources Required
Fuzzing tools, which automatically generate and send message variants, are necessary for this attack. The attacker must have sufficient access to send messages to the target. The attacker must also have the ability to observe the target application's log and/or error messages in order to collect information about the target.
Consequences
Section HelpThis table specifies different individual consequences associated with the attack pattern. The Scope identifies the security property that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in their attack. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a pattern will be used to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
ScopeImpactLikelihood
Confidentiality
Other
Mitigations
Design: Construct a 'code book' for error messages. When using a code book, application error messages aren't generated in string or stack trace form, but are catalogued and replaced with a unique (often integer-based) value 'coding' for the error. Such a technique will require helpdesk and hosting personnel to use a 'code book' or similar mapping to decode application errors/logs in order to respond to them normally.
Design: wrap application functionality (preferably through the underlying framework) in an output encoding scheme that obscures or cleanses error messages to prevent such attacks. Such a technique is often used in conjunction with the above 'code book' suggestion.
Implementation: Obfuscate server fields of HTTP response.
Implementation: Hide inner ordering of HTTP response header.
Implementation: Customizing HTTP error codes such as 404 or 500.
Implementation: Hide HTTP response header software information filed.
Implementation: Hide cookie's software information filed.
Implementation: Obfuscate database type in Database API's error message.
Example Instances

The following code generates an error message that leaks the full pathname of the configuration file.

$ConfigDir = "/home/myprog/config";
$uname = GetUserInput("username");
ExitError("Bad hacker!") if ($uname !~ /^\w+$/);
$file = "$ConfigDir/$uname.txt";
if (! (-e $file)) { ExitError("Error: $file does not exist"); }
...

If this code is running on a server, such as a web application, then the person making the request should not know what the full pathname of the configuration directory is. By submitting a username that does not produce a $file that exists, an attacker could get this pathname. It could then be used to exploit path traversal or symbolic link following problems that may exist elsewhere in the application.

In languages that utilize stack traces, revealing them can give adversaries information that allows them to map functions and file locations for an application. The following Java method prints out a stack trace that exposes the application to this attack pattern.

public void httpGet(HttpServletRequest request, HttpServletResponse response) {
try {
processRequest();
} catch (Exception ex) {
ex.printStackTrace(response.getWriter());
return;
}
}

If this code is running on a server, such as a web application, then the adversary could cause the exception to be printed through fuzzing.

Content History
Submissions
Submission DateSubmitterOrganization
2014年06月23日
(Version 2.6)
CAPEC Content TeamThe MITRE Corporation
Modifications
Modification DateModifierOrganization
2018年07月31日
(Version 2.12)
CAPEC Content TeamThe MITRE Corporation
Updated References
2020年07月30日
(Version 3.3)
CAPEC Content TeamThe MITRE Corporation
Updated Execution_Flow
2020年12月17日
(Version 3.4)
CAPEC Content TeamThe MITRE Corporation
Updated @Name, Description, Example_Instances, Execution_Flow, Related_Attack_Patterns, Related_Weaknesses
2021年06月24日
(Version 3.5)
CAPEC Content TeamThe MITRE Corporation
Updated Related_Weaknesses
2021年10月21日
(Version 3.6)
CAPEC Content TeamThe MITRE Corporation
Updated Execution_Flow
2022年02月22日
(Version 3.7)
CAPEC Content TeamThe MITRE Corporation
Updated Description, Extended_Description
2022年09月29日
(Version 3.8)
CAPEC Content TeamThe MITRE Corporation
Updated Example_Instances
Previous Entry Names
Change DatePrevious Entry Name
2020年12月17日
(Version 3.4)
Fuzzing and observing application log data/errors for application mapping
More information is available — Please select a different filter.
Page Last Updated or Reviewed: December 17, 2020

Use of the Common Attack Pattern Enumeration and Classification (CAPEC), and the associated references from this website are subject to the Terms of Use. Copyright © 2007–2025, The MITRE Corporation. CAPEC and the CAPEC logo are trademarks of The MITRE Corporation.

AltStyle によって変換されたページ (->オリジナル) /