Home > CAPEC List > CAPEC-215: Fuzzing and observing application log data/errors for application mapping (Version 2.11)  

CAPEC-215: Fuzzing and observing application log data/errors for application mapping

Fuzzing and observing application log data/errors for application mapping
Definition in a New Window Definition in a New Window
Attack Pattern ID: 215
Abstraction: Detailed
Status: Draft
Completeness: Complete
Presentation Filter:
+ Summary

An attacker sends random, malformed, or otherwise unexpected messages to a target application and observes the application's log or error messages returned. Fuzzing techniques involve sending random or malformed messages to a target and monitoring the target's response. 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. 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.

+ Attack Steps
  1. Probing: The attacker uses fuzzing tools to send random malformed messages to web server and observes for server's log or error message.

    The attacker uses fuzzing tools to send random malformed messages to web server and observes for server's log or error message.

  1. Modify the parameters to get the desired information from the error messages.: Attacker 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 attacker may try changing the origin IP addresses or client browser identification strings or start a new session from where he left off in obfuscating the attack.

    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 attacker needs to hide the attacks by changing the IP addresses or other credentials.

+ Attack Prerequisites
  • The target application must fail to sanitize incoming messages adequately before processing.

+ Typical Severity


+ Typical Likelihood of Exploit

Likelihood: High

+ Methods of Attack
  • Analysis
  • Injection
  • Brute Force
+ Examples-Instances


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

(Bad Code)
Example Language: Perl 
$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.

+ Attacker Skills or Knowledge Required

Skill or Knowledge 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.

+ Solutions and 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.

+ Attack Motivation-Consequences
ScopeTechnical ImpactNote
"Varies by context"
Information Leakage
+ Injection Vector

User-controllable request

+ Payload

Malformed message, based on application context, crafted to elicit error conditions from the application.

+ Activation Zone

Error handling mechanism within the application.

+ Payload Activation Impact

The impact of activation is an error condition that reveals sufficient information for further application mapping to the attacker.

+ Purposes
  • Exploitation
+ CIA Impact
Confidentiality Impact: MediumIntegrity Impact: LowAvailability Impact: Low
+ Technical Context
Architectural Paradigms
+ References
[R.215.1] [REF-3] "Common Weakness Enumeration (CWE)". CWE-209: Information Exposure Through an Error Message. Draft. The MITRE Corporation. <http://cwe.mitre.org/data/definitions/209.html>.
+ Content History
CAPEC Content TeamThe MITRE Corporation2014-06-23Internal_CAPEC_Team

More information is available — Please select a different filter.
Page Last Updated or Reviewed: July 31, 2017