First it was Heartbleed, then Shellshock, now POODLE…while the names are intriguing, the focus of these security vulnerabilities is on how broad the exposure is, what is required to build the right protection, and how long the exposure may have been exploited for.
What is it?
POODLE (Padding Oracle On Downgraded Legacy Encryption) is a security vulnerability that forces the downgrade of negotiated session protocol to SSLv3, a legacy protocol used to establish secure web communication (HTTPS). The good news is that the attack vectors to exploit the vulnerability are limited and several client and servers restrict the use of SSLv3 (SSLv3 is a 15-year-old protocol that has been replaced by the TLS protocol). The bad news is that if vulnerable, a man-in-the-middle attack can be executed to compromise the encrypted session.
How Does the Exploit Work?
To effectively protect your environment, remediation should be focused at both the client and server perspective. The quickest and simplest method for immediate remediation is to disable SSLv3 within your web server (Apache, IIS etc) and/or client (ideally both). This will make the exploit totally ineffective. Keep in mind that if you disable the SSLv3 support on the server-side, some legacy clients may not be able to establish a connection. If you disable it on the client-side, you may not be able to connect to some servers that only support SSLv3. For these legacy systems that only support SSLv3, you need to strongly consider having the system updated to support more current, and secure, protocols such as TLSv1.0, 1.1, or 1.2.
For the more technically oriented folks, here is more info….The poodle attack is an attack against the SSLv3 protocol which may allow attackers to decrypt SSLv3 requests into plaintext. The exploitation of the bug capitalizes off the fact that when working with legacy servers, most TLS clients will downgrade each time a secure handshake fails.
GET / HT | TP/1.1\r\n | Cookie: | cookies! | \r\n\r\nxxxx | Mac Data |01234567
The attacker can only see the CBC encrypted data, but if he/she duplicates the block containing the cookie data and overwrites the last block with it, the receiver decrypts the last block. It then XORs the contents of the previous data which the attacker knows. Since SSLv3 doesn’t do any checks on the contents of the padding, the receiver cannot validate it and the record is accepted if the last byte ends up as a seven. So if we append to the request a little:
GET /a H | TTP/1.1\r| \nCookie:| cookies|!\r\n\r\nxxx| Mac Data|01234567
GET /aa |HTTP/1.1 | \r\nCookie:| cookie| s!\r\n\r\nxx| Mac Data|01234567
The attacker can read part of the request that has the cookie in it. The attacker can keep appending to the request and decode the cookie one byte at a time.
At the time the only mitigation is to stop using SSLv3. There is no workaround for the simple reason that receiver cannot validate the record it receives.