Home > CAPEC List > CAPEC-267: Leverage Alternate Encoding (Version 2.4)  

CAPEC-267: Leverage Alternate Encoding

 
Leverage Alternate Encoding
Definition in a New Window Definition in a New Window
Attack Pattern ID: 267
Abstraction: Standard
Status: Draft
Completeness: Complete
+ Description

Summary

This attack leverages the possibility to encode potentially harmful input and submit it to applications not expecting or effective at validating this encoding standard making input filtering difficult.

Attack Execution Flow

Explore
  1. Survey the application for user-controllable inputs:

    Using a browser, an automated tool or by inspecting the application, an attacker records all entry points to the application.

    Attack Step Techniques

    IDAttack Step Technique DescriptionEnvironments
    1

    Use a spidering tool to follow and record all links and analyze the web pages to find entry points. Make special note of any links that include parameters in the URL.

    env-Web
    2

    Use a proxy tool to record all user input entry points visited during a manual traversal of the web application.

    env-Web
    3

    Use a browser to manually explore the website and analyze how it is constructed. Many browsers' plugins are available to facilitate the analysis or automate the discovery.

    env-Web
    4

    Manually inspect the application to find entry points.

    env-All

    Indicators

    IDTypeIndicator DescriptionEnvironments
    1Positive

    Inputs are used by the application or the browser (DOM)

    env-All env-Web
    2Inconclusive

    Using URL rewriting, parameters may be part of the URL path.

    env-Web
    3Inconclusive

    No parameters appear to be used by the application. Even though none appear, the application may still use them if they are provided.

    env-Web
    4Inconclusive

    No inputs seem to be used by the application. They might still be provided to another component (web service, database, system call, etc.).

    env-All env-Web
    5Negative

    Applications that have only static pages or that simply present information without accepting input are unlikely to be susceptible.

    env-Web

    Outcomes

    IDTypeOutcome Description
    1Success
    A list of entry points (URL, parameters, configuration files, etc.) is created by the attacker.
    2Success
    A list of resources accessed by the application is created by the attacker.

    Security Controls

    IDTypeSecurity Control Description
    1Detective
    Monitor velocity of page fetching in web logs. Humans who view a page and select a link from it will click far slower and far less regularly than tools. Tools make requests very quickly and the requests are typically spaced apart regularly (e.g. 0.8 seconds between them).
    2Detective
    Create links on some pages that are visually hidden from web browsers. Using iframes, images, or other HTML techniques, the links can be hidden from web browsing humans, but visible to spiders and programs. A request for the page, then, becomes a good predictor of an automated tool probing the application.
    3Preventative
    Use CAPTCHA to prevent the use of the application by an automated tool.
    4Preventative
    Actively monitor the application and either deny or redirect requests from origins that appear to be automated.
Experiment
  1. Probe entry points to locate vulnerabilities:

    The attacker uses the entry points gathered in the "Explore" phase as a target list and injects various payloads using a variety of different types of encodings to determine if an entry point actually represents a vulnerability with insufficient validation logic and to characterize the extent to which the vulnerability can be exploited.

    Attack Step Techniques

    IDAttack Step Technique DescriptionEnvironments
    1

    Try to use different encodings of content in order to bypass validation routines.

    env-All env-Web

    Indicators

    IDTypeIndicator DescriptionEnvironments
    1Positive

    The application accepts user-controllable input.

    env-All env-Web

    Outcomes

    IDTypeOutcome Description
    1Success
    The attacker's encoded payload is processed and acted on by the application without filtering or transcoding.
    2Failure
    The application decodes the charset and filters the inputs.

    Security Controls

    IDTypeSecurity Control Description
    1Detective
    Monitor inputs to web servers. Alert on unusual charset and/or characters.
    2Preventative
    Implement input validation routines that canonicalize and filter user submitted content.
    3Preventative
    Specify the charset of the HTTP transaction/content.
    4Preventative
    Actively monitor the application and either deny or redirect requests from origins that appear to be attack attempts.
+ Attack Prerequisites
  • The application's decoder accepts and interprets encoded characters. Data canonicalization, input filtering and validating is not done properly leaving the door open to harmful characters for the target host.

