XML Signature Wrapping - with Namespace Injection

From WS-Attacks
Jump to: navigation, search

Attack description

In order to mitigate XML Signature Wrapping attacks on messages with Id-based referencing, it is possible to use further, more concrete, referencing mechanisms. One of these mechanisms is XPath (XML path language). XPath allows one to define exact positions of XML elements in the document tree. This way, it is also possible to define positions of signed XML data.

However, this approach also has some drawbacks and could be attacked with XML Signature Wrapping. The basic idea of the attack is to redefine a signed element namespace that is not protected by the XML Signature. If this is possible, the XML Signature validator can attempt to validate a different XML element.

Refer to the example below for a detailed attack description.

Attack subtypes

There are no attack subtypes for this attack.


Prerequisites for attack

In order for this attack to work the attacker has to have knowledge about the following things:

  1. Attacker knows endpoint of web service. otherwise he is not able to reach the web service.
  2. Attacker knows that the web web service processes the security header and the "signature" element. If the web service doens't "expect" a signed part, it just discards the signature and the attack doesn't work.
  3. Attacker can reach endpoint from its location. Access to the attacked web service is required. If the web service is only available to users within a certain network of a company, this attack is limited.
  4. Signed data is referenced using an XPath expression. The XPath expression does not include namespace declarations.

Graphical representation of attack

AttackedComponent Signature.png

  • Red = attacked web service component
  • Black = location of attacker
  • Blue = web service component not directly involved in attack.



Attack example

For the description of the basic attack idea please consider the following figure.

SOAPMessageSignedXPathNamespace.png

This figure contains a SOAP message with an operation's content. The content is referenced using the XPath expression /soap:Envelope/soap:Body/op:Operation/Content. The XPath engine typically searches for such an XML element using namespace URIs (not namespace prefixes). Thus, the namespace prefixes are first resolved. The XPath engine traverses the document to the top and collects all the namespace URIs: soap="ns-soap" and op="ns-op". Afterwards, it searches for the element /{ns-soap}:Envelope/{ns-soap}:Body/{ns-op}:Operation/Content} . The Content element is then canonicalized and signed. Note that the Exclusive XML Canonicalization method omits the op="ns-op" namespace declaration as it is not needed in the Content element. Thus, this namespace is not protected.

The following figure shows a simplified XSW attack on the message from the previous example.

SOAPMessageSignedXPathNamespaceWrapping.png

The attacker proceeds by the message modification as follows. He first declares a new xmlns:op="ns-attack" namespace in one of the ancestors of the ds:SignedInfo element (in the figure wsse:Security is used). Afterwards, he duplicates the op:Operation element. The first element declares the original namespace xmlns:op="ns-op" and the second element declares xmlns:op="ns-attack". The attacker inserts his content into the first op:Operation element.

The signature verification logic processes this message as follows. It finds the Reference element and resolves the namespace context. As the attacker declared the xmlns:op="ns-attack" namespace in the wsse:Security element, it resolves the following URIs: soap="ns-soap" and op="ns-attack". Afterwards, it searches for /{ns-soap}:Envelope/{ns-soap}:Body/{ns-attack}:Operation/Content. Thus, this XPath expression returns the second (original) op:Operation element and the signature is successfully verified.

The business logic searches for an element in /{ns-soap}:Envelope/{ns-soap}:Body/{ns-op}:Operation/Content. Thus, it executes the first (modified) op:Operation element.

Attack mitigation / countermeasures

Jensen et al. proposed several countermeasures against these attacks. Two of them are practically applicable in the current XML Security frameworks. The first countermeasure includes explicit namespaces in the SignedInfo element, which results in a hash value computation over additionally defined namespaces. The second countermeasure proposes a new XPath syntax. The syntax identifies each element explicitly by its element name (by using the local-name() function) and its namespace context (by using the namespace-uri() function). This ensures that the referenced elements belong to the correct namespaces.

Explicitly Embedding Namespaces in the Hashed XML content

The first proposed approach is to embed the relevant namespaces into the InclusiveNamespaces element. In the case of our message, the sender needs to define soap and op namespaces. 

<Reference URI="#xpointer(
         /soap:Envelope[1]/soap:Body[1]/op:Operation[1]/Content[1])">
  <Transforms>
    <Transform Algorithm=".../xml-exc-c14n#">
      <InclusiveNamespaces PrefixList="soap op"></InclusiveNamespaces>
    </Transform>
  </Transforms>
  <DigestMethod Algorithm=".../xmldsig#sha1"></DigestMethod>
  <DigestValue>yc17yWXGca510flwlu4BzHuZ0IU=</DigestValue>
