CAPEC - CAPEC-43: Exploiting Multiple Input Interpretation Layers (Version 3.9)
New to CAPEC? Start Here
Home > CAPEC List > CAPEC-43: Exploiting Multiple Input Interpretation Layers (Version 3.9)  

CAPEC-43: Exploiting Multiple Input Interpretation Layers

Attack Pattern ID: 43
Abstraction: Detailed
View customized information:
+ Description
An attacker supplies the target software with input data that contains sequences of special characters designed to bypass input validation logic. This exploit relies on the target making multiples passes over the input data and processing a "layer" of special characters with each pass. In this manner, the attacker can disguise input that would otherwise be rejected as invalid by concealing it with layers of special/escape characters that are stripped off by subsequent processing steps. The goal is to first discover cases where the input validation layer executes before one or more parsing layers. That is, user input may go through the following logic in an application: <parser1> --> <input validator> --> <parser2>. In such cases, the attacker will need to provide input that will pass through the input validator, but after passing through parser2, will be converted into something that the input validator was supposed to stop.
+ Likelihood Of Attack

Medium

+ Typical Severity

High

+ Relationships
Section HelpThis table shows the other attack patterns and high level categories that are related to this attack pattern. These relationships are defined as ChildOf and ParentOf, and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as CanFollow, PeerOf, and CanAlsoBe are defined to show similar attack patterns that the user may want to explore.
NatureTypeIDName
ChildOfStandard Attack PatternStandard Attack Pattern - A standard level attack pattern in CAPEC is focused on a specific methodology or technique used in an attack. It is often seen as a singular piece of a fully executed attack. A standard attack pattern is meant to provide sufficient details to understand the specific technique and how it attempts to accomplish a desired goal. A standard level attack pattern is a specific type of a more abstract meta level attack pattern.267Leverage Alternate Encoding
Section HelpThis table shows the views that this attack pattern belongs to and top level categories within that view.
+ Execution Flow
Explore
  1. Determine application/system inputs where bypassing input validation is desired: The attacker first needs to determine all of the application's/system's inputs where input validation is being performed and where they want to bypass it.

    Techniques
    While using an application/system, the attacker discovers an input where validation is stopping them from performing some malicious or unauthorized actions.
Experiment
  1. Determine which character encodings are accepted by the application/system: The attacker then needs to provide various character encodings to the application/system and determine which ones are accepted. The attacker will need to observe the application's/system's response to the encoded data to determine whether the data was interpreted properly.

    Techniques
    Determine which escape characters are accepted by the application/system. A common escape character is the backslash character, '\'
    Determine whether URL encoding is accepted by the application/system.
    Determine whether UTF-8 encoding is accepted by the application/system.
    Determine whether UTF-16 encoding is accepted by the application/system.
    Determine if any other encodings are accepted by the application/system.
  2. Combine multiple encodings accepted by the application.: The attacker now combines encodings accepted by the application. The attacker may combine different encodings or apply the same encoding multiple times.

    Techniques
    Combine same encoding multiple times and observe its effects. For example, if special characters are encoded with a leading backslash, then the following encoding may be accepted by the application/system: "\\\.". With two parsing layers, this may get converted to "\." after the first parsing layer, and then, to "." after the second. If the input validation layer is between the two parsing layers, then "\\\.\\\." might pass a test for ".." but still get converted to ".." afterwards. This may enable directory traversal attacks.
    Combine multiple encodings and observe the effects. For example, the attacker might encode "." as "\.", and then, encode "\." as "&#92;&#46;", and then, encode that using URL encoding to "%26%2392%3B%26%2346%3B"
Exploit
  1. Leverage ability to bypass input validation: Attacker leverages their ability to bypass input validation to gain unauthorized access to system. There are many attacks possible, and a few examples are mentioned here.

    Techniques
    Gain access to sensitive files.
    Perform command injection.
    Perform SQL injection.
    Perform XSS attacks.
+ Prerequisites
User input is used to construct a command to be executed on the target system or as part of the file name.
Multiple parser passes are performed on the data supplied by the user.
+ Skills Required
[Level: Medium]
Knowledge of various escaping schemes, such as URL escape encoding and XML escape characters.
+ Indicators
Control characters are being detected by the filters repeatedly.
+ Consequences
Section HelpThis table specifies different individual consequences associated with the attack pattern. The Scope identifies the security property that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in their attack. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a pattern will be used to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
ScopeImpactLikelihood
Integrity
Modify Data
Confidentiality
Access Control
Authorization
Gain Privileges
Confidentiality
Read Data
+ Mitigations
An iterative approach to input validation may be required to ensure that no dangerous characters are present. It may be necessary to implement redundant checking across different input validation layers. Ensure that invalid data is rejected as soon as possible and do not continue to work with it.
Make sure to perform input validation on canonicalized data (i.e. data that is data in its most standard form). This will help avoid tricky encodings getting past the filters.
Assume all input is malicious. Create an allowlist that defines all valid input to the software system based on the requirements specifications. Input that does not match against the allowlist would not be permitted to enter into the system.
+ Example Instances

The backslash character provides a good example of the multiple-parser issue. A backslash is used to escape characters in strings, but is also used to delimit directories on the NT file system. When performing a command injection that includes NT paths, there is usually a need to "double escape" the backslash. In some cases, a quadruple escape is necessary.

Original String: C:\\\\winnt\\\\system32\\\\cmd.exe /c

<parsing layer>

Interim String: C:\\winnt\\system32\\cmd.exe /c

<parsing layer>

Final String: C:\winnt\system32\cmd.exe /c

This diagram shows each successive layer of parsing translating the backslash character. A double backslash becomes a single as it is parsed. By using quadruple backslashes, the attacker is able to control the result in the final string.

[REF-1]

+ Taxonomy Mappings
Section HelpCAPEC mappings to ATT&CK techniques leverage an inheritance model to streamline and minimize direct CAPEC/ATT&CK mappings. Inheritance of a mapping is indicated by text stating that the parent CAPEC has relevant ATT&CK mappings. Note that the ATT&CK Enterprise Framework does not use an inheritance model as part of the mapping to CAPEC.
Relevant to the ATT&CK taxonomy mapping (see parent )
+ References
[REF-1] G. Hoglund and G. McGraw. "Exploiting Software: How to Break Code". Addison-Wesley. 2004-02.
+ Content History
Submissions
Submission DateSubmitterOrganization
2014-06-23
(Version 2.6)
CAPEC Content TeamThe MITRE Corporation
Modifications
Modification DateModifierOrganization
2018-07-31
(Version 2.12)
CAPEC Content TeamThe MITRE Corporation
Updated Attacker_Skills_or_Knowledge_Required, Description, Description Summary, References
2020-07-30
(Version 3.3)
CAPEC Content TeamThe MITRE Corporation
Updated Example_Instances, Execution_Flow, Mitigations
2021-06-24
(Version 3.5)
CAPEC Content TeamThe MITRE Corporation
Updated Related_Weaknesses
2022-09-29
(Version 3.8)
CAPEC Content TeamThe MITRE Corporation
Updated Example_Instances
More information is available — Please select a different filter.
Page Last Updated or Reviewed: July 31, 2018