🧪 Labs › Cryptography
RSA & Signature Verification Flaws
Severity: High
A signature check that's lenient in the wrong place lets forged data through.
What it is
Public-key signatures prove a message came from the holder of a private key — but only if verification is strict. Real deployments get it wrong: accepting a signature without checking the algorithm, mishandling padding so a forged signature validates, or trusting a key the message itself supplies.
The result is forged tokens, tampered updates, or bypassed authentication, with no access to the private key.
As with the others here, the maths holds; the verification logic doesn't.
How to approach it
- Find where the app verifies a signature and what it checks — algorithm, padding, which key.
- Test whether it will accept a message you altered, or a signature you crafted under relaxed assumptions.
- Look at whether the verifier trusts attacker-influenced parameters (the algorithm, the key reference).
- Reason from a lenient check to a forgeable message.
Your task
Get the application to accept a message whose signature you forged or altered.
▶ 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
- Pin the algorithm and key; reject anything the message tries to choose for you.
- Use vetted libraries and strict, constant-time verification with correct padding checks.
- Never trust a key supplied alongside the data it signs.
More Cryptography labs
- Padding Oracle — An app that tells you whether a decryption 'looked right' leaks the plaintext, one byte at a time.
- Weak Keys & Predictable Randomness — A secret that's short, guessable, or generated predictably isn't a secret.
- Hash Misuse — Hashes used the wrong way — for integrity, for passwords, for tokens — break in predictable ways.