</Reference>

This enforces that the hash value is computed over the Content element as well as explicitly over the soap and op namespaces. An attacker moving the Content element into an element from a different namespace context would thus invalidate the message.

Prefix-free XPath

The second countermeasure approach defines namespaces directly in the XPath expressions. The proposed XPath expressions explicitly reference elements by their names (using the local-name() function) and namespace URIs (using the namespace-uri() function). An example of such an XPath expression referencing the Content element gives: 

/*[local-name()="Envelope" and namespace-uri()="ns-soap"]/
 *[local-name()="Body" and namespace-uri()="ns-soap"]/
 *[local-name()="Operation" and namespace-uri()="ns-op"]/
 *[local-name()="Content" and namespace-uri()="ns-default"]

This expression contains the namespace context of each element. Thus, if the attacker would move the original element into an element with a different namespace context, the original element would not be found. This approach is for example used in IBM appliances.

Attack categorisation

Categorisation by violated security objective

The attack aims at exhausting the system resources, therefore it violates the security objective Availability.


Categorisation by number of involved parties


Categorisation by attacked component in web service architecture


Categorisation by attack spreading



References

  1. Karthikeyan Bhargavan, Cedric Fournet, Andrew D. Gordon and Greg O’Shea. An Advisor for Web Services Security Policies. CCS Workshop on Secure Web Services, 2005. http://research.microsoft.com/en-us/um/people/fournet/papers/an-advisor-for-web-services-security-policies-sws05.pdf
  2. Michael McIntosh and Paula Austel. Xml signature wrapping attacks and countermeasures. Technical report, IBM Research, Hawthorne, New York, 10532, 2005.
  3. Mohammad Ashiqur Rahaman, Maarten Rits, and Andreas Schaad. An inline approach for secure soap requests and early validation, 2005.
  4. Sebastian Gajek, Lijun Liao, and Jörg Schwenk. Breaking and fixing the inline approach. Technical report, Horst G ̈rtz Institute for IT-Security, 44780 Bochum, Germany, 2007.
  5. Nils Gruschka and Luigi Lo Iacono. Vulnerable Cloud: SOAP Message Security Validation Revisited. In Proceedings of the IEEE International Conference on Web Services, 2009. http://cs.uccs.edu/~gsc/pub/phd/chow/doc/vulnerableCloud2009.pdf
  6. Meiko Jensen, Lijun Liao, and Jörg Schwenk. The curse of namespaces in the domain of XML signature. In ACM Workshop on Secure Web Services (SWS), pages 29–36, 2009.
  7. Frederick Hirsch and Pratik Datta. Xml signature best practices. http://www.w3.org/TR/2009/WD-xmldsig-bestpractices-20090226/, 2010. Accessed 01 July 2010.
  8. Juraj So­mo­rovs­ky, Mario Hei­de­rich, Meiko Jen­sen, Jörg Schwenk, Nils Grusch­ka, Luigi Lo Ia­co­no. All Your Clouds are Be­long to us – Se­cu­ri­ty Ana­ly­sis of Cloud Ma­nage­ment In­ter­faces. In Pro­cee­dings of the ACM Cloud Com­pu­ting Se­cu­ri­ty Work­shop (CCSW), 2011. https://www.nds.rub.de/research/publications/amazon-hacking/
  9. Meiko Jen­sen, Chris­to­pher Meyer, Juraj So­mo­rovs­ky, Jörg Schwenk. On the Effec­tiven­ess of XML Sche­ma Va­li­da­ti­on for Coun­tering XML Si­gna­tu­re Wrap­ping At­tacks. In Pro­cee­dings of the ACM Cloud Com­pu­ting Se­cu­ri­ty Work­shop (CCSW), 2011. https://www.nds.rub.de/research/publications/OnTheEffectivenessOfXMLSchemaValidation/
  10. Juraj Somorovsky. On the In­se­cu­ri­ty of XML Se­cu­ri­ty. PhD thesis supervised by Jörg Schwenk and Kenny Paterson, Ruhr University Bochum. https://www.nds.rub.de/research/publications/xmlinsecurity/
Retrieved from "https://www.ws-attacks.org/index.php?title=XML_Signature_Wrapping_-_with_Namespace_Injection&oldid=69"