The POODLE (Padding Oracle On Downgraded Legacy Encryption) attack is a fallback attack that tries to downgrade the used TLS protocol version to SSL 3.0. A POODLE attack can also be executed successfully against TLS protocol versions 1.0 – 1.2.
Learn how to prevent SSL POODLE in this article.
Table of contents
SSL POODLE Attack Security Assessment
CVSS Vector: AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N
SSL POODLE Vulnerability Information
The POODLE attack (Padding Oracle On Downgraded Legacy Encryption) was discovered by Bodo Möller, Thai Duong, and Krzysztof Kotowicz from the Google Security Team. It was announced publicly in October 2014 in a paper called This POODLE Bites: Exploiting The SSL 3.0 Fallback.
This attack is made up of two parts. A man-in-the-middle attack allows an attacker to force a connection between a server and a client to be downgraded from transport layer security (TLS) protocol encryption to SSL 3.0 encryption. This allows them to eavesdrop on the traffic between the client and the server and then decipher it.
The second part is a padding oracle attack that reveals the encrypted information (ciphertext) by repeatedly sending requests to a web server. This part of the attack exploits a security vulnerability in the CBC (cipher block chaining) encryption mode of SSL 3.0. Hence the need to downgrade that version of the protocol.
If a POODLE attack is successful, it allows an attacker to reveal sensitive data such as passwords, session cookies, or other authentication tokens that enable them to impersonate a user and gain access to a website. It can also lead to a leak of personal data, credit card numbers, and health records.
In other words, for a POODLE attack to be possible and succeed, several conditions need to be in place. Attackers must:
- Launch a successful man-in-the-middle attack (MITM) – which requires a certain set of circumstances in itself
- Send requests to the server by varying the input in order to exploit the CBC vulnerability
- Monitor the server responses and resulting ciphertext to decrypt the information and gain access
If attackers can execute all of these steps, a POODLE attack is successful. In total, it only takes several minutes to complete the attack, given that the above conditions are met.
Any system that supports SSL 3.0 with CBC or implements an SSL/TLS suite is vulnerable to this type of attack. In addition, systems that reference SSL/TLS libraries (such as OpenSSL) are also possible targets. Moreover, as of 2014, it has been found that TLS protocol version 1.0 – 1.2 are also vulnerable to a POODLE attack and are even easier targets because no fallback to SSL is required as part of the attack.
Check Your Web App for SSL/TLS Vulnerabilities
How does the POODLE Attack Work?
The two parts of the attack are described below.
The downgrade dance
The attack exploits the protocol version negotiation feature that is present in TLS and SSL implementations. This means that servers and clients using TLS can move back to using SSL when connecting to a system using SSL. I.e., they can shift to working with legacy systems using older protocol versions to improve interoperability and user experience.
An attacker exploits this feature to force a server to shift toward SSL 3.0, a downgrade dance or downgrade attack. The attacker achieves this downgrade by repeatedly launching attempts at secure connections with a server (handshake) and then dropping them.
After repeated connection failures, a server automatically will shift to an older protocol to accommodate the client who is supposedly trying to connect.
Block ciphers and CBC encryption
To understand the padding oracle, you must understand how CBC mode encryption works.
SSL and TLS protocols allow browsers and servers to use sets of encryption algorithms, also known as cipher suites. These cipher suites contain several different algorithms for varying purposes, among which are also so-called block ciphers such as Advanced Encryption Standard (AES) and Data Encryption Standard (DES).
When block ciphers are used, data is encrypted in blocks that have a fixed size. So to encrypt data, it must be divided into equal blocks. If the data in a block is not enough, padding is added. This padding is needed to ensure that the length of the data, or message, is equal to the standard block size, say 8 bytes or 16 bytes.
Cipher suites that are susceptible to a POODLE attack further use a cipher blockchain (CBC) encryption mode. This mode of data encryption functions as follows.
First, the plaintext, or message, is broken up into blocks. Then several bytes of padding or a whole padding block are added at the end to ensure that all blocks are of the same size. Finally, the plaintext in the first block is XORed with a random initialization vector (IV) that is unique to generate an intermediary value.
After that, the intermediary value is encrypted by feeding it into the block cipher (which produces ciphertext). Now the resulting block of ciphertext is used as the key (i.e., the initialization vector) in the next block, which is to be XORed with padded plaintext.
To decrypt the message, the order of this process must be reversed. When you decrypt one block, you must XOR it with the previous block. In this way, blocks are chained together, hence the name.
The padding oracle and CBC security vulnerability
The vulnerability in this type of encryption is due to a flaw in the padding validation in CBC. In SSL 3.0, which uses CBC, the padding bytes (the padding content) are not specified or checked. The only requirement is that the last byte of the previous block must indicate the padding length. If the length of the padding is correct, the server will accept the padding block.
Moreover, because SSL 3.0 uses MAC-then-encrypt, the plaintext message authentication code (MAC) is calculated before the padding and encryption. In other words, the padding or padding block is not secure, and this is what attackers exploit when conducting a padding oracle attack.
Since the attacker has already gained access to the communication between the client and the server through a man-in-the-middle, they are in possession of encrypted communication. HTTP POST requests have a defined structure, so the attacker knows where a session cookie is located. The attacker then modifies the encrypted data by forging a request that is a multiple of the block size. This request includes the session cookie in a specific block and has the necessary padding at the end that they know will be accepted. Finally, they send this request to the server, attempting to guess the value of the last byte of the cookie.
The server then responds by either confirming or declining the request. If the server rejects the request, the attacker has not guessed the value correctly. However, if the server accepts the request, the value of the last byte of the block is correct. Using XOR, the attacker can then combine the decrypted byte with the previous block, revealing the real (plaintext) last byte. By repeating this operation, they can guess the cookie byte-by-byte.
In summary, here is how a POODLE attack is executed, step by step:
2. The MITM attack allows them to eavesdrop on the communication between the client and the server and interfere and add input to this traffic. This communication remains encrypted, so the attacker has to cause the server to downgrade to SSL 3.0 to exploits its vulnerability.
3. After successfully causing the server to switch to SSL 3.0 through a protocol downgrade dance, the attacker can begin with the padding oracle attack.
4. The attacker exploits the SSL 3.0 padding vulnerability, which allows them to recover ciphertext by sending numerous cookie-bearing HTTP POST requests to the server with varying inputs in the last block of the request.
5. By monitoring server responses and varying the input, attackers can recover the contents byte-by-byte. One byte of the cookie typically takes no more than 256 attempts to be revealed, and for a 16-byte cookie, this equals a maximum of 4096 requests.
How to Prevent SSL POODLE Attack
To prevent the POODLE attack, SSL 3.0 support must be disabled from both servers and browsers, and a secure TLS configuration must be put in place that, ideally, supports TLS 1.2 or higher.
In addition, you must also make sure to enable TLS_FALLBACK_SCSV. This protocol extension guarantees that during a negotiation, the protocol never falls back to earlier protocol versions that are below the highest SSL or TLS version supported by the server.
Implementing TLS_FALLBACK_SCSV means that SSL is only used when an existing legacy system is involved and not a downgrade attack that forces the server to skip versions and downgrade to SSL 3.0. Effectively, this stops the forced downgrade from occurring and thereby the whole POODLE attack.