Using Leading 'Ghost' Character Sequences to Bypass Input Filters |
Attack Pattern ID: 3 (Detailed Attack Pattern Completeness: Complete) | Typical Severity: Medium | Status: Draft |
Summary
An attacker intentionally introduces leading characters that enable getting the input past the filters. The API that is being targetted, ignores the leading "ghost" characters, and therefore processes the attacker's input. This occurs when the targetted API will accept input data in several syntactic forms and interpret it in the equivalent semantic way, while the filter does not take into account the full spectrum of the syntactic forms acceptable to the targetted API.
Some APIs will strip certain leading characters from a string of parameters. Perhaps these characters are considered redundant, and for this reason they are removed. Another possibility is the parser logic at the beginning of analysis is specialized in some way that causes some characters to be removed. The attacker can specify multiple types of alternative encodings at the beginning of a string as a set of probes.
One commonly used possibility involves adding ghost characters—extra characters that don't affect the validity of the request at the API layer. If the attacker has access to the API libraries being targeted, certain attack ideas can be tested directly in advance. Once alternative ghost encodings emerge through testing, the attacker can move from lab-based API testing to testing real-world service implementations.
Attack Execution Flow
Determine if the source code is available and if so, examine the filter logic.
If the source code is not available, write a small program that loops through various possible inputs to given API call and tries a variety of alternate (but equivalent) encodings of strings with leading ghost characters. Knowlege of frameworks and libraries used and what filters they apply will help to make this search more structured.
Observe the effects. See if the probes are getting past the filters. Identify a string that is semantically equivalent to that which an attacker wants to pass to the targeted API, but syntactically structured in a way as to get past the input filter. That encoding will contain certain ghost characters that will help it get past the filters. These ghost characters will be ignored by the targeted API.
Once the "winning" alternate encoding using (typically leading) ghost characters is identified, an attacker can launch the attacks against the targetted API (e.g. directory traversal attack, arbitrarary shell command execution, corruption of files)
The targetted API must ignore the leading ghost characters that are used to get past the filters for the semantics to be the same.
Description
Alternate Encoding with Ghost Characters in FTP and Web Servers
Some web and FTP servers fail to detect prohibited upward directory traversals if the user-supplied pathname contains extra characters such as an extra leading dot. For example, a program that will disallow access to the pathname "../test.txt" may erroneously allow access to that file if the pathname is specified as ".../test.txt". This attack succeeds because 1) the input validation logic fails to detect the triple-dot as a directory traversal attempt (since it isn't dot-dot), 2) some part of the input processing decided to strip off the "extra" dot, leaving the dot-dot behind.
Using the file system API as the target, the following strings are all equivalent to many programs:
As you can see, there are many ways to make a semantically equivalent request. All these strings ultimately result in a request for the file ../test.txt.
Perform white list rather than black list input validation.
Canonicalize all data prior to validation.
Take an iterative approach to input validation (defense in depth).
The payload is the parameter that an attacker is supplying to the targetted API that will allow the attacker to elevate privilege and subvert the authorization service.
The targetted API is the activation zone. These attacks often target the file system or the shell to execute commands.
Failure in authorization service may lead to compromises in data confidentiality and integrity.
CWE-ID | Weakness Name | Weakness Relationship Type |
---|---|---|
173 | Failure to Handle Alternate Encoding | Targeted |
41 | Improper Resolution of Path Equivalence | Targeted |
172 | Encoding Error | Targeted |
171 | Cleansing, Canonicalization, and Comparison Errors | Targeted |
179 | Incorrect Behavior Order: Early Validation | Targeted |
180 | Incorrect Behavior Order: Validate Before Canonicalize | Targeted |
181 | Incorrect Behavior Order: Validate Before Filter | Secondary |
183 | Permissive Whitelist | Secondary |
184 | Incomplete Blacklist | Secondary |
20 | Improper Input Validation | Targeted |
74 | Failure to Sanitize Data into a Different Plane ('Injection') | Targeted |
697 | Insufficient Comparison | Targeted |
707 | Improper Enforcement of Message or Data Structure | Targeted |
Nature | Type | ID | Name | Description | View(s) this relationship pertains to |
---|---|---|---|---|---|
ChildOf | Attack Pattern | 267 | Leverage Alternate Encoding | Â | Mechanism of Attack (primary)1000 |
Perform input validation and filtering on data in its canonical form.
Understand the APIs to which user input will be passed and know how permissive they are. Perform appropriate input validation given that information.
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.
Submissions | ||||
---|---|---|---|---|
Submitter | Organization | Date | ||
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004. | Cigital, Inc | 2007-03-01 |
Modifications | |||||
---|---|---|---|---|---|
Modifier | Organization | Date | Comments | ||
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 | ||
Richard Struse | VOXEM, Inc | 2007-03-26 | Review and feedback leading to changes in Name, Attack Execution Flow and Examples | ||
Sean Barnum | Cigital, Inc | 2007-04-13 | Modified pattern content according to review and feedback |