Padding Oracle Attack

A Padding Oracle lets you decrypt and forge data encrypted in CBC without knowing the key, by abusing the fact that the application reveals whether the padding of a decrypted text is valid. An oracle is any signal that tells "correct padding" from "corrupt padding" apart: a different error message, a different status code, or even a response-time variation. With that single binary answer, an attacker recovers the plaintext byte by byte.

The lever is how CBC chains blocks: each plaintext block is P_i = D(C_i) XOR C_{i-1}. Since we control the previous block C_{i-1}, we can tweak its bytes and watch when the oracle accepts the padding: at that moment we know D(C_i) for that byte and, XOR-ing with the original C_{i-1}, we deduce the plaintext byte. Repeated over every byte and block, the whole message is decrypted; and because the process also lets you compute the C_{i-1} that yields a chosen plaintext, you can encrypt arbitrary content (for instance, turn a user=guest cookie into user=admin). The standard tool automates both operations:

# decrypt a CBC-encrypted cookie (8-byte blocks)
padbuster http://<ip>/index.php <encrypted_cookie> 8 -cookies "auth=<encrypted_cookie>"
# forge a chosen plaintext -> new valid cookie
padbuster http://<ip>/index.php <encrypted_cookie> 8 -cookies "auth=<encrypted_cookie>" -plaintext "user=admin"

When there is no explicit error oracle but the cipher is weak, sometimes plain bit flipping is enough: if the user cdmin produces a ciphertext almost identical to admin's, you brute-force the block's bits with Intruder until the response length changes, a sign that a valid admin cookie has been obtained.

Requirements. The application must (1) use CBC with padding (PKCS#7) and no integrity check, and (2) distinguish, to the attacker, valid from invalid padding (different error, status or timing). Without that observable oracle the attack cannot start; with authenticated integrity (HMAC verified in constant time, or AEAD), neither.

How to detect it. The pattern is unmistakable in the log: thousands of requests with the same ciphertext except tiny mutations of one block, the vast majority returning the "invalid padding" error and a few the "valid" one. That volume of failed decryptions over a single token is what gives padbuster away; a WAF or a rate-limit on decryption errors cuts it off cold.

Defence. Do not entrust integrity to padding: authenticate the encryption (AES-GCM or another AEAD, or encrypt-then-MAC with an HMAC verified in constant time) before decrypting, so any tampering is rejected without revealing anything about the padding. Return a generic, identical error on decryption failure and rate-limit it. Data extracted this way, if hashes, still needs breaking: see hash cracking.