Software Integrity

 

POODLE: Yet another attack on SSLv3 (SSL 3.0)

POODLE Introduction

The POODLE (Padding Attack On Downgraded Legacy Encryption) attack was published by Bodo Möller, Thai Duong, and Krzysztof Kotowicz of Google in a security advisory last month (September 2014). The attack is on SSL 3.0 (SSLv3), an obsolete and insecure protocol, and allows an attacker to decrypt authentication cookies for websites. To exploit this vulnerability, the attacker must possess the following capabilities:

    1. The attacker must control the connection between the client and the server, and
    2. The attacker must be able to inject code into the browser (e.g.

JavaScript

    code) of the victim to be able to launch the attack successfully.

The capability to control the connection between the client and the server is required because an attacker needs to somehow force the client and the server to agree to use the SSL 3.0 protocol. An attacker can do this by tampering with the SSL negotiation process. SSL handshake will try to use the most recently supported version of TLS (starting with say TLS 1.2) at both the client and the server. However, for compatibility reasons, many clients have implemented a fallback mechanism that lets them retry a failed negotiation by using an older version. If an attacker interferes with the SSL negotiation process to disrupt it, the client will then fallback successively to TLS 1.1, TLS 1.0, and finally to SSL 3.0.

Note that, in the past, attacks such as BEAST, CRIME, and Lucky-13 have been discovered against SSL 3.0 protocol. Poodle, like BEAST, requires the capability to inject code into the victim’s browser. But, while there was an acceptable workaround solution for the prior attacks, there is no reasonable work around for POODLE. The only workaround is to not use SSL 3.0, period.

Anatomy of the Attack

The attack is possible due to two SSL design flaws:

  1. SSL uses the MAC-THEN-ENCRYPT mode of authenticated encryption. This means a receiver has to decrypt the message before applying the MAC integrity check. This allows an attacker to change the ciphertext to launch active attacks to learn more about the plaintext.
  2. SSL 3.0 padding definition is incomplete. When SSL 3.0 is used with a block cipher CBC mode of encryption, the SSL implementations must add padding bytes to make the total data (that includes the plaintext and the MAC of the plaintext) integral number of cipher blocks in length. The padding can be, as a result, at the most one cipher block in length. SSL 3.0 defines only the last byte of the padding. It does not define what the rest of the bytes of the padding need to be. And therein lies the second design problem.

An attacker can exploit the above two design flaws as follows.

Let us say that we have a plaintext message. Before the SSL 3.0 protocol encrypts this plaintext message, it first creates a MAC and appends the MAC to the message. Padding is then added at the end to make the message an integral number of blocks in length. Note if the plaintext message and the MAC are exactly integral number of blocks in length, then a full padding block is added. This is shown in the diagram below.

Poodle Plain Text

Assuming the block size is 16 bytes long (if one is using AES encryption as an example) as in the above example the last byte of the padding block will have a value of 15. All other bytes of the padding block are not defined and could be any value.

Once encrypted with a key K and an initialization vector IV, the plaintext message will be converted into a series of ciphertext blocks as shown below. IV is not shown in the diagram below.

Poodle-Cipher Text

In the CBC mode, the decryption works as follows:

* For any block Ci, its decryption is given by Decrypt(K, Ci) XOR Ci-1, where C0 = IV

Now we know that the last ciphertext block, when decrypted, will yield the padding block (whose last byte has a value of 15). We could now exploit this fact as follows:

    1. Suppose we want to know the plaintext corresponding to block C3, we would send a message of such length that it requires a full padding block to the server with block C3 copied as the last block (in lieu of Cn). The attacker needs to fix the padding block to a known length, e.g., 16 bytes in this case, to know the value of the last byte. This could be done by varying “attacker padding” in the plaintext request.
    2. The server will either accept this request or reject it based on whether the padding is correct – meaning whether the last byte of the padding block has a value of 15.
    3. In the CBC mode of encryption, the decryption of the new last block will be

