XML Signature Wrapping - Optional Element in Security Header

From WS-Attacks
Jump to: navigation, search

Attack description

In this attack the following scenario is covered: A signed element is an optional sibling of the <Signature> element, contained within the Security Header. A typical example is the <Timestamp> element, which is a sibling of the <Signature> element. Both are direct children of the SOAP Security Header.

When comparing this scenario to the previous examples: XML Signature Wrapping - Simple Context and XML Signature Wrapping - Optional Element, the difference is that the signed data is a sibling of the <Signature> element.

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 thinks:

  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 doesn'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.
  4. Signed element is an (optional) child of the SOAP Security Header and a sibling of the <Signature> element.


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. This time the signed part is the <wsu:Timestamp> element. The <wsu:Timestamp> element specifies the timeframe the SOAP message is valid. In this example we assume that the element is optional. Note that the signed data is refernced via an XPath. The XPath expression selects any <wsu:Timestamp> element that is a child of any element named <wsu:Security> which is a child of any element named soap:Header which is a child of any root element named soap:Envelope.

<soap:Envelope ...>
  <soap:Header>
    <wsse:Security>
      ...
      <ds:Signature>
        <ds:SignedInfo>
           ...
           <ds:Reference URI="#theBody">
              ...
           </ds:Reference>
           <ds:Reference URI="">
             <ds:Transforms>
               <ds:Transform Algorithm=".../REC-xpath-19991116">
                 <ds:XPath ...>
                    /soap:Envelope/soap:Header/wsse:Security/wsu:Timestamp
                 </ds:XPath>
                </ds:Transform>
                ...
               </ds:Transforms>
               ...
          </ds:Reference>
        </ds:SignedInfo>
        ...
      </ds:Signature>
      <wsu:Timestamp wsu:Id="theTimestamp">
         <wsu:Created>2005-05-29T08:45:00Z</wsu:Created>
         <wsu:Expires>2005-05-29T09:00:00Z</wsu:Expires>
      </wsu:Timestamp>
    </wsse:Security>
  </soap:Header>
  <soap:Body wsu:Id="theBody">
    <getQuote Symbol="IBM"/>
  </soap:Body>
</soap:Envelope>

Listing 1: Unmodified SOAP message with signed <wsu:Timestamp> element


Listing 2 shows the same example. However a change was made: The <wsu:Timestamp> element got removed from its original position and got placed in a 2nd additional <wsse:Security> element. Furthermore the new <wssu:Security> element got the following attributes:

  • soap:mustUnderstand="0" - That means that this element is optional [2]
  • soap:role=".../none" - That means that the the SOAP node (application logic) should not process this header element[3].

In total that means that it gets completely ignored by the application logic later on.


<soap:Envelope ...>
  <soap:Header>
    <wsse:Security>
      ...
      <ds:Signature>
        <ds:SignedInfo>
           ...
           <ds:Reference URI="#theBody">
              ...
           </ds:Reference>
           <ds:Reference URI="">
             <ds:Transforms>
               <ds:Transform Algorithm=".../REC-xpath-19991116">
                 <ds:XPath ...>
                    /soap:Envelope/soap:Header/wsse:Security/wsu:Timestamp
                 </ds:XPath>
                </ds:Transform>
                ...
               </ds:Transforms>
               ...
          </ds:Reference>
        </ds:SignedInfo>
        ...
      </ds:Signature>
    </wsse:Security>
    <!-- 2nd SOAP Security Header added by attacker-->
    <wsse:Security
      soap:mustUnderstand=”0”
      soap:role=”.../none”>
      <wsu:Timestamp wsu:Id="theTimestamp">
         <wsu:Created>2005-05-29T08:45:00Z</wsu:Created>
         <wsu:Expires>2005-05-29T09:00:00Z</wsu:Expires>
      </wsu:Timestamp>
    </wsse:Security>
  </soap:Header>
  <soap:Body wsu:Id="theBody">
    <getQuote Symbol="IBM"/>
  </soap:Body>
</soap:Envelope>

Listing 2: Maliciously modified SOAP message with <wssu:element> in new 2nd <wsse:Security> element.


What happens when the SOAP Message gets processed:

  1. The XML Signature verification algorithm starts looking for the element <wsu:Timestamp>, as stated in the Xpath expression.
  2. Eventually it will find the <wsu:Timestamp> Element within the 2nd <wsse:Header> element.
  3. Signature verification will be performed on the <wsu:Timestamp> element within the 2nd <wsse:Security> element. Signature verification will be positive, since the Xpath expression finds the unmodified Timestamp.
  4. The SOAP Body and its children get passed to the application logic, except for the 2nd <wsse:Security> element, since it contains the information to be "discarded". Therefore the application logic behaves as if the optional <wsu:Timestamp> element is not present. For example an attacker performing a replay attack would have been successful.


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 own set of rules.


The strategy to defend against this scenario, are as follows:

  • Define a strict receiver side security policy:
    • a signature "A" XML Signature must be present in a wsse:Security header element with an explicit soap:role attribute with the value ".../ultimateReceiver".
    • the element specified by /soap:Envelope/soap:Body must be referenced from signature "A" and
    • if present, any element matching /soap:Envelope/soap:Header/wsa:ReplyTo must be referenced via an absolute path XPath expression from signature "A" using WSS with XML Signature, and
    • if present, any element matching /soap:Envelope/soap:Header/wsse:Security[@role=".../ultimateReceiver"]/wsu:Timestamp must be refernced via an absolute path XPath expression from signature "A" using WSS with XML Signature, and
    • the signature "A" verification key must be provided by an X.509v3 certificate issued by one of a set of trusted Certified Authorities (CA).

NOTE: This countermeasures only apply to this specific attack scenario. Make sure that your scenario matches the scenario described within. 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/