How to Confirm Whether You are Vulnerable to the DROWN Attack4 min read

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 https://drownattack.com/

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 http://test.drownattack.com 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

dnsrecon

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

nmapports

 

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.

nosslv2

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: http://forums.kali.org/showthread.php?98-Adding-support-for-SSLv2-for-SSLScan-and-OpenSSL-testing

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

sslyze

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

 

Conclusion:

  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.

Update:

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.

13 Replies to “How to Confirm Whether You are Vulnerable to the DROWN Attack4 min read

  1. A few additional considerations. Many of the ssl nmap scripts fail when used on ssl services running on non std port 443. That is why it is probably a good thing to evaluate and understand the various limitations which could also explain some of the discrepancies between the drown website and your testing.

    I highly recommend re-enabling sslv2 support into openssl and testing non standard port 443 using openssl s_client. Of course it is best to create a script in whatever preferred language to do all the heavy lifting. Would also use curl, wget etc in script to download headers etc from server. Parse redirects etc. (Have done this and more).

    Should use xml output, with clear variables to help filter on all the data collected.

    Do the challenges of forward and reverse lookup, do not forget about certificate cn as it will likely identify the FQDN.

    1. Last line should read do to the challenges/limitations of forward and reverse lookups, do not forget about the certificate cn….

  2. Perhaps I made the mistake of updating my Kali distro. It seems almost every way I attempt to get SSLv2 info I get a message that SSLv2 is disabled. The above instructions of recompiling openssl no longer work, check this page https://bugs.kali.org/view.php?id=146. It seems that sslscan does work though since it links to libopenssl. The syntax I used was sslscan –failed –ssl2 [IP ADDRESS or HOST NAME]

    1. It took one of our engineers a couple of times before it was upgraded successfully too. I believe sslscan turns more accurate results too.

  3. Did you confirm that your underlying OpenSSL libraries support SSLv2? SSLyze relies on the OpenSSL libraries supported in Kali 2.0 (which I from your screenshot, appears to be what you’re using). From my testing, the Kali supported OpenSSL libraries do not actually support SSLv2. Using the following command you can do a quick check to determine if it is: openssl s_client -connect HOST:PORT -ssl2

    Once identifying this was the case, it seems SSLyze is reporting “SSLv2 Disabled” as a false-positive of OpenSSL SSLv2 not being supported in Kali.

    For my checks, and this is only for port 443 on hosts, I leveraged the Nmap’s SSLv2.nse script, which seemed to work with a high level of accuracy and low false positive rate. Then spot checking a few of the hosts that were reported from Nmap, I used the OpenSSL client within Cygwin on a Windows host to confirm that in fact SSLv2 was supported on the host.

  4. The point of the attack is that SSLv2 doesn’t need to be enabled on the HTTPS daemon. If you’re using the same certificate on any other service (SMTP/POP3/IMAP/FTP/etc) that has SSLv2 enabled, then any service using the same certificate including HTTPS is vulnerable. Simply checking 443 for SSLv2 support is not enough to provide an accurate representation of the vulnerability of a site/server.

    1. You are absolutely correct and communication with the DROWN team confirmed that. However, the point behind this blog post is to confirm each and single server and don’t just rely on the DRWON team’s test tool.

  5. Note that the attack doesn’t require the ciphers to be enabled, just for SSLv2 support to be present. This could account for what you are seeing.

    1. Thanks JK. They are pretty vague about this. I see they are saying: “DROWN shows that merely supporting SSLv2 is a threat to modern servers and clients. It allows an attacker to decrypt modern TLS connections between up-to-date clients and servers by sending probes to a server that supports SSLv2 and uses the same private key.” So it seems at least one server; i.e. web, mail, etc must allow SSLv2, and if it happens that this server shares the key with another server does not enable SSLv2 then that server could be vulnerable too?

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.