Part 2:
Vaudenays Zombie
TLS Handshake done, we have a shared secret and transmit data between server and client.
Different methods
- Block cipher, HMAC authentication, CBC encryption.
- Stream cipher (RC4).
- Authenticated encryption mode: GCM or Poly1305 (TLS 1.2 only).
CBC/HMAC
Most common method until around 2013.
CBC/HMAC in TLS
AES-CBCEncrypt([Plaintext][MAC][Padding])
MAC-then-Pad-then-Encrypt
TLS Padding
0x00
0x01, 0x01
0x02, 0x02, 0x02
0x03, 0x03, 0x03, 0x03
CBC Decryption
CBC Padding Oracle
TLS 1.0 / 1.1 Error Alerts
bad_record_mac
decryption_failed
Padding Oracle via TLS Error Alerts
There's one Problem:
This attack doesn't work.
TLS Error Alerts are encrypted
CBC Padding Oracle attack works with timing
Let's have a look at TLS 1.2 again
Implementation note: Canvel et al. [CBCTIME] have demonstrated a timing attack on CBC padding based on the time required to compute the MAC. In order to defend against this attack, implementations MUST ensure that record processing time is essentially the same whether or not the padding is correct. In general, the best way to do this is to compute the MAC even if the padding is incorrect, and only then reject the packet. For instance, if the pad appears to be incorrect, the implementation might assume a zero-length pad and then compute the MAC. This leaves a small timing channel, since MAC performance depends to some extent on the size of the data fragment, but it is not believed to be large enough to be exploitable, due to the large block size of existing MACs and the small size of the timing signal.
We fixed it! Maybe... mostly...
Lucky Thirteen attack
Breaks TLS with the small timing side channel that is not believed to be large enough to be exploitable.Hard to fix
- The fix for Lucky Thirteen introduced another more serious padding oracle in OpenSSL (CVE-2016-2107)
- The fix in Amazon s2n didn't work (Lucky Microseconds)
Or just don't fix?
Bugs: The crypto/tls package only implements some countermeasures against Lucky13 attacks on CBC-mode encryption, and only on SHA1 variants.But let's forget timing for a moment
Timing errors are hard to exploit in practice.What if...
... there is an implementation that- sends a TLS Error Alert for one error type
- causes a TCP Reset for the other error type?
POODLEs, more POODLEs and friends
POODLE (2014)
The old SSL version 3 protocol didn't define the padding, it could be random.
That enabled a different variant of a padding oracle.
Why does POODLE matter?
Nobody would use SSL version 3 in 2013, right?Downgrade attacks
Browsers did out of protocol downgrade fallbacks due to broken implementations.It's a hillarious story, but I won't cover it today.
POODLE-TLS
Some servers don't check the padding.
More POODLEs?
It turns out some implementations only check parts of the padding.Checking Padding is hard
- GnuTLS had an off-by-two error.
- The authors of Lucky Thirteen discovered this, but thought it's an off-by-one-error.
- So an off-by-one error got "fixed" into an off-by-one error.
There are more things for servers to check
MACE
Some servers simply forgot to check the MAC...Or - of course - parts of the MAC
Finished message
Provides integrity over the handshake.
if you check it...
The Cryptographic Doom Principle
If you have to perform any cryptographic operation before verifying the MAC on a message you’ve received, it will somehow inevitably lead to doom.
More examples
- SSH vulnerability in MAC and Encrypt mode allows decrypting one byte, unfixable
- XML Encryption - character decoding error oracle/li>
- Apple iMessage vulnerability
- Owncloud - no authentication at all
The Fix:
Authenticated Encryption modes (AEADs)
Why don't people use authenticated encryption?
What do people teach at universities?
ECB, CBC, CFB, OFB, CTR
ECB, CBC, CFB, OFB, CTR
These five cipher modes are surprisingly popular in crypto introduction courses.
Why?
Is there a secret list somewhere that everyone uses as inspiration?
It turns out: Yes.
Padding Oracle conclusion
Just always use Authenticated Encryption modes