XML Signature Wrapping - Simple Context

From WS-Attacks
Jump to: navigation, search

Attack description

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.


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 a mandatory element outside of the Security Header.


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

All examples taken from[1]. 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:

  1. The SOAP Body got exchanged by a malicious SOAP Body. It is important that the new SOAP Body has another Id.
  2. 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?

  1. The XML Signature verification algorithm starts looking for the element with the id "theBody", as stated in the <Reference> element.
  2. 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".
  3. 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.
  4. 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.[2], 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.


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. Frederick Hirsch and Pratik Datta. Xml signature best practices. http://www.w3.org/TR/2009/WD-xmldsig-bestpractices-20090226/, 2010. Accessed 01 July 2010.
  7. 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/
  8. 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/
  9. 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/