🧪 Labs › Cryptography
Padding Oracle
Severity: High
An app that tells you whether a decryption 'looked right' leaks the plaintext, one byte at a time.
What it is
Some block-cipher modes pad data to a block boundary. If an app decrypts attacker-supplied ciphertext and behaves differently when the padding is valid versus invalid — a distinct error, a different status, a timing difference — that difference is an oracle.
With the oracle, an attacker can decrypt ciphertext, and often forge valid ciphertext, without ever knowing the key. The cipher is sound; the usage leaks.
It's a classic example of a side channel turning strong crypto into no crypto.
How to approach it
- Find a value the app decrypts that you can modify — a token, a cookie, an encrypted parameter.
- Look for any observable difference between a submission that decrypts to valid padding and one that doesn't.
- That distinguishable response is the oracle; it lets you recover plaintext byte by byte.
- Reason about what the recovered or forged value lets you do.
Your task
Use the app's differing responses to recover the plaintext of an encrypted token without the key.
▶ Access the labOpens your hosted RatCTF instance. Work on it directly — there's nothing to submit here; you'll know when you've solved it.
How to prevent it
- Use authenticated encryption (AEAD) so tampered ciphertext is rejected before padding is ever checked.
- Return identical responses and timing for all decryption failures.
- Don't decrypt attacker-controlled data without verifying integrity first.
More Cryptography labs
- Weak Keys & Predictable Randomness — A secret that's short, guessable, or generated predictably isn't a secret.
- RSA & Signature Verification Flaws — A signature check that's lenient in the wrong place lets forged data through.
- Hash Misuse — Hashes used the wrong way — for integrity, for passwords, for tokens — break in predictable ways.