Padding Oracle Attacks in Detail

In CBC (Cipher Block Chaining) mode, decryption of each block involves decrypting the ciphertext block with the block cipher, then XORing the result with the previous ciphertext block. This XOR operation introduces a critical property: by modifying bits in a ciphertext block, an attacker can predictably affect specific bits in the decrypted plaintext of the following block. This property enables the padding oracle attack.

Block ciphers require input in fixed-size blocks. PKCS#7 padding fills the last block: if 3 bytes of padding are needed, add three bytes each with value 0x03. If the block is already full, add a complete padding block where all 16 bytes are 0x10. During decryption, the padding bytes are verified to be consistent (all N bytes have value N) and removed. If the padding is invalid, the decryption should fail.

A padding oracle is any system that reveals whether a decrypted ciphertext has valid PKCS#7 padding. The oracle can be: an explicit error message (Invalid padding), a different HTTP status code (500 vs 403), a different error response body, or even a timing difference (valid padding decryption is slightly faster). The attacker does not need to know the key; they only need this binary signal: valid padding or not.

The attacker targets a specific ciphertext block. To recover the last byte of plaintext: flip the last byte of the previous ciphertext block and send the modified ciphertext to the oracle. Iterate through 256 possible values until the oracle reports valid padding. At the value that produces valid padding (0x01), the intermediate decryption value is known (it XORed with the modified byte to produce 0x01). XOR with the original ciphertext byte reveals the plaintext byte.

Once the last byte is recovered, the next-to-last byte is targeted. The last byte's intermediate value is already known, so it can be forced to 0x02. Then iterate through 256 values for the next-to-last byte until padding 0x02 0x02 is valid. This process repeats for each byte, recovering a complete 16-byte block with 256 * 16 = 4,096 oracle queries on average per block. With a fast oracle, this can complete in seconds.

The process is repeated for each ciphertext block (except the IV, which cannot be recovered without the previous block). A 128-byte ciphertext (8 AES blocks) requires approximately 32,000 oracle queries on average to fully decrypt. Against a web server processing hundreds of requests per second, this takes minutes. The attacker recovers the full plaintext without ever learning the encryption key.

POODLE (Padding Oracle On Downgraded Legacy Encryption) exploited SSL 3.0's CBC padding validation. SSL 3.0 used a non-PKCS#7 padding scheme, but the attack adapted the oracle concept. An attacker who could inject content into an SSL 3.0 session and force clients to downgrade to SSL 3.0 could recover session cookies using the padding oracle technique. POODLE forced the deprecation of SSL 3.0.

Lucky Thirteen (2013) exploited a timing side channel in TLS's CBC MAC-then-encrypt scheme. The MAC verification timing differed by a few nanoseconds based on whether padding was valid, creating a timing oracle. BEAST (2011) exploited the predictable IV in TLS 1.0 CBC mode to mount a chosen-plaintext attack against session cookies. Both attacks demonstrated that CBC mode in TLS was fundamentally difficult to implement correctly.

The definitive defense against padding oracle attacks is to use AEAD (Authenticated Encryption with Associated Data) modes instead of CBC. AEAD modes like AES-256-GCM and ChaCha20-Poly1305 verify authentication before any decryption or padding check occurs. If the authentication tag is invalid, decryption never happens, and no padding information leaks. TLS 1.3 mandates AEAD and removes CBC entirely.

If AEAD is not available, the Encrypt-then-MAC construction adds a MAC over the ciphertext (not the plaintext). Before decryption or padding checking, the MAC is verified. If the MAC fails, the operation is aborted immediately without revealing any padding information. This must be done in constant time to prevent timing oracles. The MAC verification failure reveals nothing about whether padding would have been valid.

To test for padding oracle vulnerabilities: encrypt a known message, then submit a modified ciphertext to the application and observe the response. If valid and invalid padding produce observably different responses (error message, status code, response time), a padding oracle exists. Automated tools like padbuster and PadBuster specifically test for padding oracles in web applications by systematically modifying ciphertexts and analyzing responses.

What does a padding oracle attack require from the target system to decrypt ciphertext without the key?

Padding oracle recap: CBC decryption XOR property allows controlled plaintext byte manipulation, PKCS#7 padding validation reveals a binary oracle, attacker iterates byte values and observes valid/invalid responses to recover plaintext byte by byte, real exploits include POODLE, Lucky Thirteen, and BEAST, defense is switching to AEAD (GCM, ChaCha20-Poly1305) which verifies authentication before decryption.