OpenSSL is the open source implementation of the Secure Sockets Layer/Transport Layer Security (SSL/TLS) protocols that encrypt data sent over a network connection (including the Internet) and is the standard for protecting sensitive information such as credit card and bank account numbers and personal data in web-based transactions. The HTTPS protocol uses TLS to secure traffic between a web client (web browser) and a web server hosting a web site.
In 2014, the big news broke about the Heartbleed exploit, which uses a buffer over-read vulnerability in OpenSSL’s cryptographic library, to steal private keys from servers and access users’ passwords. At least half a million web servers were estimated to be using the affected version of OpenSSL and thus were vulnerable to Heartbleed, including some of the most popular sites on the web. These included Amazon Web Services (AWS), GitHub, Pinterest, WordPress, Gmail, GoDaddy, Netflix, YouTube, Dropbox, Tumblr, Wikipedia, Yahoo, Instagram and many more.
To the credit of the open source community, the security flaw was patched the same day that the public disclosure occurred, but there were reports of exploits either prior to that time or during the hours between the disclosure and the application of the patch. Months later, in July, Business Insider was reporting that 300,000 servers were still vulnerable.
The Heartbleed fiasco had IT professionals scrambling to get their web servers updated and Internet users scrambling to change their passwords on the various affected sites and services. But Heartbleed is by no means the only exploit that has targeted SSL and/or TLS. BEAST (Browser Exploit Against SSL/TLS) made headlines back in 2011, BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) was revealed by security researchers at Black Hat in 2013 and FREAK (Factoring RSA Export Keys) is another SSL/TLS exploit that was discovered in 2015.
Heartbleed just got the most press. Now, not quite two years later, yet another OpenSSL exploit is rearing its ugly head. This one is called DROWN (Decrypting RSA with Obsolete and Weakened eNcryption) and it affects web servers that rely on SSLv2 to secure HTTP communications.
Version 2 of SSL was released way back in 1995 and was superseded by SSLv3 the next year. In fact, the reason a new version came out so quickly was – you guessed it – security flaws in 2.0 that led to a complete redesign in the third version. TLSv1 came out in 1999 and was based on SSLv3. The current version of TLS is version 1.2 (with TLSv3 currently a working draft at the time of this writing). With four generations of SSL/TLS between it and SSLv2, you would think that SSLv2 would be too rare in the field to worry about.
You would be wrong. Experts have warned that several million web sites and email services are vulnerable to DROWN. That’s because almost six million web servers and nearly a million email servers are directly supporting SSLv2. But there’s more. Even servers that don’t have SSLv2 enabled can still be vulnerable if another server that does support it uses the same RSA key pair. That brings the estimated number of affected web servers up to eleven and half million.
Some of the popular web sites that are believed to have been vulnerable at the time DROWN was made public, on March 1, include Yahoo.com, weather.com, speedtest.net, Samsung.com, stumbleupon.com, apache.org, usc.edu and many more.
With so many servers affected and such commonly-visited web sites vulnerable, you might be wondering: What is the impact of the DROWN exploit and how does an attacker take advantage of it? To put it simply, an attacker can use the vulnerability to decrypt TLS-protected communications. Here’s how it works: The attacker has to have some patience, because he’ll need to collect hundreds of connections between the client and server machines that use an RSA key exchange. The attacker will make changes to the RSA ciphertext and will send multiple specially crafted handshake messages to the SSLv2 server that he’s targeting. The attacker can send probe connections and eventually obtain the key for one of the TLS connections and run computations. The attacker can perform a man-in-the-middle attack and impersonate the server to the client computer.
The thing that makes DROWN important is that even if web clients don’t use SSLv2 but instead make their connections over TLS, an attacker can still intercept and decrypt those messages if SSLv2 is a supported protocol. Merely allowing SSLv2 connections, even if they are never used, makes the server vulnerable. And even if SSLv2 is not enabled, using the same private key as another server that does allow it also makes your server vulnerable. Ouch!
The solution is to disable SSLv2 on all servers and devices that use your server’s private key. Of course, this doesn’t help those connecting to the affected servers because there is nothing you can do on the client end to protect against the exploit.
The good news (yes, there is some good news) is that the attacker is only able to decrypt one TLS connection at a time; this exploit doesn’t enable him to obtain the server’s private key. That means the server’s certificates aren’t compromised. The even better news is that there have been no reports of the DROWN vulnerability being exploited in the wild before its public disclosure and publication of countermeasures for preventing attack. Of course, now that the information is “out there,” it will be easier for attackers to exploit it.
What can you do? As noted above, the solution is to disable SSLv2, but this isn’t always as simple as it sounds. In order to be protected against DROWN, you have to be sure that you’ve disabled SSLv2 on all servers and devices that use the same private key as your server(s). How to do that depends on what software and what SSLv2 implementation is running on the server(s).
If you’re running OpenSSL, upgrade to the latest version (1.0.1s or 1.0.2g). Check out this OpenSSL User’s Guide to DROWN for more information. If you’re running IIS 7.0 or above or NSS 3.13 or above, SSLv2 should be disabled by default, but you should check to ensure that it hasn’t been manually enabled. If you’re running Apache httpd 2.4.x, SSLv2 is disabled but if you’re using httpd 2.2.x, it is enabled by default so you’ll need to disable it.
For a much more comprehensive and technical discussion of the DROWN vulnerability and exploit, see the paper titled DROWN: Breaking TLS using SSLv2.