+ Typical Severity

High

+ Typical Likelihood of Exploit

Likelihood: High

+ Methods of Attack
  • Injection
  • Protocol Manipulation
  • API Abuse
+ Examples-Instances

Description

Microsoft Internet Explorer 5.01 SP4, 6, 6 SP1, and 7 does not properly handle unspecified "encoding strings," which allows remote attackers to bypass the Same Origin Policy and obtain sensitive information via a crafted web site, aka "Post Encoding Information Disclosure Vulnerability." Related Vulnerabilities CVE-2010-0488

+ Attacker Skills or Knowledge Required

Skill or Knowledge Level: Low

An attacker can inject different representation of a filtered character in a different encoding.

Skill or Knowledge Level: Medium

An attacker may craft subtle encoding of input data by using the knowledge that he/she has gathered about the target host.

+ Probing Techniques

Description

Attacker may try to inject dangerous characters using different encoding using (example of invalid UTF-8 characters, overlong UTF-8, Chinese characters in Big-5, etc.). The attacker hopes that the targeted system does poor input filtering for all the different possible representations of the malicious characters. Malicious inputs can be sent through an HTML form, directly encoded in the URL or as part of a database query. The attacker can use scripts or automated tools to probe for poor input filtering.

+ Solutions and Mitigations

Assume all input might use an improper representation. Use canonicalized data inside the application; all data must be converted into the representation used inside the application (UTF-8, UTF-16, etc.)

Assume all input is malicious. Create a white list that defines all valid input to the software system based on the requirements specifications. Input that does not match against the white list should not be permitted to enter into the system. Test your decoding process against malicious input.

+ Attack Motivation-Consequences
ScopeTechnical ImpactNote
Integrity
Modify files or directories
Confidentiality
Read files or directories
Integrity
Modify application data
Confidentiality
Read memory
Integrity
Modify memory
Confidentiality
Read application data
Authorization
Execute unauthorized code or commands
Run Arbitrary Code
Accountability
Authentication
Authorization
Non-Repudiation
Gain privileges / assume identity
Access_Control
Authorization
Bypass protection mechanism
Availability
DoS: amplification
DoS: crash / exit / restart
DoS: instability
DoS: resource consumption (CPU)
DoS: resource consumption (memory)
DoS: resource consumption (other)
Denial of Service
+ Purposes
  • Penetration
+ CIA Impact
Confidentiality Impact: HighIntegrity Impact: HighAvailability Impact: Medium
+ Technical Context
Architectural Paradigms
Client-Server
n-Tier
Frameworks
All
Platforms
All
Languages
All
+ References
[R.267.1] [REF-1] "WASC Threat Classification 2.0". WASC-20 - Improper Input Handling. The Web Application Security Consortium (WASC). 2010. <http://projects.webappsec.org/Improper-Input-Handling>.
[R.267.2] [REF-4] "OWASP". Category: Encoding. The Open Web Application Security Project (OWASP). <http://www.owasp.org/index.php/Category:Encoding>.
[R.267.3] [REF-4] "OWASP". Canonicalization, locale and Unicode. The Open Web Application Security Project (OWASP). <http://www.owasp.org/index.php/Canonicalization,_locale_and_Unicode>.
[R.267.4] [REF-4] "OWASP". XSS (Cross Site Scripting) Prevention Cheat Sheet. The Open Web Application Security Project (OWASP). <http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet>.
[R.267.5] [REF-18] David Wheeler. "Secure Programming for Linux and Unix HOWTO". Chapter 5 Section 9: Character Encoding. <http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/character-encoding.html>.
[R.267.6] [REF-6] "Wikipedia". Character encoding. The Wikimedia Foundation, Inc. <http://en.wikipedia.org/wiki/Character_encoding>.
[R.267.7] [REF-19] Eric Hacker. "IDS Evasion with Unicode". January 3, 2001. <http://www.securityfocus.com/infocus/1232>.
+ Content History
Modifications
ModifierOrganizationDateCommentsSource
Romain GaucherCigital, Inc.Pre-review - 0.1
CAPEC Content TeamThe MITRE Corporation2014-02-06Updated Attack_PhasesInternal

Page Last Updated: April 10, 2014