Using Alternative IP Address Encodings
Attack Pattern ID: 4 (Detailed Attack Pattern Completeness: Complete)Typical Severity: HighStatus: Draft
+ Description

Summary

This attack relies on the attacker using unexpected formats for representing IP addresses. Networked applications may expect network location information in a specific format, such as fully qualified domains names, URL, IP address, or IP Address ranges. The issue that the attacker can exploit is that these design assumptions may not be validated against a variety of different possible encodings and network address location formats. Applications that use naming for creating policy namespaces for managing access control may be susceptible to queryin directly by IP addresses, which is ultimately a more generally authoritative way of communicating on a network.

Alternative IP addresses can be used by the attacker to bypass application access control in order to gain access to data that is only protected by obscuring its location.

In addition this type of attack can be used as a reconnaissance mechansim to provide entry point information that the attacker gathers to penetrate deeper into the system.

+ Attack Prerequisites

The target software must fail to anticipate all of the possible valid encodings of an IP/web address.

+ Typical Likelihood of Exploit

Likelihood: Medium

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

Description

An attacker identifies an application server that applies a security policy based on the domain and application name, so the access control policy covers authentication and authorization for anyone accessing http://example.domain:8080/application. However, by putting in the IP address of the host the application authentication and authorization controls may be bypassed http://192.168.0.1:8080/application. The attacker relies on the victim applying policy to the namespace abstraction and not having a default deny policy in place to manage exceptions.

+ Attacker Skills or Knowledge Required

Skill or Knowledge Level: Low

The attacker has only to try IP address combinations.

+ Resources Required

Ability to communicate with server. Optionally, ability to capture output directly through synchronous communication or other method such as FTP.

+ Solutions and Mitigations

Design: Default deny access control policies

Design: Input validation routines should check and enforce both input data types and content against a positive specification. In regards to IP addresses, this should include the authorized manner for the application to represent IP addresses and not accept user specified IP addresses and IP address formats (such as ranges)

Implementation: Perform input validation for all remote content.

+ Attack Motivation-Consequences
  • Privilege Escalation
+ Injection Vector

Malicious input delivered through standard input

+ Payload

Varies with instantiation of attack pattern. Malicious payload may be passed directly from appliation client, such as the web browser.

+ Activation Zone

Client machine and client network

+ Payload Activation Impact

Enables attacker to view and access unexpected network services.

+ Related Weaknesses
CWE-IDWeakness NameWeakness Relationship Type
291Trusting Self-reported IP AddressTargeted
180Incorrect Behavior Order: Validate Before CanonicalizeTargeted
41Improper Resolution of Path EquivalenceTargeted
345Insufficient Verification of Data AuthenticityTargeted
697Insufficient ComparisonTargeted
707Improper Enforcement of Message or Data StructureTargeted
+ Related Attack Patterns
NatureTypeIDNameDescriptionView(s) this relationship pertains toView\(s\)
ChildOfAttack PatternAttack Pattern267Leverage Alternate Encoding 
Mechanism of Attack (primary)1000
+ Purposes
  • Penetration
+ CIA Impact
Confidentiality Impact: MediumIntegrity Impact: MediumAvailability Impact: High
+ Technical Context
Architectural Paradigms
All
Frameworks
All
Platforms
All
Languages
All
+ References
G. Hoglund and G. McGraw. "Exploiting Software: How to Break Code". Addison-Wesley. February 2004.
+ Content History
Submissions
SubmitterOrganizationDate
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.Cigital, Inc2007-01-01
Modifications
ModifierOrganizationDateComments
Gunnar PetersonCigital, Inc2007-02-28Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software"
Sean BarnumCigital, Inc2007-03-09Review and revise
Richard StruseVOXEM, Inc2007-03-26Review and feedback leading to changes in Name, Attack Prerequisites,Resources Required and Method of Attack
Sean BarnumCigital, Inc2007-04-13Modified pattern content according to review and feedback