Detecting DROWN attack

Chances are that unless you are a hermit or have turned yourself into an air-gapped server, you have heard the term “DROWN” kicking around cyberspace. I know that when I see article after article stating that 11 million HTTPS websites are at risk, I tend to get bright-eyed and bushy-tailed. Let’s take a closer look at DROWN and see if your server should be added to that growing list.

Besides death through the inhalation of water, DROWN stands for Decrypting RSA with Obsolete and Weakened eNcryption. It is a newer, much easier to say form of the Million Message Attack from 1998 that takes advantage of an SSLv2 vulnerability 20 years in the making, allowing an attacker to decrypt intercepted TLS connections.

To keep this blog readable, I will not go into full detail of how DROWN works, as the paper released is 22 pages in length (for those interested in the long version you can visit DROWN: Breaking TLS using SSLv2).

DROWN mixes the art of a man-in-the-middle attack with brute force in order to obtain a compromised session key. The original Bleichenbacher attack required hundreds of thousands to millions of connections to a victim server in order to obtain a compromised key. DROWN brings this number down into the tens of thousands, meaning that it no longer requires a super computer to perform the attack. Once a key is obtained, the attacker can decrypt it and use it to perform real-time man-in-the-middle attacks against what you thought was a private encrypted SSL connection

The SSLv2 protocol has been known to be vulnerable since the late 90s when Daniel Bleichenbacher first demonstrated an attack against RSA encryption. In 2011 the IETF published RFC 6176, prohibiting the use of Secure Sockets Layer (SSL) Version 2.0. Nonetheless, for performance reasons many servers and individuals allowed for their servers to use SSLv2, thus leaving themselves and anyone connected with those servers vulnerable. Sites such as Buzzfeed, Flickr, Samsung, and even Yahoo have been found to be vulnerable.

“Two devastating practical findings make DROWN much more impactful than it ever should have been. First, it is surprisingly common for services to share keys. DROWN can target your HTTPS server even if only your email server supports SSLv2, so long as the two share the same private key. While 11% of HTTPS servers with browser-trusted certificates are directly vulnerable to DROWN, another whopping 11% fall victim through some other service (most commonly SMTP on port 25).” – Guide to Drown

So the questions remain: Is my server vulnerable? Have I been attacked? What do I do now?

To test your web servers there is a site, https://test.drownattack.com/, that can help you determine if your server is vulnerable and the good people at OpenSSL have guides as well. If you are running an Apache server you will want to figure out what version you are on. Anything 2.4.x and up has SSLv2 disabled by default, but 2.2.x does not.

While you check your servers and perform updates, you will want to determine if you are being attacked and this is where the power of NetFlow can be a great friend. Using new behavioral analysis algorithms, solutions like Scrutinizer can determine whether a breach attempt is in progress.

This kind of knowledge will not only let you be proactive about the vulnerability, but also give your team the peace of mind they deserve while handling the updates.  It is not a fun day when you are fixing your front door’s deadbolt and someone breaks in through the back. Using your devices to their fullest and getting that visibility is important.

If you have any questions about breach attempts or would like to see an overview of Scrutinizer, feel free to download or get in contact with our team.