# How does a Padding Oracle Attack work in practice?

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.

• Thanks; your explanation is great but I somehow get confused a bit. So, the cipher text is sent to the client and again back to the server? I see the cipher text seems to be sent back and forth, right? – Minaj Aug 29 '16 at 21:39
• Yes, instead of storing the correct answer somewhere on the server, the server encrypts it and hands it to the client. The client brings the ciphertext back to the server along with the candidate puzzle solution. So yes, it goes back and forth. The server is sending an encrypted message to its future self, using the client as the channel. – Mikero Aug 30 '16 at 1:50
• For this to work, the Captcha service would have to accept many failed attempts without undertaking defensive measures, right? Also, can you please clarify on how sending the cipher text to the client is much less complex (and hence preferable) for the server than keeping the unencrypted solution at the server side? – Minaj Aug 30 '16 at 15:57

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.

• Posted to show a more enterprise level attack in addition to the attacks descibed by Mikero (excellent answer). – Maarten Bodewes Aug 29 '16 at 7:41