Archiv pro měsíc: Říjen 2014

Kevin E. Greene on OWASP and the SWAMP Project

During a meeting at AppSec USA 2014 in Denver, the SWAMP team presented its case for working with OWASP to support a marketplace for security tools. I sat down with Kevin E. Greene from DHS S&T, Cybersecurity Division to talk about what SWAMP is an how OWASP and its various projects might become involved. About Kevin E. Greene Software Assurance Program Manager responsible for oversight and management of research and development projects focused on improving the testing, analysis, and evaluation techniques used in software quality assurance tools. In addition, responsible for building a Software Assurance Marketplace (SWAMP) which will provide continuous software assurance services. The SWAMP (www.cosalab.org) will serve as a national marketplace that will provide a collaborative research infrastructure to advance improvements in software development activities, as well as improvements in software quality assurance tools in the area of precision, soundness, and scalability.

Kevin E. Greene on OWASP and the SWAMP Project

During a meeting at AppSec USA 2014 in Denver, the SWAMP team presented its case for working with OWASP to support a marketplace for security tools. I sat down with Kevin E. Greene from DHS S&T, Cybersecurity Division to talk about what SWAMP is an how OWASP and its various projects might become involved. About Kevin E. Greene Software Assurance Program Manager responsible for oversight and management of research and development projects focused on improving the testing, analysis, and evaluation techniques used in software quality assurance tools. In addition, responsible for building a Software Assurance Marketplace (SWAMP) which will provide continuous software assurance services. The SWAMP (www.cosalab.org) will serve as a national marketplace that will provide a collaborative research infrastructure to advance improvements in software development activities, as well as improvements in software quality assurance tools in the area of precision, soundness, and scalability.

SSL 3 is dead, killed by the POODLE attack

Update (8 Dec 2012): Some TLS implementations are also vulnerable to the POODLE attack. More information in this follow-up blog post.

After more than a week of persistent rumours, yesterday (Oct 14) we finally learned about the new SSL 3 vulnerability everyone was afraid of. The so-called POODLE attack (CVE-2014-3566) is a problem in the CBC encryption scheme as implemented in the SSL 3 protocol. (Other protocols are not vulnerable because this area had been strengthened in TLS 1.0.) Conceptually, the vulnerability is very similar to the 2011 BEAST exploit. In order to successfully exploit POODLE the attacker must be able to inject malicious JavaScript into the victim’s browser and also be able to observe and manipulate encrypted network traffic on the wire. As far as MITM attacks go, this one is complicated, but easier to execute than BEAST because it doesn’t require any special browser plugins. If you care to learn the details, you can find them in the short paper or in Adam Langley’s blog post.

SSL Labs Changes

We made three improvements to the SSL Labs web site to properly test and warn about the POODLE attack: 1) warnings about SSL 3 support and vulnerability to POODLE, 2) test for TLS_FALLBACK_SCSV and 3) new client test that detects support for SSL 3. At this time, a server vulnerable to the POODLE attack will be given a C grade, but we’re likely to change this grading in the near future, after we carefully consider all our options.

What Now?

POODLE is a protocol-level vulnerability that can’t be easily fixed. Although it might be possible to attempt a BEAST-style mitigation, it seems that browser vendors are not interested in that approach. Adam said Chrome won’t pursue that direction. Firefox said they would disable SSL 3 in Firefox 34. And that’s great news. Traditionally we struggle with letting go of old protocols. Because SSL 3 is not very widely used and POODLE is serious enough, it seems that we’ll be able to retire this old protocol version soon. In fact, some CDNs have already disabled it.

What You Should do

You can look at this problem from two perspectives. As a user, you want to protect yourself from attacks, and the best way to do that is to disable SSL 3 in your browser. (Instructions are easy to find online.) The updated SSL Labs Client Test will tell you if your change was successful.

As a web site operator, you should disable SSL 3 on your servers as soon as possible. You need to do this even if you support the most recent TLS version because an active MITM attacker can force browsers to downgrade their connections all the way down to SSL 3, which can then be exploited. In normal operation, SSL 3 shouldn’t needed by the vast majority of sites. Although it’s likely that there’s a long tail of clients that don’t support anything better, Internet Explorer 6 on Windows XP is potentially the biggest user segment that still relies on SSL 3. Options are to guide users to manually enable TLS 1.0 (IE6 supports it, but not by default) or upgrade to other browsers. In the short term, it’s possible to mitigate POODLE by avoiding using CBC suites with SSL 3, but that involves relying on a certain insecure stream cipher whose name no one wants to mention. I don’t recommend this approach.

POODLE wouldn’t be as serious without the ability of the active network attacker to downgrade modern browsers down to SSL 3. There’s a solution to this problem, via the TLS_FALLBACK_SCSV indicator that must be supported by clients and servers in order to be effective. Google implemented this feature in February (in Chrome and in their web sites) and has been successfully using since. Mozilla says Firefox will support the indicator in early 2015. A new version of OpenSSL has just been released, which includes support for the SCSV. The support might be backported to various Linux distributions. For best results, support also needs to be added to other major browsers. Once that happens, the POODLE attack surface will be much smaller; it will affect only the users with older browsers.

For detailed guidance on how to disable SSL 3 in various servers and browsers, head to Scott Helme’s blog post.