Mar 1, 16 3:33 pm

Was this post helpful?

How to Confirm Whether You are Vulnerable to the DROWN Attack

Mar 1, 2016
| by:
Sherif Koussa

Another OpenSSL vulnerability has been uncovered. The new vulnerability is one in yet a series found lately in the OpenSSL library, a toolkit implementing SSL v2/v3 and TLS protocols with full-strength cryptography world-wide.

The library which powers about 5.5 million websites has seen several vulnerabilities lately including a few blockbusters like Heartbleed, Shellshock and others. The new DROWN vulnerability follows the same pattern as its predecessor by getting its own website and logo here

You are vulnerable if one or both of the following conditions is true:

1. A server in your network "enables" traffic over SSLv2
2. Another server that enables "SSLv2" shares a key with a server that does not.

At Software Secured we provide managed web application security services. We focus on continuously testing web applications against security flaws such as OWASP Top 10 and more. Our services also entail notifying clients against zero-days in 3rd party libraries used by applications. As part of this service, we started the Software Secured standard procedures to confirm any reported vulnerabilities.

The DROWN team provided a utility to help test whether domains are vulnerable, but we found this tool to report too many false positives. So Software Secured has documented an alternative process to confirm whether you are vulnerable to DROWN.

Here are the steps you need to follow in order to independently confirm whether you are vulnerable to the DROWN attack.

1 - You need to do the following with all your externally available services that could be communicating over SSL (e.g. Web, FTP, SMTP, etc). We assume that you have an inventory of all your public IPs. Just in case you don't, one way to do that is using DNSRecon


2 - For each IP, you need to list all the services that communicate over SSL. First, list the open ports per IP:

3 - Ensure that you have SSLv2 supported as most openSSL distributions disable SSLv2 and SSLv3 (as they should), thanks to Dan Astor for the tip. One quick way to test is force an SSLv2 connection to the domain in question.


If you get this error: "unknown option -ssl2" then you don't have SSLv2 enabled locally. This would give you false positives as your local openSSL client wouldn't be able to negotiate an SSLv2 connection with the server even if the server has it enabled. To enable SSLv2, please follow the instructions here:

4 - So to double check the results, we used SSLyze to check. Bingo, the service at this IP does support SSLv2 ciphers:


5 - Using openSSL itself also confirms the results using the commend: openssl s_client -connect -ssl2


  1. Keep in mind that this vulnerability is in a protocol that was deemed problematic at least 20 years ago.
  2. This vulnerability is more problematic if one of the servers in the network supports the faulty version. This can be used to intercept traffic to other servers that aren’t supporting it.
  3. Although Software Secured found a very high ratio of false positives using the DROWN team’s check utility versus our own testing labs, it is highly recommended you don’t take any chances and test your own server.
  4. Make sure to test ALL your servers including web servers, mail servers, FTP server etc.


Some readers indicated that it is possible to exploit this vulnerability even if SSLv2 was disabled. Merely supporting SSLv2 could potentially be problematic, so I decided to clear out with the DROWN team and I sent the following email:
Nice work. I just had a quick question. In order for a server to be vulnerable, one of the following conditions must happen:

1. The server "enables" SSLv2
2. Another server that enables "SSLv2" shares a key with the server that does not.

If all the servers in a network didn't enable SSLv2, then the vulnerability can't be exploited, can you confirm?

And received the following reply 40 minutes after:

yes this is correct.
But note that even a single SSLv2 enabled server (running on a different
port or IP) using the same RSA key makes your server vulnerable.If you can confirm that all your servers are configured correctly to
disable sslv2, you are OK.

Was this post helpful?

About the Author

Sherif Koussa
Sherif Koussa is OWASP Ottawa Chapter Co-Leader, Software Developer, Hacker, and founder and CEO of Software Secured and Reshift. In addition to contributing to OWASP Ottawa for over 14 years, Sherif contributed to WebGoat, and OWASP Cheat Sheets. Sherif also helped the SANS and GIAC organizations launch their GSSP-Java and GSSP-NET exams and contributed to a few of their courses. After switching from the software development field to the security field, Sherif took on the mission of supporting developers shifting security left, and ship more secure code organically.
Share This Post

Leave a Reply

Your email address will not be published.

Related Post

May 17, 2023 by Omkar Hiremath

Risk of Security and Monitoring Logging Failures

Read more

Was this post helpful?

May 1, 2023 by Omkar Hiremath

Intro to Identification and Authentication Failures

Read more

Was this post helpful?

Dec 22, 2022 by Warren Moynihan

3 Types of XSS Attacks & 4 XSS Mitigation Strategies

Read more

Was this post helpful?


301 Moodie Dr. Unit 108
Ottawa ON K2H 9C4

Designed by WP Expert
© 2023
Software Secured