Overview
Last week, the world of nerds waited with bated breath for the details of a newly discovered bug in OpenSSL, announced as the highest priority, the patches for which went public today as OpenSSL versions 1.0.2g and 1.0.1s.
The details finally came out in the form of CVE-2016-0800 and it turns out it's not just OpenSSL that's affected. There is actually a deficiency in the SSLv2 protocol that affects all servers that speak SSLv2. The situation is worse for OpenSSL: they had a logic bug introduced by export-grade crypto (everyone's least favorite idea from the 90s other than parachute pants) that makes the attack much faster: the researchers behind DROWN are citing a less than one-minute decryption time on affected versions. They say other servers will take around eight hours. You'll need to disable SSLv2 entirely to be safe! Uh-oh!
17% of HTTPS servers on the Internet are capable of speaking SSLv2 and are vulnerable.
This time, the bug, named "DROWN", produces what's known in cryptography as an "oracle": something that leaks bits of information that should really be kept secret. In this case, it is possible that information leaked by SSLv2 implementations can be used to decrypt other connections, even if they use safe, modern encryption. Simply disabling SSLv2 isn't enough if it isn't disabled everywhere the key is in use.
33% of HTTPS servers on the Internet are vulnerable due to key reuse or direct SSLv2 support.
This can pose real risk to organizations. For instance, if your email server was vulnerable to this bug, an employee accessing e-mail at a coffee shop would be susceptible to several things: an attacker could spy on their email conversations or steal their credentials.
Mitigation
This underscores the importance of using modern encryption protocols and ensuring that your servers aren't susceptible to degradation to insecure standards. There are many tools, for example Qualys SSL Labs, that can tell you if your HTTPS servers can be convinced to use older encryption standards like SSLv2.
We’ve known not to use SSLv2 for a while; it was deprecated in 2011 but that was just the official nail in the coffin. Crypto heroes Bruce Schneier and Dave Wagner noted SSLv2 as being full of “gaping holes” as early as 1997. Even its immediate successor, SSLv3, has been considered unsafe for over a year now.
Duo recommends that you don’t use SSLv2 at all, if possible. Your best mitigation is to disable deprecated protocols entirely. Mozilla has also made a nice tool for generating locked-down web server configurations.
If you think you need SSLv2, for example when dealing with legacy devices without libraries that support modern cryptographic standards, you need to ensure SSLv2 uses a different private key than your TLS connections and be aware that the SSLv2 communication is not secure. If you're interested in more background, Matt Green has an excellent write-up.
Word of warning: because of the way this vulnerability works, it is possible to decrypt even TLS if there's a vulnerable SSLv2 server using the same private key.
Testing
We've been focusing on web servers here but there are other scenarios where transport-layer encryption that could include OpenSSL is present, for example mail servers and database servers. In these cases, your easiest option for assessing protocol support is by attempting to connect to them.
Update: March 4th, 2016: several researchers who worked on DROWN reached out to me to point out that CVE-2015-3197 is impossible to detect with a stock OpenSSL client. If you need to support SSLv2, it's critical to patch to at least 1.0.1r/1.0.2f to make the exploitation of DROWN more difficult. However, your only way to be completely protected is to disable SSLv2 entirely.
If you're using SSLv2, their command-line tool can be used to quickly determine if you're vulnerable to CVE-2015-3197.
Testing for SSLv2 support can be performed with the OpenSSL command-line tools (but be aware that there's no way of reporting vulnerability to CVE-2015-3197 if SSLv2 support is enabled):
openssl s_client -connect yourorg.net:3306 -ssl2
After attempting to negotiate the connection, you will either see an error indicating that SSLv2 is disabled:
CONNECTED(00000003)
2734723140:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:s2_pkt.c:429:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 30 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : SSLv2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1457112215
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
If SSLv2 is enabled, but you don't have any ciphers in common with the server, you will see a slightly different error. Your best options are to either disable SSLv2, or if you need to keep it enabled, run the Python-based DROWN scanner to determine your vulnerability to CVE-2015-3197:
CONNECTED(00000003)
depth=0 C = AU, ST = Some-State, O = Internet Widgits Pty Ltd
verify error:num=18:self signed certificate
verify return:1
depth=0 C = AU, ST = Some-State, O = Internet Widgits Pty Ltd
verify return:1
2734723140:error:1406D0B8:SSL routines:GET_SERVER_HELLO:no cipher list:s2_clnt.c:452:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 894 bytes and written 35 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : SSLv2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1457108370
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
---
client_hello, but no supported ciphers were found in common.If SSLv2 is enabled and you have overlapping cipher support on the server and client, you will see a complete handshake with more data transferred and a cipher suite selected:
CONNECTED(00000003)
---
Server certificate
-----BEGIN CERTIFICATE-----
redacted
-----END CERTIFICATE-----
subject=redacted
issuer=redacted
---
No client certificate CA names sent
---
Ciphers common between both SSL endpoints:
RC4-MD5 RC2-CBC-MD5 DES-CBC3-MD5
---
SSL handshake has read 1239 bytes and written 367 bytes
---
New, SSLv2, Cipher is RC2-CBC-MD5
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : SSLv2
Cipher : RC2-CBC-MD5
Session-ID: A79733E17D1614C67BE7CF032E53EDA3
Session-ID-ctx:
Master-Key: 753E74E79290C5C70EC0F11BE721CD6D
Key-Arg : 54634093A5F41AF4
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1456773891
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
The team that found and measured the bug also made a logo a tool to check for the vulnerability, if the server you care about is exposed to the public Internet.
So What Now?
Have we mentioned that you should disable SSLv2 everywhere? Go do that now. Pretty please?
If you can't, make sure that you only use it when absolutely necessary, and don't operate under the assumption it's secure! Due to the nature of the vulnerability, be sure you aren't sharing a private key between your SSLv2 and TLS setups.
System administrators ought to have disabled all support for SSLv2 (and SSLv3!) years ago, given the weaknesses and attacks that we've seen throughout the past 5+ years. And, yet, 25% of the Alexa top 1m sites are willing to talk SSLv2, rendering useless the responsibly chosen modern crypto options of well-behaved clients. Additionally, a scan of the entire internet found around 6 million hosts supporting SSLv2. This makes pandas everywhere sad, since this state of affairs was totally avoidable. More broadly, this demonstrates the need for sysadmins of secure systems to stay up to date with which security options are considered best practices by the crypto/security nerds. Failure to do so is negligent.