Decrypt(K, C3) XOR Cn-1

    4. Usually the server will reject the request since the last byte will not be 15 (if the last byte is not in the range of 0..15, the server will reject the message outright. If it is in the 0..15 range, the server will strip those many bytes of padding and then proceed to validate the MAC, which will fail)
    5. If the attacker makes the same request (although the request is same, the ciphertext will be randomized due to random IV) over and over again, then on an average every 256 requests it will find that the server will accept the request. The plaintext content of block C3 doesn’t change between requests, but it is XORed with C

n-1

      which does change between requests, and the server will accept the request when these two happen to align such that it results in a valid padding length byte, e.g. 15. In such cases the attacker knows the last byte of the decrypted message must be 15. The attacker can use the above fact to find out the last byte of the plaintext corresponding to the block C3 as follows:

P3[15] = Cn-1[15] XOR C2[15] XOR 15

    6. Now that the attacker has figured out one byte of plaintext, the attacker can effectively shift the plaintext message by one byte (by adding a fake byte at the beginning and removing a byte somewhere after the targeted block to maintain the same message length) such that the next byte of interest in the C3 block is in the last position.
    7. The process repeats itself until the entire message or part of the message is decrypted.

In the simplest scenario, an attacker can run JavaScript in one origin in a browser and cause the browser to make requests to other origin. The injected Javascript code has complete control over the path and the body of the HTTP request. This injected code can now “manage” the length of the path and the body to ensure that the plaintext plus the MAC will result in one full padding block when SSL 3.0 encrypts the request. The browser will do “its thing” and send cookies with the request. The attacker, who also controls the client-server connection, can now launch this attack by duplicating the block of interest (as the last block). If the receiver accepts the record then the attacker knows last byte of the cookie using (on average) 256 requests. Since the attacker has complete control over the path and the body of the message, it can shift and align content to create a full padding block.

Impact of a POODLE Attack

Although the POODLE attack is easier to launch than the BEAST attack (against SSL 3.0), it is not as serious as say, the HeartBleed attack. The reason it is less severe is because it only works against the SSL 3.0 protocol allowing an attacker to decrypt sensitive HTTP header data such as the session IDs stored in HTTP cookies. SSL 3.0 is by now largely superseded by TLS 1.x versions of the protocol. However, due to legacy reasons (support for IE-6 being one of the primary reasons), many web servers still support the SSL 3.0 protocol. The same is the case for many browsers; most browsers today support SSL 3.0 protocol.

Attack Mitigation

As already stated, there is no reasonable workaround for this issue. The only mitigation is to not use the SSL 3.0 protocol. There are three methods of achieving this:

      1. Disable SSL 3.0 support from your browsers. There are many browsers and their variants and there are a number of resources on the Internet that cover this topic.

https://zmap.io/sslv3/browsers.html

    for help on disabling SSL 3.0 in your browser.
      2. Disable SSL 3.0 support in your web server. Again, there are many different types of web servers and please refer to server documentation on how to disable SSLv3 (or SSL 3.0) support.
      3. Finally, in the long term, using the TLS_FALLBACK_SCSV mechanism guarantees that the SSL negotiation never falls back to a lower version than the highest supported by the server and thereby prevents an attacker from downgrading the connection to legacy SSL 3.0 instead of TLS 1.0 or higher. Google Chrome and server support this feature since February 2014 and it is likely that other browsers and servers will support this feature in due time. SSL-Labs (www.sssllabs.com) is a good resource for checking SSLv3 support in browsers and servers.

A commonly asked question is – if this attack is against the CBC mode of encryption can this be resolved if we were to use RC4 instead of AES in our cipher suite? The simple answer is – RC4 has since been proven to be much less secure in SSL/TLS than previously known and it’s generally not recommended to use it. For example, BEAST is nowadays mitigated on the client-side by record splitting, it has been suggested that POODLE could be mitigated in a similar way, but it’s better just to drop support of SSLv3 when you’re making changes anyway.