DROWN: Breaking Down The Latest TLS / SSL Vulnerability

A new security vulnerability in an older version of TLS / SSL was announced this week and has been named “DROWN” by its authors (Decrypting RSA with Obsolete and Weakened eNcryption). It’s estimated to affect up to 11 million servers using the TLS / SSL protocol, from websites to e-mail servers. This unique attack allows a third-party who has intercepted encrypted traffic between a client and an unaffected server, such as one only supporting TLSv1.1 and TLSv1.2, to use another server that is using the same RSA private / public key-pair to act as an oracle to decrypt the intercepted traffic. This leads to a larger attack surface than would normally be exposed if the vulnerability were isolated to a single host since it allows an adversary to perform a “cross-protocol” attack by taking advantage of servers sharing the same TLS / SSL certificates.

In other words, this means that even if a server is configured correctly with proper TLS versions, cipher suites, and is using RSA key exchange, users who interface with that website could be at risk if there is another server that has the same TLS / SSL certificate and supports SSLv2. This attack can also be done using servers running TLS / SSL with different application protocols, such as an e-mail server with the same TLS / SSL certificate acting as an oracle to compromise security for a website. TLS / SSL configurations on e-mail servers and FTP servers are often overlooked, and is considered high-risk in this situation since an attacker could use that server to decrypt communication from the protected host.

There have been other attacks in previous TLS / SSL protocol versions and implementations that used what’s known as an “oracle” to decrypt communication, but these have always been constrained to the affected protocol. An “oracle” is an unintended side-effect of a server’s inconsistency to respond to different errors the same way, thus allowing an attacker to understand the specific reasons why a transaction failed, and possibly leak information about the underlying data. In most systems, understanding errors is important for diagnostic capabilities, but in cryptographic systems, it might compromised protected data.

The DROWN vulnerability has been assigned CVE-2016-0800, which is the “Common Vulnerability and Exposure” identifier used to track and publicize security issues in software products. There are two other CVEs that are important to consider with this announcement:

• CVE-2016-0800 - “Cross-protocol attack on TLS using SSLv2” (DROWN) - Described above.
• CVE-2016-0703 - “Divide-and-conquer session key recovery in SSLv2” - An OpenSSL-specific Key recovery attack in SSLv2 that allows an attacker to recover the master secret very quickly, and can be advantageous to an attacker by allowing them to perform the DROWN attack more efficiently. This was already addressed by the OpenSSL team on March 4th 2015.
• CVE-2015-3197 - “SSLv2 doesn't block disabled ciphers” - To complicate mitigation, simply disabling all SSLv2 ciphers on a server using OpenSSL was not sufficient to disable the use of the protocol, and this issue still allowed clients to continue with the handshake. This was already addressed by the OpenSSL team on January 28th, 2016.

To remediate this vulnerability, it is recommended to either upgrade to the latest TLS / SSL library version or disable SSLv2 on the affected hosts. It’s important to understand what is required since the software package versions vary by operating system, and the steps to remediate on one operating system might be slightly different than to remediate it on another operating system.

How Does bitsight rate and detect this vulnerability?

According to Bitsight data, 56.3% of companies allow SSL v2 for some or all services.

The Bitsight Security Ratings product already assesses servers supporting the SSLv2 protocol, and we grade them as “BAD” accordingly. They should be promptly prioritized to protect against this attack. SSLv2 was officially deprecated by the security community in March 2011, but even at the time it was long considered a poor security practice due to the numerous known vulnerabilities. This week's announcement adds additional evidence that using backwards compatibility as an excuse to enable SSLv2 might put your organization at risk even further.