One of the biggest security announcements in the last year was definitely the POODLE (Padding Oracle On Downgraded Legacy Encryption) vulnerability, which marked the real end of SSLv3. In a contrast with many other previously identified vulnerabilities in encryption algorithms used by SSLv3, this vulnerability is viable, and can be exploited by an attacker without jumping over too many obstacles or requiring large resources – the POODLE vulnerability is real.

While this raised quite a bit of panic (in some cases the panic was justified) it also raised quite a bit of dust where it should not have had. The goal of this diary is therefore to clear things up a bit, to allow you to make proper risk assessment on moving away from SSLv3 – please do add comments and your experiences (and any corrections, if you find errors).

A little refresher

First, though, a little refresher on how the POODLE vulnerability works. The original paper is available at https://www.openssl.org/~bodo/ssl-poodle.pdf, however I will explain couple of details which are, in my opinion, crucial for this attack and that maybe have not been stressed out as they should have in this paper (my personal opinion is that the steps related to the attack should have been better explained since that would allow people to easily assess the risk).

The vulnerability exists in the fact that, when a CBC encryption algorithms is used, SSLv3 does not cover padding with MAC (Message Authentication Code). Additionally (and this is the key), when there is an entire block of padding, SSLv3 checks only the last byte in the padding block. All other, previous bytes in that block are ignore and the value of the last byte must be equal to the block size (i.e. 15, when the block size is 16 bytes).

If an attacker wants to exploit this vulnerability, he first must perform the following actions:

• Successfully run a Man-in-the-Middle attack against the victim,
• Downgrade connection to SSLv3, if TLS is used as well, for example,

If the requirements above have been fulfilled, the attack is relatively simple, and the attacker must do the following:

• Position the byte he wants to recover as the last byte of a block. This is a critical requirement as we will see later.
• Copy that block as the last (padding) block.

Now the attacker uses the server as the oracle depending on messages received back. The server will try to decrypt the message and when decrypting the last block, due to the CBC encryption algorithm, after the decryption, the last byte will be XOR-ed with the last byte of the previous block. As we used an entire block of padding, the attacker knows that result of this process must be 15. In other words, if the decryption was successful, the attacker can obtain the plain text value of that byte since he can easily calculate it: the decrypted byte = 15 XOR (the last byte of the previous block).

How does the attacker know if the decryption was successful? It’s simple: by observing network traffic from the server:

• If the decryption failed (and this means that the result was not 15), the attacker will see Alert Code 21, which means “Decryption failed” (the description says: Decryption of a TLSCiphertext record is decrypted in an invalid way: either it was not an even multiple of the block length or its padding values, when checked, were not correct. This message is always fatal.)
• If the decryption was successful, the attacker can decrypt the byte. The action that the request will cause does not really matter.

All the attacker needs to do now is cause the victim to issue multiple requests. In average – he will need 256 request to decrypt a single byte (but notice that it might take him much more – or less requests to do this). By causing the victim to issue arbitrary requests, the attacker decrypts his wanted data (usually a session cookie in web applications) byte by byte.

Practicality of POODLE attacks

As you can see in the previous section, there is a number of requirements that the attacker needs to fulfill to execute POODLE attacks. One of the most important is to make the victim issue arbitrary requests to the server. The attacker must somehow be able to influence these requests – the byte he wants to decrypt must be the last byte in a block.
With web applications this is relatively easy – since the attacker must be in a MitM position anyway, he can make the victim’s browser issue such special requests (for more details see the original paper).

However, and this is the crucial point of assessing the risk of POODLE – what happens if the attacker cannot influence such requests? Well, according to current information, he will be able to decrypt only single pre-positioned bytes.

While this is still bad, the risk might be lower than with a standard web application. And this is the main point of assessing the risk: in last couple of months I’ve seen simply too many cases when an auditor (or a penetration tester) ran a tool which reported that SSLv3 is enabled and blindly marked this as a critical vulnerability that has to be mitigated as soon as possible.

One of the typical cases of such detections are client-server applications that use SSLv3 to protect data, but that do not allow the attacker to modify the requests (for example: monitoring systems). Such systems always issue same requests, and they do this automatically so the attacker cannot modify the request (the plain text version of it), as he can with web applications.

So, to wrap up this already long diary – always assess risk properly and do not accept results of automated scanners blindly. While the POODLE vulnerability is indeed a severe and critical vulnerability, and we should move to TLS (v1.2 if possible), the migration should be staged and carefully planned.

--
Bojan
@bojanz
​INFIGO IS