On 1 March 2016, security researchers announced a new vulnerability exploit involving an old security protocol, SSLv2, that affects up to 33% of web servers. Even web servers that do not allow SSLv2 connections might be vulnerable if the RSA private key used on the server is reused on other servers. And, as seems to be de rigueur for major vulnerabilities nowadays, it comes with a simple and foreboding name: DROWN (which is admittedly much easier to remember and reference than its official designation of CVE-2016-0800).
.
How DROWN Works
DROWN (Decrypting RSA using Obsolete and Weakened eNcryption) requires an attacker only have access or ability to sniff network traffic and the ability to query a vulnerable server.
An example scenario would involve an attacker in a Man in the Middle (MitM) position and able to see a client initiate a TLS connection to a web server to establish a secure HTTPS session. The attacker copies this encrypted session, including the encryption negotiation that starts it. The attacker then takes the initial key negotiation and runs a variant of an old attack on SSLv2 connections known as the Bleichenbacher attack (or, the million message attack) on another server that is willing to use SSLv2 and which uses the same RSA private key as the original server. Because of the way that SSLv2 handles session key generation, this attack could allow an attacker to exploit the weaknesses of SSLv2 (which has been considered obsolete and insecure for almost 20 years now) to gain the keys negotiated over the more secure TLS connection.
The researchers were able to “decrypt a TLS 1.2 handshake using 2048-bit RSA in under 8 hours using Amazon EC2, at a cost of $440.” By exploiting a recently patched (in March 2015) vulnerability in OpenSSL, they duplicated similar results “in one minute on a single CPU”.
.
Am I Affected?
The researchers who discovered this exploitation have an online tool that can let you know if your domain or IP is vulnerable. This tool presents positive results culled from scans they performed over February 2016, so it doesn’t represent real-time data. If you’ve recently updated your OpenSSL version or recently made changes that could address vulnerability to DROWN, you could use the scanner utility they have put together to help you verify your exposure.
.
Mitigating Exposure to DROWN
Since SSLv2 is the primary vector for this attack, removing that protocol as an option during any secure connection negotiation is the first step. Consult with the documentation for your applications that use SSL/TLS for the specific configuration settings that disable SSLv2 (and SSLv3, for that matter). Affected applications can include web servers (Apache, Nginx, etc.), mail servers (Postfix, e.g.), and any connection-oriented services, especially anything using the OpenSSL library.
In addition, OpenSSL users should upgrade their OpenSSL to version 1.0.2g or 1.0.1s, depending on whether you are using version 1.0.2 or 1.0.1, respectively. Some earlier versions of OpenSSL may still allow for exploitation of this attack via the use of weak export ciphers even if they are explicitly disabled, so where possible, upgrade is your best option–these versions also contain patches that address other vulnerabilities unrelated to DROWN.
Finally, a more reliable fix would be to use a unique private key on each server that needs to run TLS. With certain certificates, particularly OV and EV certificates, this option does incur additional cost and may be viable to all deployments or situations.
.
.
