Breaking https:// with POODLE. How does it work?

This is an introduction to some basic concepts around how POODLE (Padding Oracle on downgraded legacy encryption) works. There are plenty of other blogs/videos that go into greater detail about how it works but the basics can help to provide a framework to navigate through the detail. 

Basically POODLE discovered that it was possible to decrypt some parts of encrypted SSL sessions via a man-in-the-middle. A victim can be vulnerable when using public wifi or if they have some nasty malware on their computers. 

1. Basics of Cipher Block Chaining 

During the SSL handshake, symmetric keys are exchanged to encrypt sessions. Sessions encrypted via the Cipher block chaining method are susceptible to what is known as a padding oracle attack. CBC is a method of symmetric block cipher cryptography. In CBC, a message is broken into 3 blocks of equal size blocks (eg 8 bit blocks). Each plaintext block is encrypted sequentially until you end up with 3 blocks of ciphertext. Before each block is encrypted, it is XOR’ed with the previous ciphertext block (the first block is XOR’ed with a block of random bytes known as IV) . To decrypt, this operation is reversed e.g.  Encrypted block is XOR’ed with the previous ciphertext block and then decrypted. This operation results in a very random block of ciphertext being produced every time. It is almost impossible to break however….

2. Padding in CBC

Most messages are not perfect block sizes of x bytes. Actually, messages may be of varying length. As block ciphers require the blocks to be of exact x bytes, extra padding (a string of random bytes) is added to fill up any unused bytes. The length of the padding is also stored as the last byte of the encrypted block. 

3. How padding checks can weaken security

Once the message is decrypted, servers undergo two checks. The first is to validate the padding length. If the padding length doesn’t match the actual padding, this will result in an error. The second check is a MAC on the encrypted block. This check verifies that the encrypted block hasn’t been altered during the transition.

This poses a problem. As the padding is checked before the MAC checks, a man-in-the-middle can intercept the message and try to guess what the padding length is. In only 255 guesses, he/she will be able to decrypt the last byte. 

4. Chosen ciphertext attack

If you recall, encrypted blocks are XOR’ed with the previous ciphertext block before it is decrypted. Therefore, you can substitute the last byte of the previous ciphertext block as many times as needed until the padding length is valid. Once that happens, you know you successfully guessed the padding length and cracked the last byte. You can also continue to decrypt more bytes using similar methods. 

5. What next? 

To stop padding oracle attacks, the server can provide more validation around the padding and also ensure that error messages don’t specify whether a failed session is caused by bad padding or a bad MAC.  Unfortunately, SSLv3 implementations don’t do this, which is why users should disable SSLv3. Whilst TLS does, on certain TLS implementations (e.g. TLSv1.0- TLSv1.1), a padding oracle may still be possible if there is significant time difference between sessions failing due to bad padding vs bad MAC. This can occur in certain server setups (e.g. when load balancing is used)

Want more information?

https://blog.skullsecurity.org/2013/padding-oracle-attacks-in-depth

http://www.limited-entropy.com/padding-oracle-attacks/