POODLE - The man-in-the-middle attack on SSLv3

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?
POODLE is a man-in-the-middle attack that forces modern clients (browsers) and servers (websites) to downgrade the security protocol to SSLv3 from TLSv1.0 or higher. This is done by interrupting the handshake between the client and server; resulting in the retry of the handshake with earlier protocol versions. For example, if an attacker interrupts a secure connection between a browser and a website that is using TLSv1.0, when the browser retries to establish the connection to the server, it will use the next lower level protocol (SSLv3 in this example). Once the protocol downgrade is successful, the attacker can exploit the vulnerabilities in SSLv3 to compromise (decrypt) the session. To successfully exploit the POODLE vulnerability, a hacker must either be on the same network of the client (browser) or server (website) or be able to successfully execute malicious JavaScript.

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.

Learn More
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. 

The vulnerability itself requires a man in the middle like situation (via malicious javascript, an actual MiTM, etc ) where the attacker can decrypt SSL based traffic using the Oracle side channel padding attack. For example, if the cookie is CBC encrypted using 3DES we can break it into 8 bytes blocks (16 byte blocks if AES) and add a (MAC) Message Authentication Code with 8 bytes of padding: 

   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. 

More info: