A few days ago, Google researchers announced a new vulnerability in SSLv3, dubbed the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack.
Although this vulnerability should be taken seriously, an attacker would actually need to do a lot of work to exploit it. Also, as a client side attack, it targets individual users connecting to a vulnerable server rather than the server itself, unlike the server-targeting Heartbleed vulnerability.
The POODLE attack is quite complicated, but essentially allows an attacker to gain access to an authenticated user’s session cookie, enabling the attacker to use this cookie to access the vulnerable site as an authenticated user. In order to exploit this vulnerability, all of the following conditions must be true:
1. A user needs to have already authenticated to the vulnerable site.
2. The attacker must place themselves in a position to see the encrypted traffic flowing between the user’s browser and the vulnerable site. The attacker must also be able to modify this data stream (i.e. a Man-in-the-Middle (MITM) attack).
4. The user’s browser must only support SSLv3 (and not TLS), the vulnerable server must only support SSLv3 (and not TLS), or the attacker would need to exploit some other vulnerability to cause the user to use SSLv3, rather than TLS (e.g. exploiting clients that use the downgrade dance).
Due to these conditions, the POODLE attack is not as easy as clicking a button to exploit a vulnerable server. As such, the exploitation of this vulnerability would be unlikely in most scenarios.
The most likely attack scenario occurs when a user authenticates to a particular site and has a session cookie assigned to them. This site or the user’s browser would need to support only SSLv3 (not TLS), or the attacker would need to exploit some other vulnerability to force the user to use SSLv3 (an uncommon scenario). However, if the user’s browser or the server do not support SSLv3, the attack will be unsuccessful. The attacker also needs to be on the same network as the user (e.g. an open wireless network), and needs to be able to modify the encrypted data stream between the user’s browser and the vulnerable server (through an MITM attack). The attacker needs to run a malicious script on the user’s system by getting the user to visit a malicious website, or by inserting a malicious script into a page that the user visits. Once the script is running on the user’s system, the script must continue to run until the attack is complete, which as noted above, could take a significant amount of time. Once the attack is finished, the attacker then can use the authenticated user’s session cookie to access the website as the authenticated user.
The best way to remediate this vulnerability is simply disabling SSLv3 and only accepting connections using TLS. In most cases, this will have minimal impact to the organization, since TLS has been around for quite some time, and the vast majority of browsers support connections over TLS. The process for disabling SSLv3 in Apache and IIS is as follows:
Apache – Remove support for SSLv3 in the ssl.conf file, by opening ssl.conf, and ensuring that the SSL protocol list has SSLv3 disabled (SSLProtocol All -SSLv2 -SSLv3). Then restart Apache with the following command: sudo service apache2 restart
IIS – For Windows systems, SSLv3 can be disabled through the registry. Simply go to the following registry key:
Once this key is selected, create a new key named SSL 3.0. Select this key, and create a new key under this one named server. Select this server key, and create a new DWORD value named Enable, and give it a value of 0. Once this is done, reboot the server.
To disable SSLv3 in many of the most popular web browsers, refer to this article:http://superuser.com/questions/826729/disable-sslv3-in-major-browsers
IMPORTANT NOTE: It is highly recommended that these configuration changes be tested in a test environment before rolling them out to production.