Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
I have understood how the padding oracle attack works in theory. Now, I am trying to visualize it in a real scenario.
Can someone please give a real scenario in which an attacker can insert himself in the channel and send cipher texts and be able to receive the error messages indicating success or failure of encryption? I am struggling to establish how this attack would work.
Here's a real-world example: A captcha service behaves as follows. First, it generates a distorted image of some known text $t$. It sends then image to a web browser, and waits for a response. It compares the response to $t$ to decide whether the captcha is successful.
In a stateful solution, the captcha service itself would have to store $t$ while the web browser would keep some sort of identifier. This leads to all sorts of bookkeeping by the captcha service.
A better approach is to make the captcha service stateless. To do this, you must store the correct solution $t$ to the captcha puzzle in the web browser client! Obviously this solution should be encrypted. The idea is to give the client an image and a ciphertext that encrypts the solution (under a key known only to the captcha service). The client presents the claimed solution along with the ciphertext, and the service just needs to decrypt in order to verify.
But nothing prevents the client from presenting some other ciphertext! This fact (along with poor choice of unauthenticated encryption and error messages leaking padding validity) has led to padding oracle attacks against captcha services. With a standard padding oracle attack you can actually systematically decrypt ciphertexts, hence obtain the captcha solution. Here is a video (loud annoying music) demonstrating a proof-of-concept on a real captcha service.
One protocol that is vulnerable all by itself is XML-enc, where enc of course means encryption.
The earlier versions do not have any support for authenticated encryption, defaulting to CBC with PKCS#7 padding. That means that any transport protocol using XML-enc is vulnerable to padding oracle attacks. That the ciphertext is wrapped within XML and base 64 encoding doesn't make any difference.
A paper has been written about a generalized plaintext oracle attack on the protocol.
Not long after it was found that the Glassfish and Tomcat WS-Security implementations were vulnerable to this attack even if the data was signed. What happened was that the attacker could simply leave out the signature. The data was then decrypted, and then deemed invalid by the upper layer as the signature was missing. Padding oracles happened before the signature was deemed missing.
Until this was patched all web applications relying on signed web services on these application servers were vulnerable, unless they also used TLS or - in my case - their own WS-Security implementation that checked the presence of the signature in advance.
