| Attack Pattern ID | Pattern Abstraction: Detailed 24 |
| Typical Severity | High |
| Description | Summary
In this attack, the idea is to cause an active filter to fail by causing an oversized transaction. An attacker may try to feed overly long input strings to the program in an attempt to overwhelm the filter (by causing a buffer overflow) and hoping that the filter does not fail securely (i.e. lets the user input into the system unfiltered).
Attack Execution Flow Explore Survey: The attacker surveys the target application, possibly as a valid and authenticated user |
Attack Step Techniques |
|---|
| Description | Environments |
|---|
| Spidering web sites for inputs that involve potential filtering | env-Web | | Brute force guessing of filtered inputs | env-All |
|
Indicators of Susceptibility
|
|---|
| ID | Type | Description | Environments |
|---|
| c24s1i1 | Positive | Software messages (e.g., "the following characters are not allowed...") indicate that filtered inputs are present in the software. ( | env-Web env-ClientServer | | c24s1i2 | Positive | Application uses predefined inputs (e.g., drop-down lists, radio buttons, selection lists, etc.) | env-Web env-ClientServer env-Local env-Embedded | | c24s1i3 | Negative | Managed code (e.g., .NET, Java) is likely, based on URLs. | env-Web | | c24s1i4 | Negative | Managed code (e.g., .NET, Java) is likely, based on files found in software. | env-ClientServer env-Local env-Embedded env-Peer2Peer env-CommProtocol | | c24s1i5 | Negative | Java code is likely, based on standard disclaimers (e.g., "This software contains Java from Sun...."). Such declarations are frequent on commercial software that is based on Java. | env-Embedded env-Local env-ClientServer | | c24s1i6 | Inconclusive | Java code is likely, based on one of the other indicators, but it could contain Java Native Interface (JNI) code. This is indicated by the inclusion of DLLs or equivalent binary object code with Java code. | env-Embedded env-Local env-ClientServer |
Experiment Attempt injections:
Try to feed overly long data to the system. This can be done manually or a dynamic tool (black box) can be used to automate this. An attacker can also use a custom script for that purpose.
|
Attack Step Techniques |
|---|
| Description | Environments |
|---|
| Brute force attack through black box penetration test tool. | env-Web env-ClientServer env-CommProtocol env-Peer2Peer | | Fuzzing of communications protocols | env-CommProtocol env-Peer2Peer env-ClientServer | | Manual testing of possible inputs with attack data. | env-All |
|
Outcomes |
|---|
| ID | Type | Description |
|---|
| c24s2o1 | Success | Unexpected output from the application. | | c24s2o2 | Failure | No unexpected output from the application. |
|
Security Controls |
|---|
| ID | Type | Description |
|---|
| c24s2s1 | Detective | Monitor and analyze logs for failures that exceed common usage sizes. For example, if typical transactions, even normal failed transactions, rarely exceed 250 characters, monitor logs for all attempts that contain 250 or more characters. In the event of successful exploitation, there may actually be no useful log. But an attacker's experiments will likely show up, giving clues to the ultimate attack. | | c24s2s2 | Corrective | Disconnect or block connections from systems or users that exceed acceptable heuristics for normal transaction sizes. |
Monitor responses:
Watch for any indication of failure occurring. Carefully watch to see what happened when filter failure occurred. Did the data get in?
|
Attack Step Techniques |
|---|
| Description | Environments |
|---|
| Boron tagging. Choose clear attack inputs that are easy to notice in output. In binary this is often 0xa5a5a5a5 (alternating 1s and 0s). Another obvious tag value is all zeroes, but it is not always obvious what goes wrong if the null values get into the data. | env-All | | Check Log files. An attacker with access to log files can look at the outcome of bad input. | env-Local env-Embedded |
|
Security Controls |
|---|
| ID | Type | Description |
|---|
| c24s3s1 | Preventative | Prevent access to log files that contain error output. | | c24s3s2 | Preventative | Prevent access to and/or sanitize all error output. |
Exploit Abuse the system through filter failure: An attacker writes a script to consistently induce the filter failure. |
Attack Step Techniques |
|---|
| Description | Environments |
|---|
| DoS through filter failure. The attacker causes the system to crash or stay down because of its failure to filter properly. | env-All | | Malicious code execution. An attacker introduces a malicious payload and executes arbitrary code on the target system. | env-All | | An attacker can use the filter failure to introduce malicious data into the system and leverage a subsequent SQL injection, Cross Site Scripting, Command Injection or similar weakness if it exists. | env-All |
|
Indicators of Susceptibility
|
|---|
| ID | Type | Description | Environments |
|---|
| c24s4i1 | Positive | Failure mode of the software (perhaps as a safety mechanism) includes exiting or ceasing to respond. | env-All | | c24s4i2 | Negative | Failures do not involve stopping services, rejecting inputs or connections, and do not affect other simultaneous users of the software. | env-All |
|
Outcomes |
|---|
| ID | Type | Description |
|---|
| c24s4o1 | Success | Attacker-supplied code is executed on the target system. | | c24s4o2 | Success | The software stops responding for at least two orders of magnitude longer than the input takes to send. (e.g., 0.1s to send input induces at least a 10 second period non-responsiveness). | | c24s4o3 | Success | Non-response by an attacker's input has an impact on the quality of service of other simultaneous users of the software. |
|
Security Controls |
|---|
| ID | Type | Description |
|---|
| c24s4s1 | Detective | Monitor software response time regularly, and react to unexpected variations. | | c24s4s2 | Preventative | Execute filtering modules with minimal privileges. | | c24s4s3 | Preventative | Execute filtering modules in operating system "sandboxes" or similar containers. |
|
| Attack Prerequisites | Ability to control the length of data passed to an active filter. |
| Typical Likelihood of Exploit |
High
|
| Methods of Attack | |
| Examples-Instances | Description Attack Example: Filter Failure in Taylor UUCP Daemon
Sending in arguments that are too long to cause the filter to fail open is one instantiation of the filter failure attack. The Taylor UUCP daemon is designed to remove hostile arguments before they can be executed. If the arguments are too long, however, the daemon fails to remove them. This leaves the door open for attack. Description A filter is used by a web application to filter out characters that may allow the input to jump from the data plane to the control plane when data is used in a SQL statement (chaining this attack with the SQL injection attack). Leveraging a buffer overflow the attacker makes the filter fail insecurely and the tainted data is permitted to enter unfiltered into the system, subsequently causing a SQL injection. Description
Audit Truncation and Filters with Buffer Overflow. Sometimes very large transactions can be used to destroy a log file or cause partial logging failures. In this kind of attack, log processing code might be examining a transaction in real-time processing, but the oversized transaction causes a logic branch or an exception of some kind that is trapped. In other words, the transaction is still executed, but the logging or filtering mechanism still fails. This has two consequences, the first being that you can run transactions that are not logged in any way (or perhaps the log entry is completely corrupted). The second consequence is that you might slip through an active filter that otherwise would stop your attack.
|
| Attacker Skill or Knowledge Required | Low : An attacker can simply overflow a buffer by inserting a long string into an attacker-modifiable injection vector. The result can be a DoS.
High : Exploiting a buffer overflow to inject malicious code into the stack of a software system or even the heap can require a higher skill level.
|
| Resources Required | |
| Probing Techniques |
Try to feed very long data as input to the program and watch for any indication that a failure has occurred. Then see if input has been admitted into the system.
Some dynamic analysis tools may be helpful here to determine whether failure can be induced by feeding overly long inputs strings into the system.
|
| Indicators-Warnings of Attack |
Many exceptions are thrown by the application's filter modules in a short period of time. Check the logs. See if the probes are coming from the same IP address.
|
| Obfuscation Techniques |
An attacker may temporally space out their probes.
An attacker may perform probes from different IP addresses.
|
| Solutions and Mitigations |
Make sure that ANY failure occurring in the filtering or input validation routine is properly handled and that offending input is NOT allowed to go through. Basically make sure that the vault is closed when failure occurs.
Pre-design: Use a language or compiler that performs automatic bounds checking.
Pre-design through Build: Compiler-based canary mechanisms such as StackGuard, ProPolice and the Microsoft Visual Studio /GS flag. Unless this provides automatic bounds checking, it is not a complete solution.
Operational: Use OS-level preventative functionality. Not a complete solution.
Design: Use an abstraction library to abstract away risky APIs. Not a complete solution.
|
| Attack Motivation-Consequences | - Run Arbitrary Code
- Privilege Escalation
- Denial of Service
|
| Context Description | |
| Injection Vector | Web form, URL, File, Command line, Network socket, etc.
|
| Payload | All of the data that just got into the system unfiltered becomes the payload. |
| Activation Zone |
Since the input enters the system effectively unfiltered, it may be dangerous if used in a SQL statement (i.e. SQL injection), as part of the command executed on the target system (i.e. command injection), as part of the reflection API (i.e. reflection injection), placed in logs (i.e. log injection), or perhaps to overflow another buffer in the system and give the attacker ability to execute arbitrary code. A subsequent buffer overflow may not even be required for that as the original one may be leveraged if the attacker gets lucky, that is the payload is activated in the filter itself, which also becomes the activation zone.
|
| Payload Activation Impact |
Since no input validation is effectively performed in this situation, the impact of the attack may be a complete compromise of confidentiality, integrity, accountability and availability services.
|
| Related Weaknesses | | CWE-ID | Weakness Name | Weakness Relationship Type |
|---|
| 120 | Unbounded Transfer ('Classic Buffer Overflow') | Targeted | | 119 | Failure to Constrain Operations within the Bounds of an Allocated Memory Buffer | Targeted | | 118 | Range Errors | Targeted | | 74 | Failure to Sanitize Data into a Different Plane (aka 'Injection') | Targeted | | 20 | Insufficient Input Validation | Targeted |
|
| Related Attack Patterns | | ID | Name | Relationship Type | Relationship Description |
|---|
| 100 | Overflow Buffers | Occasionally Follows | |
|
| Relevant Security Requirements |
Input validation and filtering logic should fail securely (vault doors are closed)
|
| Related Security Principles | |
| Related Guidelines | - All input should be treated as rejected by default, unless explicitly allowed by the filter. Thus if the filter fails before "blessing" the data, it will be rejected.
|
| Purpose | Penetration |
| CIA Impact | | Confidentiality Impact | Integrity Impact | Availability Impact |
|---|
| Medium | High | Medium |
|
| Technical Context | | Architectural Paradigm | Framework | Platform | Language |
|---|
| All | All | All | All |
|
| References | G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. CWE – Buffer Errors |
| Source | | Submission(s) |
|---|
| Submitter | Organization | Date | Comment |
|---|
| G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. | Cigital, Inc | 2007-03-01 | |
| Modification(s) |
|---|
| Modifier | Organization | Date | Comment |
|---|
| Eugene Lebanidze | Cigital, Inc | 2007-02-26 | Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software" | | Sean Barnum | Cigital, Inc | 2007-03-05 | Review and revise | | Paco Hope | Cigital, Inc. | 2007-10-20 | Added extended Attack Execution Flow |
|
