How the POODLE Attack Spelled the End of SSL 3.0

What Is a Padding Oracle?

Let’s start with the first half of POODLE: the padding oracle attack. Block ciphers such as AES can only encrypt and decrypt fixed-size blocks of data, so each message needs to be divided into blocks. Padding is added at the end to make sure that the message length is a multiple of the block size.

Padding oracle attacks exploit a flaw in the padding validation algorithm to reveal information from encrypted messages. This is done by analyzing message block padding and asking the “oracle” (usually a vulnerable web server) if the supplied padding is correct. By repeating such yes/no questions, the attacker can reveal the plaintext message far more quickly than with a brute force attack.

What About Downgraded Legacy Encryption?

The POODLE attack relies on forcing the victim’s browser to downgrade the connection protocol to an older, vulnerable version: SSL v3.0. Introduced in 1996, this was the first widely-used protocol for encrypted web communication. By 2014, it had been superseded by TLS (Transport Layer Security) but was still supported by web servers as a legacy fallback. This was mostly because it was the only SSL/TLS protocol that could be used by older versions of Internet Explorer.

When a web browser and web server connect over HTTPS, they negotiate a secure protocol supported by both sides. Protocol downgrade attacks exploit support for older protocol versions to force the server to use a vulnerable protocol for HTTPS communication. In 2014, modern web servers would default to using at least TLS 1.0 but fall back to SSL v3.0 if requested. The POODLE vulnerability allowed a man-in-the-middle attacker (for example on a public Wi-Fi hotspot) to downgrade the connection from TLS to SSL v3.0 and then mount a padding oracle attack on the vulnerable SSL protocol.

How the POODLE Attack Works

In many ways, the attack on SSL v3.0 is similar to the BEAST attack against TLS 1.0 which we wrote about a few months ago. Both attacks exploit a flaw in the cryptographic algorithm that makes small parts of the encrypted message recoverable without decryption. The flaws and protocols are different, but both attacks target block ciphers in CBC (cipher block chaining) mode.

As already mentioned, block ciphers work by dividing a message into fixed-sized blocks which are then encrypted and combined. There are several block cipher modes of operation that determine how the blocks are combined to generate the whole encrypted message. In CBC encryption, each block of plaintext is combined using XOR with the previous encrypted block and then encrypted using a secret key. Decryption in CBC mode is done in reverse order: by decrypting each block and then XORing it with the previous one. If there is no previous block, the algorithm uses a random value called an initialization vector.

Plaintext messages are padded to make sure their length is a multiple of block size, but – and this is the important part – SSL v3.0 does not specify the padding content. The only requirement is that the last byte must indicate the padding length. The padding is not checked, so as long as the length is correct, the padding block will be accepted by the receiver. In addition, the message authentication code (MAC) included in every SSL v3.0 request is calculated only for the plaintext message, not including padding. In terms of security, all this means that the integrity of the padding bytes is not assured – and this is what provides a foothold for the attacker.

To start recovering information, such as a session cookie, the attacker must know where in the encrypted message it is. HTTP requests are easy prey because they have a predictable format and a MITM attacker already knows most of the header content, so it is not difficult to spoof a request where the session cookie occupies a specific block.

The length of the crafted request is a multiple of the block size, so the last block contains only padding and the padding length. For example, if the block size is 8 and the message length is a multiple of 8, the last block will contain 7 bytes of padding and the value 07. Knowing that only the last byte of the last block is checked, the attacker can replace the last block with the cookie block and send this request to the receiver to try and guess the last byte of the cookie.

Now we get to the oracle part: the receiver’s response tells the attacker if the last byte of the cookie block is correct. If the receiver rejects the request, this means “no”. The attacker can then modify the request by shifting the encrypted cookie value by one byte and try again. The next response indicates if the last-but-one byte of the cookie is correct. This is repeated until the request is accepted, which means a “yes” answer. Because the MITM attacker knows the previous encrypted block, a simple XOR is then enough to discover one byte of the cookie – and all in no more than 256 requests.

Preventing POODLE and Other Downgrade Attacks

The chances of brute-forcing SSL v3.0 encryption are astronomical, but with the POODLE attack, each byte of an SSL v3.0 encrypted message could be recovered without decryption after a maximum of 256 attempts. For a 16-byte session cookie, this means no more than 4096 attempts, or just a few minutes, which is quite enough to mount real-life attacks. Something had to be done – and fast.

The POODLE vulnerability was disclosed on October 14th, 2014, and assigned the CVE-ID CVE-2014-3566. While the obvious solution was simply to disable the obsolete SSL v3.0 protocol in web browsers and servers, back in 2014, that would still break a lot of sites and legacy systems. Because the attack only works for block ciphers in CBC mode, one option (already used to mitigate the earlier BEAST attack) was to simply remove support for vulnerable ciphers and use others available in SSL v3.0. Unfortunately, this only left the RC4 stream cipher, which by then was also proven to be vulnerable.

An interim solution recommended by the POODLE researchers was to use the TLS_FALLBACK_SCSV cipher suite value to provide fallback capability but prevent forced downgrading to a less secure SSL/TLS protocol. This prevented protocol downgrade attacks while retaining support for legacy browsers and servers. Vendors and website operators moved quickly to implement TLS_FALLBACK_SCSV while also removing support for SSL v3.0 immediately or within the next few months. In June 2015, SSL v3.0 was officially deprecated by RFC 7568.

POODLE Today

Despite definitive proof that SSL v3.0 was insecure, it persisted in legacy systems, especially internal applications that still relied on old versions of Internet Explorer. While certainly a realistic threat, the POODLE attack could only be mounted in a man-in-the-middle scenario, so upgrading to a more secure protocol was often not worth breaking legacy support. In fact, recent research shows that as of 2020, up to 4% of public web servers still support SSL v3.0.

POODLE is one of many vulnerabilities detected by Invicti. If SSL v3.0 support is detected on the web server, Invicti reports the vulnerability and suggests remedies to disable support for insecure SSL/TLS protocols in several popular web servers.