RESEARCH | October 17, 2014

Vicious POODLE Finally Kills SSL

The poodle must be the most vicious dog, because it has killed SSL.

 

POODLE is the latest in a rather lengthy string of vulnerabilities in SSL (Secure Socket Layer) and a more recent protocol, TLS (Transport layer Security). Both protocols secure data that is being sent between applications to prevent eavesdropping, tampering, and message forgery.

POODLE (Padding Oracle On Downgraded Legacy Encryption) rings the death knell for our 18-year-old friend SSL version 3.0 (SSLv3), because at this point, there is no truly safe way to continue using it.

Google announced Tuesday that its researchers had discovered POODLE. The announcement came amid rumors about the researchers’ security advisory white paper which details the vulnerability, which was circulating internally.

SSLv3 had survived numerous prior vulnerabilities, including SSL renegotiation, BEAST, CRIME, Lucky 13, and RC4 weakness. Finally, its time has come; SSLv3 is long overdue for deprecation.

The security industry’s initial view is that POODLE will not be as devastating as other recent vulnerabilities such as Heartbleed, a TLS bug. After all, POODLE is a client-side attack; the others were direct server-side attacks.

However, I believe POODLE will ultimately have a larger overall impact than Heartbleed. Even the hundreds of thousands of applications that use a more recent TLS protocol still use SSLv3 as part of backward compatibility. In addition, some applications that directly use SSLv3 may not support any version of TLS; for these, there might not be a quick fix, if there will be one at all.


POODLE attacks the SSLv3 block ciphers by abusing the non-deterministic nature of block cipher padding of CBC ciphers. The Message Authentication Code (MAC), which checks the integrity of every message after decryption, does not cover these padding bytes. What does this mean? The padding can’t be fully verified. In other words, this attack is very capable of determining the value of HTTPS cookies. This is the heart of the problem. That might not seem like a huge issue until you consider that this may be a session cookie, and the user’s session could be potentially compromised.

TLS version 1.0 (TLSv1.0) and higher versions are not affected by POODLE because these protocols are strict about the contents of the padding bytes. Therefore, TLSv1.0 is still considered safe for CBC mode ciphers. However, we shouldn’t let that lull us into complacency. Keep in mind that even the clients and servers that support recent TLS versions can force the use of SSLv3 by downgrading the transmission channel, which is often still supported. This ‘downgrade dance’ can be triggered through a variety of methods. What’s important to know is that it can happen.

There are a few ways to prevent POODLE from affecting your communication:

Plan A: Disable SSLv3 for all applications. This is the most effective mitigation for both clients and servers.

Plan B: As an alternative, you could disable all CBC Ciphers for SSLv3. This will protect you from POODLE, but leaves only RC4 as the remaining “strong” cryptographic ciphers, which as mentioned above has had weaknesses in the past.

Plan C: If an application must continue supporting SSLv3 in order work correctly, implement the TLS_FALLBACK_SCSV mechanism. Some vendors are taking this approach for now, but it is a coping technique, not a solution. It addresses problems with retried connections and prevents reversion to earlier protocols, as described in the document TLS Fallback Signaling Cipher Suite Value for Preventing Protocol Downgrade Attacks (Draft Released for Comments).

How to Implement Plan A

 

 

 

With no solution that would allow truly safe continued use of SSLv3, you should implement Plan A: Disable SSLv3 for both server and client applications wherever possible, as described below.

Disable SSLv3 for Browsers

 

 

 

 

Browser
 Disabling instructions
Chrome:
Add the command line -ssl-version-min=tls1 so the browser uses TLSv1.0 or higher.
Internet: Explorer:
Go to IE’s Tools menu -> Internet Options -> Advanced tab. Near the bottom of the tab, clear the Use SSL 3.0 checkbox.
Firefox:
Type about:config in the address bar and set security.tls.version.min to 1.
Adium/Pidgin:
 Clear the Force Old-Style SSL checkbox.

Note: Some browser vendors are already issuing patches and others are offering diagnostic tools to assess connectivity.

If your device has multiple users, secure the browsers for every user. Your mobile browsers are vulnerable as well.

Disable SSLv3 on Server Software

 

 

 

 
Server Software 
   Disabling instructions
