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:

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

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: 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:

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

Conclusion: