Posted by Chandu Ketkar on October 20, 2014
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:
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.
The attack is possible due to two SSL design flaws:
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.
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.
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:
Decrypt(K, C3) XOR Cn-1
P3 = Cn-1 XOR C2 XOR 15
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.
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:
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.
Get the latest Software Integrity news, thought leadership, and more.