Do Your Research: Don’t DROWN in Misinformation

Before you go and try to fix a problem, it’s important to find out exactly what the problem is. This is something that seems to be getting harder and harder these days, especially when it comes to cryptography. Why am I bringing this up? One of the recent vulnerabilities splashing across the headlines, known as DROWN (which is a new attack on old encryption), seems to have a lot of misinformation surrounding it. My goal with this blog is to clear up a few main points about DROWN that people seem to be getting wrong.

Inherent in this blog is a warning: Security is a thing now and people tend to get really excited about it, which means getting easily swept up in the media hype. What I’m saying is, when the next big vulnerability hits, don’t get caught up in it – at least not until you do your own research. Reading about it in blogs is fine, but make sure you follow up with their references and review the original disclosure.

Misconception 1: None of our clients use SSLv2

DROWN is an attack on SSL version 2, an old and busted protocol no one should use. If you’ve been on the receiving end of a Hurricane Labs pentest, it has probably shown up on your report somewhere as low severity (although it’s ranked a little higher now). It wasn’t a big deal because, well, SSL version 2 is old and no end users should be using it. In fact, it’s unlikely you even have a program on your computer that supports it.

The question floating around is: “If SSLv2 isn’t used, why should I care about its vulnerabilities?” Well, just because you don’t use SSLv2, doesn’t mean the attacker won’t. And they do. The availability of SSLv2 allows an attacker to replay (with some modifications) your fancy TLS 1.2 2048 bit RSA packets to the old and busted SSLv2 server and leverage this vulnerability to decrypt those packets.

That’s right – SSLv2 may’ve been broken before, but now it is SO broken that it even breaks the most modern crypto solution. At this point, your SSLv2 connections are likely working as a nice little service offering (that you’re providing) for attackers to exploit your strongest crypto.

Misconception 2: Attackers can compromise the “private key”

While researching this vulnerability, my colleagues and I came across a piece of contradictory information. This really surprised me. Sites I have trusted many times in the past seemed to have contradicted the very sources they reference… Some sources (even credible websites) claim that the DROWN attack allows an attacker to steal a server’s “private key”. I figured this was likely just a misunderstanding about what “private key” really means, but maybe I missed something.

In this context, “private key” is expected to mean the RSA private key. The RSA private key is EVERYTHING. If an attacker can get your private key, then he can decrypt new traffic, old traffic (excluding perfect forward secrecy), and even impersonate your web server. He essentially has a key to your house, which means you have to change your locks. However, changing your locks means time and money. Someone has to swap the current certificates with new ones, but those need to be generated by modern standards (no SHA1 hashing past January 2017), and signed by a certificate authority.

While changing your keys might be a good idea if your server is old enough to offer SSLv2, it turns out it’s not strictly necessary. The authors of the white paper explicitly address this in their FAQ. The DROWN attack can decrypt a TLS session, but can NOT steal your RSA private key.

In order to get to the bottom of this, I emailed one of the authors of the white paper. His email must be on fire right now having just released this vulnerability, but he was kind enough to reply to me very quickly, clearing up any confusion: “DROWN does not allow an attacker to extract a server’s private key, only to decrypt connections.” – Nimrod Aviram

Misconception 3: The “Special DROWN attack”

Due to the complexity of the DROWN attack, the simplified website DROWNattack.com was created so normal humans can wrap their minds around it. For the sake of understanding, the write-up focuses on the attack implications on SSLv2, which is the most significant result of the attack. However, the authors were able to drastically improve the feasibility of the attack by leveraging a flaw in the specific implementation of SSLv2 by OpenSSL. This is what the authors refer to as the “Special DROWN attack” and is found on page 9, section 5 of the paper.

How does the “Special DROWN attack” improve it? Well, it costs $440.00 to run an EC2 instance for 8 hours to perform the normal DROWN attack, while the improved version of the attack can be run on a common single core computer in less than a minute. This improves the feasibility, but additionally the implications, because the attack is now fast enough that it can be executed while the victim is performing the TLS handshake. This means that an attacker can become an active man-in-the-middle and modify the information you send to the server.

This, at first, may not seem significant because decrypting packets now, or 8 hours from now, still gets credentials that are likely active. However, with an active man-in-the-middle position, the attacker does have more power. An example of this is his ability to compromise a TLS session implementing perfect forward secrecy by impersonating the server during the Diffie-Hellman key exchange (find more about this here). The complexity of the previous sentence is a great illustration as to why the authors did not focus on this in the simple write-up.

As to the implementation flaw by OpenSSL, the white paper states: “…it was unknowingly fixed on March 4, 2015 by a patch designed to correct an unrelated problem.”

So, the next time a big vulnerability hits, consider the information presented by many sources and weigh all claims based off of the original source for a better understanding.