I recently stumbled on this post: XML Encryption Broken, Need To Fix W3C Standard
I was expecting to find lots of information online about it, but there isn't actually all that much detail. Since I'm using WCF with lots of message level security SOAP, I thought I popped the question.
Is the mentioned post the real thing, or is it just something exaggerated based on some obtained success in a controlled environment? Is XML encryption actually broken?
With a bit of digging around, I've found some evidence of recent activity on this subject: Functional Explanation of Changes in XML Encryption 1.1 (W3C Working Group Note 11 April 2013). There are a lot of changes in the XML Encryption 1.1, among others:
and among most relevant to your question, changes to security considerations:
Added security consideration information on Chosen Ciphertext Attacks, including attacks against encrypted data and encrypted key. Provide specific notes on CBC Block Encryption vulnerability, and the Bleichenbacher attack.
The article you were reading is about exploiting a weakness in the CBC mode for the chaining of different ciphertext blocks. While it does appear to be the real thing, it applies to encryption schemes before XML Encryption 1.1:
“We were able to decrypt data by sending modified ciphertexts to the server, by gathering information from the received error messages.” The attack was tested against a popular open source implementation of XML Encryption, and against the implementations of companies that responded to the responsible disclosure – in all cases the result was the same: the attack works, XML Encryption is not secure.
While I don't see this as exaggeration, and it doesn't strike me as surprising either (see for example this answer to the question How less secure is an encryption if we know something about the original data? and Wiki on Adaptive chosen-ciphertext attack), it needs to be mentioned again that it applies to CBC encryption mode avalable in XML Encryption 1.0 that was handled by a different W3C workgroup (XML Encryption WG last active in 2008).
This work has by now been moved to XML Security Working Group whose baby is XML Encryption 1.1 as a direct answer to such attacks as described in the article. In fact, The XML Security Working Group even directly mentions these attacks on XML Encryption 1.0 in the XML Encryption 1.1 documentation.
Addendum: Whilst reading through some non-related cryptography articles, I've stumbled across Matthew Green's blog post on Attack of the week: XML Encryption dating back to October, 2011. Matthew Green is a cryptographer and research professor at Johns Hopkins University, and writes most fabulous texts on cryptography and related subjects. His explanation of what this attack on XML Encryption is all about is the best one I've yet read, and of course a recommended read for anyone interested to learn more about them. Here's a short excerpt:
Stop using unauthenticated CBC mode. Stop using any encryption standard designed before 2003 that hasn't been carefully analyzed and recently updated. Stop using any unauthenticated encryption at all. Wrap your SOAP connections with TLS (a recent version!) if you can.
I think it will be helpful if I add a comment to this answer, including the current state.
Adaptive-Chosen Ciphertext Attacks:
The attacks applied on XML Encryption are adaptive chosen-ciphertext attacks. In an adaptive chosen-ciphertext attack scenario the attacker takes the original ciphertext, modifies it, and sends to the server. He then evaluates the server response, which allows him to decide if the underlying plaintext was valid or not. He repeats this several times which allows him to decrypt the whole message.
These attacks are e.g. applicable to CBC schemes (Cipher Block Chaining mode of operation), which is still standardized by XML Encryption or many other standards. CBC (AES-CBC or 3DES-CBC) allows to modify plaintexts in the ciphertext, without knowing the encryption key. More specifically, the attacker is able to flip specific bits in the plaintext (I am not going into details, please read the paper or the blogpost by Matt Green mentioned in the first answer). If certain bits in the plaintext are flipped, the attacker produces a message, which can not be processed by XML parser. Other bits result in valid plaintexts.
Attack Prerequisites: There are two prerequisites for executing the attack. First, the attacker has to be able to modify the ciphertexts and force the server to process them. Second, the attacker has to have an information if the decrypted modified ciphertext was valid or not. This is typically possible since the server responds with a different error message if the modified ciphertext was valid and with a different message if it was invalid (there are also other ways to distinguish valid or invalid messages, e.g. by measuring response times).
Ok, but XML Signatures should secure integrity... Yes, we have the XML Signature standard which allows to secure integrity of the XML messages. This theoretically mitigates the attacks since the ciphertexts can be signed. This prevents ciphertext modification (the first attack prerequisite).
However, in all the tested frameworks, it was possible to apply this attack even if XML Signatures were applied. In short, a typical XML Signature secures only a part of an XML message. We were able to place the modified ciphertexts into parts, which were not signed. Even if they were not signed, the frameworks processed and decrypted them.
This was not considered by the XML Encryption standard and is now addressed in the newest version, including a secure encryption scheme AES-GCM: http://www.w3.org/TR/xmlenc-core1/
Frameworks we analyzed: We analyzed some frameworks and found out they were vulnerable to the attacks. For example Apache Axis2, JBossWS, Apache CXF, or some SAML frameworks. The attacks worked, even if the XML Signatures were used.
Countermeasures: As mentioned in the first answer, there are several countermeasures listed in the newest standard. If you design or use XML Security, your server should carefully check if the ciphertexts were signed. If the message contains an unsigned ciphertext, the message should be rejected. This is how it was implemented now in Apache CXF. Another possibility is to use AES-GCM...
For more information, you can take a look at my thesis, which summarizes all the attacks (including attacks on RSA PKCS#1 v1.5) and provides several countermesures: http://www.nds.rub.de/research/publications/xmlinsecurity/
Current state: With the presented countermeasures, it is possible to deploy a system secure against adaptive chosen-ciphertext attacks. We did several pentests and we saw many systems, where we were not able to apply these attacks.
I think XML Encryption (together with XML Signature) is a great standard supporting so many confidentiality scenarios. But you have to pay attention how you configure your system (I am not sure the frameworks are secure by default).
UPDATE
We released a plugin for our WS-Attacker framework to test for vulnerabilities in Web Services using XML Encryption: http://web-in-security.blogspot.de/2015/05/how-to-attack-xml-encryption-in-ibm.html
We presented our new paper: How to Break XML Encryption - Automatically: https://www.nds.rub.de/research/publications/how-to-break-xml-encryption-automatically/ There, we analyzed also the WCF framework.
