Probing an Application Through Targeting its Error Reporting
Attack Pattern ID: 54 (Standard Attack Pattern Completeness: Complete)Typical Severity: LowStatus: Draft
+ Description


An Attacker, aware of an application's location (and possibly authorized to use the application) can probe the application's structure and evaluate its robustness by probing its error conditions (not unlike one would during a 'fuzz' test, but more purposefully here) in order to support attacks such as blind SQL injection, or for the more general task of mapping the application to mount another subsequent attack.

Attack Execution Flow

  1. Determine user-controllable parameters of the application

  2. SecurityDatabase\Alert\Inject each parameter with content that causes an error condition to manifest

  3. Modify the content of each parameter aaccording to observed error conditions

  4. Repeat above steps with enough parameters until the application has been sufficiently mapped out to launch desired attack (for example, Blind SQL Injection)

+ Attack Prerequisites

This class of attacks does not strictly require authorized access to the application. As Attackers use this attack process to classify, map, and identify vulnerable aspects of an application, it simply requires hypotheses to be verified, interaction with the application, and time to conduct trial-and-error activities.

+ Typical Likelihood of Exploit

Likelihood: High

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


Blind SQL injection is an example of this technique, applied to successful exploit.

Related Vulnerabilities



Attacker sends bad data at various servlets in a J2EE system, records returned exception stack traces, and maps application functionality.

In addition, this technique allows attackers to correlate those servlets used with the underlying open source packages (and potentially version numbers) that provide them.

+ Attacker Skills or Knowledge Required

Skill or Knowledge Level: Medium

Although fuzzing parameters is not difficult, and often possible with automated fuzzers, 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

The Attacker needs the ability to probe application functionality and provide it erroneous directives or data without triggering intrusion detection schemes or making enough of an impact on application logging that steps are taken against the attacker.

The Attack does not need special hardware, software, skills, or access.

+ Indicators-Warnings of Attack

Repeated errors generated by the same piece of code are an indication, although it requires careful monitoring of the application and its associated error logs, if any.

+ Obfuscation Techniques

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; any technique aimed at defeating the use of certain identification parameters for correlation goes a small way in obfuscating the attack.

+ Solutions and Mitigations

Application designers can 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 cataloged 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.

Application designers can wrap application functionality (preferrably 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.

+ Attack Motivation-Consequences
  • Information Leakage
+ Injection Vector

User-controllable input

+ Payload

Content, 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, hopefully for the attacker, reveals sufficient information to further map the application.

+ Related Weaknesses
CWE-IDWeakness NameWeakness Relationship Type
209Information Exposure Through an Error MessageTargeted
248Uncaught ExceptionSecondary
717OWASP Top Ten 2007 Category A6 - Information Leakage and Improper Error HandlingTargeted
+ Related Attack Patterns
NatureTypeIDNameDescriptionView(s) this relationship pertains toView\(s\)
ChildOfAttack PatternAttack Pattern116Data Excavation Attacks 
Mechanism of Attack (primary)1000
ChildOfCategoryCategory210Abuse of Functionality 
Mechanism of Attack (primary)1000
ParentOfAttack PatternAttack Pattern214Fuzzing for garnering J2EE/.NET-based stack traces, for application mapping 
Mechanism of Attack (primary)1000
ParentOfAttack PatternAttack Pattern215Fuzzing and observing application log data/errors for application mapping 
Mechanism of Attack (primary)1000
+ Relevant Security Requirements

Custom error pages must be used to handle exceptions such that they do not reveal any information about the architecture of the application or the database.

Employ application-level safeguards to filter data and handle exceptions gracefully.

+ Related Security Principles
  • Failing Securely

  • Defense in Depth

+ Related Guidelines
  • Never Use Input as Part of a Directive to any Internal Component

  • Handle All Errors Safely

+ Purposes
  • Reconnaissance
+ CIA Impact
Confidentiality Impact: MediumIntegrity Impact: MediumAvailability Impact: Low
+ Technical Context
Architectural Paradigms
+ References

CWE - Input Validation

CWE - Improper Error Handling

+ Content History
John StevenCigital, Inc2007-02-10Initial core pattern content
Chiradeep B. ChhayaCigital, Inc2007-02-23Fleshed out pattern with extra content