Difference between revisions of "XML Signature Wrapping - Optional Element"

From WS-Attacks
Jump to: navigation, search
(→‎References)
 
m (1 revision imported: Import from WS-Attacks)
 
(No difference)

Latest revision as of 11:26, 31 October 2015

Attack description

In other scenarios the signed data is contained within the SOAP Header and is optional. A typical example is the <ReplyTo> element, that specifies where to send the reply to. When comparing this scenario to the previous example the XML Signature Wrapping - Simple Context attack, the problem is not the positioning of the signed data within SOAP Header. The problem is that the signed data is optional. This scenario is not covered by the previous example.

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 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, this attack is limited.
  4. Signed data is an optional 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. This time the signed part is the <wsa:ReplyTo> element. The <wsa:ReplyTo> element specifies where the reply is sent. In this example we assume that the element is optional. 

<soap:Envelope ...>
  <soap:Header>
   <wsse:Security>
     ...
     <ds:Signature>
       <ds:SignedInfo>
         ...
         <ds:Reference URI="#theBody">
           ...
         </ds:Reference>
         <ds:Reference URI="#theReplyTo">
           ...
         </ds:Reference>
       </ds:SignedInfo>
         ...
       </ds:Signature>
     </wsse:Security>
     <wsa:ReplyTo wsu:Id=”theReplyTo>
       <wsa:Address>http://good.com/</wsa:Address>
     </wsa:ReplyTo>
  </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 a change was made: The <wsa:ReplyTo> element got placed in a <wrapper> element that is positioned below the <wsse:security> element. Furthermore the <wrapper> element got assigned 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].

The above attribute settings cause the <wsa:ReplyTo> to be 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="#theReplyTo">
           ...
         </ds:Reference>
       </ds:SignedInfo>
         ...
       </ds:Signature>
     </wsse:Security>
     <Wrapper
       soap:mustUnderstand="0"
       soap:role=".../none" >
     <wsa:ReplyTo wsu:Id=”theReplyTo>
       <wsa:Address>http://good.com/</wsa:Address>
     </wsa:ReplyTo>
     </Wrapper>
  </soap:Header>
  <soap:Body wsu:Id="theBody">
    <getQuote Symbol=”IBM”/>
  </soap:Body>
</soap:Envelope>

Listing 2: Maliciously modified SOAP message with signature


What happens when the SOAP Message gets processed:

  1. The XML Signature verification algorithm starts looking for the element with the id "theReplyTo", as stated in the <Reference> element.
  2. Eventually it will find the <wsa:ReplyTo> Element wrapped within the <wrapper> element.
  3. Signature verification will be performed on the <wsa:ReplyTo> within the <wrapper> element. Signature verification will be positive, since it contains the unmodified <wsa:ReplyTo> that got signed by the sender.
  4. The SOAP Body and entire children that are understood get passed to the application logic. The <wrapper> element doesn't get passed over to the application logic. Therefore the application logic behaves as if the <wsa:ReplyTo> element is not present and replies to the original sender of the message.


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:
    • the element specified by /soap:Envelope/soap:Body must be referenced from a signature "A" using WSS with XML Signature, and
    • if present, any element matching /soap:Envelope/soap:Header/wsa:ReplyTo must be referenced via an absolute XPath path expression having a 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).
  • Define a sender side specification of a security policy.
    Apply an XPath expression within the <Reference> element of the XML Signature that points to the signed data.
    Listing 3 gives an example for such a transform. 
    <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/wsa:ReplyTo
               </ds:XPath>
             </ds:Transform>
             <ds:Transform Algorithm=".../xml-exc-c14n#"/>
           </ds:Transforms>
           ...
         </ds:Reference>
       </ds:SignedInfo>
         ...
       </ds:Signature>
     </wsse:Security>
     <wsa:ReplyTo wsu:Id=”theReplyTo>
       <wsa:Address>http://good.com/</wsa:Address>
     </wsa:ReplyTo>
  </soap:Header>
  <soap:Body wsu:Id="theBody">
    <getQuote Symbol=”IBM”/>
  </soap:Body>
</soap:Envelope>
    Listing 3: SOAP message with XPath expression in <Reference> element

NOTE: This countermeasures only apply to this specific attack scenario. Make sure that your scenario matches the scenario described above. 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/
Retrieved from "http://ws-attacks.org/index.php?title=XML_Signature_Wrapping_-_Optional_Element&oldid=63"