Preventing cryptographic protocols from “DROWN attack”

07 / Mar / 2016 by Ankit Giri 0 comments

DROWN is an abbreviation for Decrypting RSA with Obsolete and Weakened encryption and is seems to be applicable on servers using SSLV2. Just like Heartbleed, it may impact more than 11 million websites using OpenSSL.This blog explains Preventing cryptographic protocols from “DROWN attack”.

What this vulnerability can do?

DROWN vulnerability enables attackers to break the encryption mechanism in use and sniff the communication between the client and server. This may result in all the data being intercepted by the attackers, although it was meant to be sure as it was being transmitted on a secure channel i.e. HTTPS. And hence, data leak may include username, passwords, PII, credit/debit card information and more such documents. An attacker can change the  content the user will see on the “secure” website.

Many popular applications were reported to be vulnerable to this attacks:

What is the possibility of this vulnerability affecting your setup?

Servers including mail servers are at risk of the DROWN attack, especially the servers which currently support the SSLV2 encryption protocol. Although, practically SSLV2 is obsolete and no client used this protocol for communication with the server and hence it was not considered to be an issue. But, with DROWN attack even if the server supports SSLV2, it becomes vulnerable to decrypting of communication between clients and servers. This is being done by sending a probe to a server which supports SSLV2 and uses the same private key.


More cases where the server may vulnerable to DROWN:

A server using the same private key being used on another server, and the another server supports SSLV2. Many organizations use the same certificate and key across many of its web servers and mail servers. For example, if a mail server is vulnerable to DROWN vulnerability i.e. supports SSLV2 but the web server does not support SSLV2. An attacker can use the vulnerability in mail server to attack the web server and intercept the communication happening. And the vice-versa is also true!

How to check for this vulnerability?

There are two ways of checking your server for this vulnerability:

  • Use the online scanner provided by the which lists all the servers on which SSLV2 is enabled and the ciphers being used.DROWN_check
  • If you wish to scan server on which you can execute commands and scripts, use the following DROWN Scanner: . This python script can be useful if you need to scan a server behind a firewall or if you do not want to expose the domain or the server IP which you need to test.

Mitigating the attack:

  • Ensure that SSLv2 is disabled, across all the servers used in your architecture.
  • Disabling SSLV2 across different server software such as OpenSSL, IIS may differ and you can take reference from this article for steps of mitigation(check the “How do I protect my server?” section):
  • OpenSSL users should upgrade to 1.0.2g

For more details, you can also refer to DROWN: Breaking TLS using SSLv2 and the “Q&A” section.

At the time of writing this blog post, there is no exploit code present. I would update the blog once an exploit code becomes public.


Leave a comment -