Should you panic about the recently disclosed DROWN SSL vulnerability? Is it cute and kid-friendly, or is it a monster vulnerability coming to expose your most sensitive data?
The DROWN announcement was done the right way:
• Cool acronym (Decrypting RSA with Obsolete and Weakened eNcryption)
• Decent logo
• Domain name (drownattack.com)
The mainstream tech media has been giving DROWN (CVE-2016-0800) some love, partially because the DROWN research team has some big names like Professor Nadia Heninger (I really do love her research). As usual, they write scary-sounding stuff, but have provided no guidance on how to compare DROWN to other SSL vulnerabilities.
So, how much of a threat is DROWN? Last year I put together a scoring system for enterprise administrators and security architects (i.e., the SecurityWeek readership) to rank SSL/TLS vulnerabilities. My system gauges relative levels of panic for each new vulnerability. To make the scoring system digestible for the media, ranges are based on a Japanese Monster Alert Level.
By my scoring system, DROWN only achieves a Hello Kitty warning level. This is because the asset in play is only a single TLS session (Impact=3), and the exploitability is non-trivial or impossible on most counts (Exploitability = 2).
Here’s the breakdown in a single paragraph of how DROWN works:
Be a passive man-in-the-middle (MitM). Record 1,000 TLS sessions. Mince the handshakes and then feed them (in 4,000 new sessions) to an SSLv2 server that is using the same private key. Also, perform a quintillion (1018) mathematical calculations.
That last part—the 1,125,899,906,842,624 mathematical operations—can be done for about $440 in eight hours using a cluster of NVIDIA GPUs.
The other requirements for DROWN keep its exploitability score low for enterprise administrators. For example, the passive MitM requirement means you won’t be seeing drive-by attacks, just determined adversaries that are in position to see all your traffic.
The key to DROWN is that in order to be vulnerable, you have to have SSLv2 enabled and sharing a key. Anyone serious about security should have disabled SSLv2 everywhere. An audit or penetration test should have flagged SSLv2 for you more than two decades ago. The DROWN authors suggest that 33% of the Internet is potentially vulnerable—mostly because of more bugs in OpenSSL. Somehow, Yahoo.com and Alibaba got into Alexa’s Top 10,000 vulnerable sites list, but the rest reads like the who’s-not-who (xhamster.com, anyone?)
Having SSLv2 still enabled, even in an email server, is a stronger indicator that a site simply hasn’t kept house properly; the site will likely have other, bigger problems than DROWN.
Indeed, one could assert that the largest impact of DROWN may be the increased spotlight on sites that still support SSLv2 rather than any widespread threat from the vulnerability itself. One customer, who was prompted by the DROWN vulnerability to scan for SSLv2, was shocked to find they still had over 50 Internet-exposed services supporting SSLv2 (including an unpatched, default IIS 7 website).
Some interesting facts about DROWN:
• Surprisingly, forward secrecy doesn’t help.
• Google’s TLS-like UDP protocol, QUIC, is vulnerable, just not as bad.
• Ivan Ristic at SSL Labs is preparing a special DROWN test that will give a site an F if it’s susceptible.
• There is no exploit tool in the wild. And if DROWN follows the same path as all other “Hello Kitty” SSL vulnerabilities, there won’t ever be one.
I could posit a scenario about a determined attacker who doesn’t mind waiting weeks or months for success. Somehow you mess up and load a high-value certificate into the server with an older version of OpenSSL on a part of the network the attacker already has compromised. The attacker then uses DROWN to sniff out another user’s cookie, and then escalate their privilege.
It could happen. Same as FREAK could happen. Or LOGJAM.
But the determined attacker could almost certainly find another, easier (non-SSL) vulnerability much faster and cheaper than by using DROWN.
Does this mean you don’t have to patch? Of course not; you always have to patch. You don’t need to change all your certificates though, like you did with Heartbleed. If you’ve been auditing and pen-testing your environment, you’re probably safe.
It never hurts to check, though.