| Name |
Fuzzing for application mapping |
|
| Likelyhood of attack |
Typical severity |
| High |
Low |
|
| Summary |
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. 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. |
| Prerequisites |
The target application must fail to sanitize incoming messages adequately before processing. |
| Execution Flow |
| Step |
Phase |
Description |
Techniques |
| 1 |
Explore |
[Probing] The attacker uses fuzzing tools to send random malformed messages to an application and observes for log or error messages. |
- The attacker uses fuzzing tools to send random malformed messages to an application and observes for log or error messages.
|
| 2 |
Experiment |
[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 they 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.
|
|
| Solutions | 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. |
| Related Weaknesses |
|
CWE ID
|
Description
|
| CWE-209 |
Generation of Error Message Containing Sensitive Information |
| CWE-388 |
7PK - Errors |
| CWE-532 |
Insertion of Sensitive Information into Log File |
|
| Related CAPECS |
|
CAPEC ID
|
Description
|
| CAPEC-28 |
In this attack pattern, the adversary leverages fuzzing to try to identify weaknesses in the system. Fuzzing is a software security and functionality 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. Fuzzing can help an attacker discover certain assumptions made about user input in the system. Fuzzing gives an attacker a quick way of potentially uncovering some of these assumptions despite not necessarily 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 their goals. |
| CAPEC-54 |
An adversary, aware of an application's location (and possibly authorized to use the application), probes an application's structure and evaluates its robustness by submitting requests and examining responses. Often, this is accomplished by sending variants of expected queries in the hope that these modified queries might return information beyond what the expected set of queries would provide. |
|