Apache:
Add -SSLv3 to the SSLProtocol line.
IIS 7:
Because this is an involved process that requires registry tweaking and a reboot, please refer to Microsoft’s instructions: https://support.microsoft.com/kb/187498/en-us
Postfix:
In main.cf, adopt the setting smtpd_tls_mandatory_protocols=!SSLv3 and  ensure that !SSLv2 is present too.

Stay alert for news from your application vendors about patches and recommendations.

POODLE is a high risk for payment gateways and other applications that might expose credit card data and must be fixed in 30 days, according to Payment Card Industry standards. The clock is ticking.

 

 

Conclusion

 

 

 

 

Ideally, the security industry should move to recent versions of the TLS protocol. Each iteration has brought improvements, yet adoption has been slow. For instance, TLS version 1.2, introduced in mid-2008, was scarcely implemented until recently and many services that support TLSv1.2 are still required to support the older TLSv1.0, because the clients don’t yet support the newer protocol version.

A draft of TLS version 1.3 released in July 2014 removes support for features that were discovered to make encrypted data vulnerable. Our world will be much safer if we quickly embrace it.

Robert Zigweid

 

 

References 
INSIGHTS | April 12, 2012

TLS Renegotiation and Load Balancers

 

I seem to be fielding more and more questions of late around the rather well-known SSLv3 and TLS renegotiation flaw. For those who aren’t familiar, the TLS renegotiation flaw allows the injection of data into a SSLv3 or TLS stream, potentially causing data injection or the program to misbehave in some other fashion. It is not a full man-in-the-middle attack because the attacker can’t read what’s in the data stream, only inject into it. Ultimately, this is a protocol flaw—one that’s been fixed as an extension to TLS as dictated by RFC 5746—but adoption in SSL libraries has been relatively slow.



 

I’m seeing this come around how to deal with the flaw when it’s reported in a scan, such as a PCI ASV scan. If encountered as part of an ASV scan, it could result in non-compliance, which makes it a cause for concern. However, as with many flaws, the TLS renegotiation issue can be a false positive depending on the implementation of the system.

 

If the flaw is reported against a system that the scanner accesses directly—perhaps only passing through a firewall—then how to react to the report is pretty straightforward. In these instances, I have not encountered any circumstance in which the flaw might be a false positive if the service is allowing TLS renegotiation. The best recommendation in these situations is to disable TLS renegotiation if possible. In most cases, renegotiation is not truly needed.

 

Things get more interesting when load balancers are involved, at which point it depends on the how the load balancers are implemented. Usually, one of two basic approaches are used when implementing a load balancer between the internet and the service.

 

First scenario: the load balancer is completely responsible for handling the SSL. The SSL connection is received, and a new connection is established between the load balancer and the service. In this approach, the connection between the service and the load balancer may or may not be encrypted. In this implementation, if TLS renegotiation is enabled on the load balancer, it is not a false positive because the load balancer is responsible for the renegotiation taking place, and the flaw can manifest.

 

Second scenario: the load balancer passes through the connection to the service and never interrupts the SSL channel, so the end service decides whether TLS renegotiation occurs. It is this circumstance that can cause tests for TLS renegotiation to be false. The load balancer will report back to the scanner or tester that it handles TLS renegotiation, but it is, in fact, the service that is responsible. If the service itself does not support TLS renegotiation, the finding is very likely a false positive.

 

Secure Renegotiation has been added as an extension to the TLS protocol to support RFC 5746; therefore, if you utilize an SSL implementation it should support Secure Renegotiation. Otherwise, if an RFC 5746-compliant SSL library must be used (and unless there is an explicit need for TLS renegotiation to be enabled), it is recommended that you disable it.
INSIGHTS | February 24, 2012

IOActive’s IOAsis at RSA 2012

 

This is not a technical post as usual. This is an invitation for an important event if you are going to RSA 2012 and want to escape the chaos and experience the luxury at IOAsis while enjoying great technical talks and meeting with industry experts. If you want to feel like a VIP and have great time then don’t miss this opportunity!

 

We have scheduled some really interesting talks such as:
  • Firmware analysis of Industrial Devices with IOActive researcher Ruben Santamarta
  • Mobile Security in the Enterprise with IOActive VP, David Baker and IOActive Principal Consultant, Ilja van Sprundel
  • The Social Aspect of Pen Testing with IOActive Managing Consultant, Ryan O’Horo
  • Battling Compliance in the Cloud with IOActive Principal Compliance Consultant, Robert Zigweid
We hope to see you there!