How to attack XML Encryption in IBM Datapower (and other Web Services) with WS-Attacker

WS-Attacker is a penetration testing tool, whose aim is to test Web Service specific attacks. It provides attacks, which are far beyond typical Web attacks like SQL injection and XSS. For example, in last blog post, WS-Attacker and its XML Signature wrapping attacks were introduced: http://web-in-security.blogspot.de/2015/04/introduction-to-ws-attacker-xml.html

Today, we released a new version of our WS-Attacker framework: https://github.com/RUB-NDS/WS-Attacker

The new version includes some additional features and bug fixes. For example, WS-Attacker now allows you to define an HTTP/HTTPS proxy for forwarding the generated XML attack messages. This gives you the opportunity to send all the WS-Attacker messages through BurpSuite or OWASP ZAP, and analyze their content or resend them to the Web Service.

However, most importantly, the newest WS-Attacker version includes a plugin for automatic XML Encryption attacks. The plugin was implemented by our student Dennis Kupser.

In this blog post, I am going to show you how to use the plugin to attack an IBM Datapower Web Service and decrypt an encrypted content. Please note that these attacks are also applicable to other services as well.

XML Encryption Attacks

XML Encryption is a W3C standard used for encryption of XML documents. It is typically used in Web Services applications or for encryption of SAML tokens in Single Sign-On scenarios.

XML Encryption defines (among others) two cryptographic algorithms: RSA PKCS#1 v1.5 and AES/3DES in CBC (Cipher Block Chaining) mode of operation. These two algorithms are vulnerable to so called adaptive chosen ciphertext attacks, which has been shown in many practical examples. Thus, it is not surprising that XML Encryption applications were found to be vulnerable to those attacks:

• In 2011, we presented a paper on How to Break XML Encryption, which showed how to attack symmetric key encryption algorithms in CBC mode: https://www.nds.rub.de/research/publications/breaking-xml-encryption/. The idea is very similar to the typical padding oracle attacks, it is just a slightly more complicated, since we use XML parsing errors as a side-channel. A very good summary on this attack gives Matthew Green: http://blog.cryptographyengineering.com/2011/10/attack-of-week-xml-encryption.html
• In 2012, we showed how to apply Bleichenbacher's attack on the asymmetric encryption algorithm (RSA PKCS#1) in XML Encryption: https://www.nds.rub.de/research/publications/breaking-xml-encryption-pkcs15/. A summary on Bleichenbacher's attack is given on our blog: http://web-in-security.blogspot.de/2014/08/old-attacks-on-new-tls-implementations.html

All you need to know for now is that both attacks belong to the family of adaptive chosen ciphertext attacks.

The attacker, who eavesdrops an encrypted message, uses the message receiver as an oracle. He sends to the oracle modified ciphertexts and observes its response (it can contain a general error, a parsing failure, or just a valid response text). Based on the responses, he learns the plaintext.

Attacking XML Encryption in Web Services

In the following, it will be shown how to attack symmetric AES-CBC ciphertexts in Web Services using XML Encryption. For the testing purposes, I configured an IBM Datapower Web Service, which simply decrypts a ciphertext and responds with a test message in a case the decryption was valid.

To execute the attacks, first we start WS-Attacker and load the WSDL file (WSDL message format is used to describe Web Services interfaces and their methods). As can be seen, WS-Attacker successfully loads the Web Services methods offered by our IBM Datapower server.

Afterwards, we can send a test request (our eavesdropped encrypted XML message) to the Web Service. The test request initializes WS-Attacker and the contained plugins: WS-Attacker automatically analyzes whether the message contains encrypted content and whether it is possible to execute an attack on XML Encryption.

 

 After initializing WS-Attacker with the test request, we can move to Plugin configuration. We choose XML Encryption attack, which contains the following, at the first sight complicated configuration.

Here are the relevant parts and their description:

• Elements: list of EncryptedKey elements contained in this message. This message contains only one EncryptedKey element, but there are more complicated scenarios, where messages include more ciphertexts. This option allows us then to choose, which of the encrypted elements is going to be attacked.
• Attack: we can choose between CBC and PKCS#1 attack. Now, we work with the CBC attacks.
• Wrapping attack: If the message contains an XML Signature to protect message authenticity, we can automatically adapt Wrapping attacks to overcome the authenticity check (see previous blog post). In the tested message, there is no XML Signature so I use NO_WRAP.
• String Compare: In order to apply oracle attacks, we have to map real server responses to "oracle" responses. Real responses can however contain timestamps and message ids, which can make the mapping complicated. String comparison methods allow us to define thresholds for message similarities. This makes mapping much easier. I typically use the default Dice-coefficient method with a threshold 0.9.

After setting the above options, we have to just select the attack payload (the CBC ciphertext) using the check box located on the right side. 

Now, we are ready to configure the oracle in the Server Error Table configuration. Here, we click on "New Messages", which sends a few hundreds of messages to the server. Afterwards, we have to provide a mapping from real messages to oracle results. Since we set the Dice-coefficient with a 0.9 threshold, we received only two messages. In the next figure, you can see we configured the server response with an EncryptedData element to be an INVALID oracle response. This is because IBM Datapower with our configuration is not able to decrypt the request and just mirrors the request.

 Ok, so we finally configured WS-Attacker and we can start the attack. After few minutes and about 4900 magical server queries, we can see that we could successfully decrypt 221 message bytes (including the comments and namespaces).

If you use Burp Suite, you can of course follow the whole communication and, if needed, resend some requests:

 Conclusion

In this post I presented how our new WS-Attacker plugin works and how to attack Web Services and decrypt XML Encryption contents. You probably ask whether it is always so easy to attack XML Encryption and what are the countermeasures: no, it is not that easy...

It is a good practice to use XML Encryption together with XML Signatures. XML Signature must be used over the encrypted data, so it is not possible to execute modifications of those data. Most of the Web Services use such a configuration, and IBM Datapower of course allows you to configure such a protection (I just used an insecure configuration to present the WS-Attacker functionality).
However, it is possible to execute certain XML Signature Wrapping attacks or XML Encryption Wrapping attacks to enforce an unsigned content to be decrypted. This allows again for attacks on XML Encryption.

In the next blog post (if I am not too lazy to write it :) ), I will present how to attack an IBM Datapower Web Service, which enforces usage of XML Signature and XML Encryption...

The XML Encryption Plugin has already been used to analyze several XML frameworks. One publicly available result can be seen here: http://coheigea.blogspot.co.at/2015/02/two-new-security-advisories-released.html

If you are interested in more details, please feel free to take a look at the attack implementation or read our papers.