XML Signature Wrapping - Simple Context
- 1 Attack description
- 2 Attack subtypes
- 3 Prerequisites for attack
- 4 Graphical representation of attack
- 5 Attack example
- 6 Attack mitigation / countermeasures
- 7 Attack categorisation
- 8 References
Usually the data signed is embedded within the SOAP Body and is referenced via the "Id" attribute. The signed data is contained in a Simple Ancestory Context - that is why we refer to this attack subtype as "XML Signature Wrapping - Simple Context" During signature validation the validator resolves the reference within the <Reference> element and verifies the signature, returning a boolean value. In case of a positive signature verification, the application logic starts processing the SOAP message. In case of a negative signature verification the the message gets discarded. Under regular circumstances manipulation of the signed data always gets detected.
However, it is possible to change the content of the signed data without invalidating the signature. Refer to the example below for a detailed attack description.
Note: Make sure to read the prerequisites of the attack to understand in what scenarios this attack works.
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:
- Attacker knows endpoint of web service. otherwise he is not able to reach the web service.
- 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.
- 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.
- Signed data is a mandatory element outside of the Security Header.
Graphical representation of attack
- Red = attacked web service component
- Black = location of attacker
- Blue = web service component not directly involved in attack.
All examples taken from. Listing 1 shows a valid unmodified SOAP message. The entire SOAP Body is signed, as shown by the line <ds:Reference URI="#theBody"> within the SOAP Header.
<soap:Envelope ...> <soap:Header> <wsse:Security> <wsse:BinarySecurityToken ValueType="...#X509v3" EncodingType="...#Base64Binary" wsu:Id="X509Token"> MIabcdefg0123456789... </wsse:BinarySecurityToken> <ds:Signature> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm=".../xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="...#rsa-sha1"/> <ds:Reference URI="#theBody"> <ds:Transforms> <ds:Transform Algorithm=".../xml-exc-c14n#"/> </ds:Transforms> <ds:DigestMethod Algorithm=".../xmldsig#sha1"/> <ds:DigestValue> AbCdEfG0123456789... </ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue> AbCdEfG0123456789... </ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference> <wsse:Reference URI="#X509Token"/> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> </soap:Header> <soap:Body wsu:Id="theBody"> <getQuote Symbol=”IBM”/> </soap:Body> </soap:Envelope>
Listing 1: Unmodified SOAP message with signature
Listing 2 shows the same example. However some changes were made:
- The SOAP Body got exchanged by a malicious SOAP Body. It is important that the new SOAP Body has another Id.
- The original SOAP Body got placed in a <wrapper> element that is positioned in the SOAP Header.
<soap:Envelope ...> <soap:Header> <wsse:Security> <wsse:BinarySecurityToken ValueType="...#X509v3" EncodingType="...#Base64Binary" wsu:Id="X509Token"> MIabcdefg0123456789... </wsse:BinarySecurityToken> <ds:Signature> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm=".../xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="...#rsa-sha1"/> <ds:Reference URI="#theBody"> <ds:Transforms> <ds:Transform Algorithm=".../xml-exc-c14n#"/> </ds:Transforms> <ds:DigestMethod Algorithm=".../xmldsig#sha1"/> <ds:DigestValue> AbCdEfG0123456789... </ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue> AbCdEfG0123456789... </ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference> <wsse:Reference URI="#X509Token"/> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> <!-- ... --> <!-- Original SOAP Body is placed below --> <!--.... --> <wrapper> <soap:Body wsu:Id="theBody"> <getQuote Symbol=”IBM”/> </soap:Body> </wrapper> </soap:Header> <!-- ... --> <!-- Maliciously modified SOAP Body is placed below --> <!--.... --> <soap:Body wsu:Id="NEW_ID"> <getQuote Symbol=”Evil”/> </soap:Body> </soap:Envelope>
Listing 2: Maliciously modified SOAP message with signature
What happens when the signature gets validated?
- The XML Signature verification algorithm starts looking for the element with the id "theBody", as stated in the <Reference> element.
- Eventually it will find the <soap:Header> Element wrapped within the <wrapper> element. The "real" <soap:Body>, outside of the <soap:Header>, gets ignored since it has the wrong "id".
- Signature verification will be performed on the <soap:Header> within the <wrapper> element. signature verification will be positive, since it contains the original SOAP Body that got signed by the sender.
- The SOAP message gets passed to the application logic. The application logic only processes the SOAP Body that is directly placed under the SOAP Header. All other SOAP Body elements are just ignored.
Practical attacks were shown by Somorovsky et al., who showed how to attack cloud interfaces of Amazon and Eucalyptus cloud providers. This enabled them to execute arbitrary methods on cloud interfaces.
Attack mitigation / countermeasures
The attack worked because of two major flaws:
- The position of the signed data was not fixed within the XML document. Horizontal and vertical movement within the XML document was possible without invalidating the signature.
- XML Signature Verification and processing by the application logic are two different processes that validate/process data according to their one point of views.
Various countermeasures were proposed. Strategies to defend the against this specific scenario, with the SOAP Body signed, are as follows:
- Strategy:define a strict security policy
- the element specified by /soap:Envelope/soap:Body must be signed using WSS with XML Signature, and
- the associated signature verification key must be provided by an X.509v3 certificate issued by one of a set of trusted Certificate Authorities (CAs) (this part is not Signature Wrapping specific!)
NOTE: These countermeasures only apply to this specific attack scenario. Make sure that your scenario matches the scenario described abve. Otherwise your application might be vulnerable.
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
- 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
- Michael McIntosh and Paula Austel. Xml signature wrapping attacks and countermeasures. Technical report, IBM Research, Hawthorne, New York, 10532, 2005.
- Mohammad Ashiqur Rahaman, Maarten Rits, and Andreas Schaad. An inline approach for secure soap requests and early validation, 2005.
- 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.
- 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
- Frederick Hirsch and Pratik Datta. Xml signature best practices. http://www.w3.org/TR/2009/WD-xmldsig-bestpractices-20090226/, 2010. Accessed 01 July 2010.
- Juraj Somorovsky, Mario Heiderich, Meiko Jensen, Jörg Schwenk, Nils Gruschka, Luigi Lo Iacono. All Your Clouds are Belong to us – Security Analysis of Cloud Management Interfaces. In Proceedings of the ACM Cloud Computing Security Workshop (CCSW), 2011. https://www.nds.rub.de/research/publications/amazon-hacking/
- Meiko Jensen, Christopher Meyer, Juraj Somorovsky, Jörg Schwenk. On the Effectiveness of XML Schema Validation for Countering XML Signature Wrapping Attacks. In Proceedings of the ACM Cloud Computing Security Workshop (CCSW), 2011. https://www.nds.rub.de/research/publications/OnTheEffectivenessOfXMLSchemaValidation/
- Juraj Somorovsky. On the Insecurity of XML Security. PhD thesis supervised by Jörg Schwenk and Kenny Paterson, Ruhr University Bochum. https://www.nds.rub.de/research/publications/xmlinsecurity/