Three researchers from Google have published findings about a vulnerability in SSL 3.0, a cryptographic protocol designed to provide secure communication over the internet. Although SSL 3.0 is nearly 15 years old, it’s still used all over the place – browsers, VPNs, email clients, etc. In other words, this bug is pretty widespread.
Successful exploitation of this vulnerability can result in an attacker exposing data encrypted between an SSL 3.0 compatible client and a SSL 3.0 compatible server. We’re talking about the kind of data you encrypt because you want it to stay confidential. Overall, the issue is relatively difficult to exploit but you’re still going to want to address it quickly.
Where does the dog come in?
POODLE (Padding Oracle On Downgraded Legacy Encryption) is the attack that exploits this vulnerability. It allows an attacker to steal information over time by altering communications between the SSL client and the server (also known as a man in the middle attack, or MITM). This means that exploitation is NOT trivial; it takes some work. That doesn’t necessarily mean its bark is worse than its bite given the type of information that can be stolen through successful exploitation, but it does limit the impact.
If both the client and server support SSL 3.0, the attacker can leak approximately one byte of clear-text for every 256 requests. To give you an idea of the amount of effort required to get anything useful out of this, it would take approximately 2,000 forced requests to leak enough data for the attacker to hijack a typical HTTP over SSL session. This would take a few minutes if exploited by an attacker that was silently forcing connections to another server in the background.
A couple of additional notes on exploitability:
- If SSL2 and SSL3 is disabled in the web browser, the issue is not exploitable
- If SSL2 and SSL3 is disabled on the server, the issue is not exploitable
How do you muzzle the POODLE?
The recommendation is to disable SSL 3.0 on all clients and servers. We suggest you start with your most business critical, high value assets, eg. VPNs, PCI websites, Point of Sale systems, other line of business applications, etc. Don’t forget about your STARTTLS-compliant services, such as IMAP, POP3, and SMTP.
Disabling SSL 3.0 on clients and servers is a change that will have impact and that you may need to stage over time. If you’re going to do this, it’s advisable to evaluate the likely impact for your internal and external customers and communicate clearly to them so they understand the implications too. Getting a log summary of which encryption ciphers clients and browsers are using will help you understand how many people will be impacted by SSL 3.0 being disabled. This will also potentially give you the ability to detect if the attack is happening over time.
One note: If for some reason you still have Windows XP users running Internet Explorer 6, this will prevent them from accessing TLS-only services. Keep in mind that these users will not be able access most of the internet once SSL 3.0 is blocked by major service providers. Windows XP users can switch to Chrome or Firefox as alternatives to Internet Explorer.
UPDATE Thank you to @tomsellers for this clarification: "XP supports TLS 1.0 with a setting change on IE 6, and natively on IE 7."
In cases where disabling SSL 3.0 is not possible, some workarounds have been provided, but they are generally not as effective.
It’s pretty difficult for consumers to protect themselves. There are options in Firefox and Chrome that enable you to turn SSL 3.0 off, but you need to set them up manually and most consumers probably won’t. Older network 2devices may only support SSL and disabling SSL 3.0 could prevent them from being able to configure their modem, router, or printer. This makes it even more imperative for businesses to protect their customers, and consumers should be looking to their vendors to provide updates on whether they have taken the necessary steps to protect themselves.
How can Rapid7 help you protect yourself?
Nexpose is able to assess for weak ciphers any time it detects SSL/TLS protocol.
UPDATE - October 15th - As of today, Nexpose includes a check for this vulnerability.
The Metasploit team is also actively working on exploits and will publish to the Metasploit Framework as soon as they are available.
Are Rapid7’s products affected by this vulnerability?
Nexpose and Metasploit allow clients to use SSL 3.0 by default. However, all supported browsers provide TLS 1.0 and above, and Nexpose and Metasploit will use the strongest level available. Rapid7 is currently working on updates to both products to ensure that clients use TLS 1.0 or higher when securing their communications. We will make these updates available ASAP and will notify our customers when they are.
We have reconfigured UserInsight’s web console to no longer accept SSL 3.0 browser connections, which eliminates what seems to be the most likely attack vector: an administrator signing in to the service from an unsecured network. We will notify UserInsight and Mobilisafe customers directly of any other potential concerns and mitigations.