So, what's going on here is that SSL 3.0 has a vulnerability in the way it uses cipher block chaining encryption and the padding it applies to plain text messages before it goes through that encryption. POODLE, which stands for Padding Oracle On Downgraded Legacy Encryption, is the attack that exploits this vulnerability. An attacker who is conducting a man in the middle attack, between a victim client and a victim server, who may also need to conduct a downgrade attack to force that client and server to use SSL 3.0 when they might be supporting, let's say, TLS.1, they can start capturing encrypted streams of data from the client and then tweaking just one portion of that encrypted data, just modifying it and moving it around. They send that modified data off to the web server and wait to see how the web server handles it. Two-hundred and fifty-five out of 256 times, on average, the web server is going to reject that request. It will see it as malformed or as erroneous and it will drop it but one out of 256 times, it will accept it and when that victim server accepts the modified request, the attacker is able to decrypt or determine one byte of plain text information from that encrypted stream they modified.
This might sound pretty minor. It's just one byte and it could take 256 tries to successfully get that one byte but, given some automation and given enough time, it's feasible for an attacker to slowly, byte by byte, reconstruct a stream of encrypted information into its decrypted, plain text counterpart.
Now, the reason why this is so bad is, if you have, let's say, a victim client trying to connect to their banking site to conduct some online banking, if an attacker pulls off POODLE, they could potentially steal the victim's session token to their authenticated session on the banking site, which gives the attacker access to withdraw money, deposit money, change settings, change passwords, do whatever in the context of the victim. This doesn't just affect HTTPS. This affects any protocol that uses or supports SSL 3.0, such as SMTP or even VPNs that use SSL VPNs.
The extent of this vulnerability is pretty broad. SSL 3.0 has been around since about 1996 and support for it hasn't really gone away. There's been no good reason to not support SSL 3.0 until today. So, even though many browsers support SSL 3.0, TSL 1.0, 1.1, and 1.2, attackers can conduct a man in the middle attack and force a client using Firefox, let's say, or Chrome, to renegotiate down from TSL 1.2 to SSL 3.0 and use that weak, vulnerable protocol when they communicate with a server.
How do we fix this? How do we test that we fixed it? The main radiation technique to focus on is just completely disabling SSL 3.0 support in any software you have or make. So, whether it's a web browser, web server, an API, we want to move away from SSL 3.0 and only support TSL 1.0, 1.1, and 1.2. This can create problems, though, if these remediation techniques aren't tested properly. You could create issues with how APIs are communicating with other software. You can create issues with users who are using very old web browsers that are trying to access websites that no longer support SSL 3.0 when their web browser only supports SSL 3.0. However, this is the best mediation technique. We have to move away from SSL 3.0.
There is another mitigation technique that can be used. There's a mechanism called TLS fallback SCSV that can help mitigate the success of these downgrade attacks from recurring. So, if an attackers doing a man in the middle attack and they try to force a client down from TLS 1.2 to SSL 3.0, skipping TLS 1.1 and 1.0, this TLS fallback mechanism will require that the client and the server try TLS 1.1 and then 1.0 and move in sequence like that, rather than skipping all lesser versions of TLS to get to SSL 3.0.
Once you have remediated this in your environment, you can test it with an expose today. We have updated vulnerability checks. The CV ID for this SSL vulnerability is CVE-2014-3566. There are updated meta-sploit modules to test the effectiveness of your remediation techniques and some of our other products, like user insight, for example, we've remediated the web console so that it will no longer allow SSL 3.0 connections from clients.
Otherwise, our page here, Rapid7.com/Poodle will be updated with more information as we learn more about this vulnerability and how it affects the community at large and various products, services, and industries. Thanks again for joining us today and we'll see you next week.
