CAPEC-24 - Filter Failure through Buffer Overflow

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. the user input is let into the system unfiltered).

Severity

Likelihood

Confidentiality

Integrity

Availability

  • Attack Methods 1
  • Injection
  • Purposes 1
  • Penetration
  • Sec Principles 1
  • Failing Securely
  • Scopes 4
  • Modify memory
  • Integrity
  • Execute unauthorized code or commands
  • Availability
  • Integrity
  • Confidentiality
  • Bypass protection mechanism
  • Authorization
  • Access_Control
  • Confidentiality
  • DoS: crash / exit / restart
  • Availability

Low level: 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 level: 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.

Ability to control the length of data passed to an active filter.

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.

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.

Step 1 - Survey

The attacker surveys the target application, possibly as a valid and authenticated user.

Tecnique ID: 1 - Environment(s) env-Web

Spidering web sites for inputs that involve potential filtering

Tecnique ID: 2 - Environment(s) env-All

Brute force guessing of filtered inputs

Indicator ID: 1 - Environment(s) env-Web env-ClientServer

Type: Positive

Software messages (e.g., "the following characters are not allowed...") indicate that filtered inputs are present in the software. (

Indicator ID: 2 - Environment(s) env-Web env-ClientServer env-Local env-Embedded

Type: Positive

Application uses predefined inputs (e.g., drop-down lists, radio buttons, selection lists, etc.)

Indicator ID: 3 - Environment(s) env-Web

Type: Negative

Managed code (e.g., .NET, Java) is likely, based on URLs.

Indicator ID: 4 - Environment(s) env-ClientServer env-Local env-Embedded env-Peer2Peer env-CommProtocol

Type: Negative

Managed code (e.g., .NET, Java) is likely, based on files found in software.

Indicator ID: 5 - Environment(s) env-Embedded env-Local env-ClientServer

Type: 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.

Indicator ID: 6 - Environment(s) env-Embedded env-Local env-ClientServer

Type: 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.



Step 1 - 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..

Tecnique ID: 1 - Environment(s) env-Web env-ClientServer env-CommProtocol env-Peer2Peer

Brute force attack through black box penetration test tool.

Tecnique ID: 2 - Environment(s) env-CommProtocol env-Peer2Peer env-ClientServer

Fuzzing of communications protocols

Tecnique ID: 3 - Environment(s) env-All

Manual testing of possible inputs with attack data.

Security Control ID: 1

Type: 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.

Security Control ID: 2

Type: Corrective

Disconnect or block connections from systems or users that exceed acceptable heuristics for normal transaction sizes.


Outcome ID: 1

Type: Success

Unexpected output from the application.

Outcome ID: 2

Type: Failure

No unexpected output from the application.


Step 2 - Monitor responses

Watch for any indication of failure occurring. Carefully watch to see what happened when filter failure occurred. Did the data get in?.

Tecnique ID: 1 - Environment(s) env-All

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.

Tecnique ID: 2 - Environment(s) env-Local env-Embedded

Check Log files. An attacker with access to log files can look at the outcome of bad input.

Security Control ID: 1

Type: Preventative

Prevent access to log files that contain error output.

Security Control ID: 2

Type: Preventative

Prevent access to and/or sanitize all error output.



Step 1 - Abuse the system through filter failure

An attacker writes a script to consistently induce the filter failure..

Tecnique ID: 1 - Environment(s) env-All

DoS through filter failure. The attacker causes the system to crash or stay down because of its failure to filter properly.

Tecnique ID: 2 - Environment(s) env-All

Malicious code execution. An attacker introduces a malicious payload and executes arbitrary code on the target system.

Tecnique ID: 3 - Environment(s) 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.

Indicator ID: 1 - Environment(s) env-All

Type: Positive

Failure mode of the software (perhaps as a safety mechanism) includes exiting or ceasing to respond.

Indicator ID: 2 - Environment(s) env-All

Type: Negative

Failures do not involve stopping services, rejecting inputs or connections, and do not affect other simultaneous users of the software.


Security Control ID: 1

Type: Detective

Monitor software response time regularly, and react to unexpected variations.

Security Control ID: 2

Type: Preventative

Execute filtering modules with minimal privileges.

Security Control ID: 3

Type: Preventative

Execute filtering modules in operating system "sandboxes" or similar containers.


Outcome ID: 1

Type: Success

Attacker-supplied code is executed on the target system.

Outcome ID: 2

Type: 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).

Outcome ID: 3

Type: Success

Non-response by an attacker's input has an impact on the quality of service of other simultaneous users of the software.



Input validation and filtering logic should fail securely (vault doors are closed)

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.