DROWN SSLv2 Vulnerability Rears Ugly Head, Puts One-Third of HTTPS Servers At Risk
A “new” and important vulnerability has been discovered that affects HTTPS and other services that rely on SSL/TLS implementations. This flaw is in the SSLv2 protocol, and affects all implementations. Researchers refer to this attack as DROWN – short for “Decrypting RSA using Obsolete and Weakened eNcryption”. This attack allows attackers to read or steal information sent via the “secure” connection. No attacks in the wild are currently known.
DROWN itself and several other problems in SSLv2 have received the following CVEs in a recent advisory:
- Cross-protocol attack on TLS using SSLv2 (DROWN) (CVE-2016-0800)
- SSLv2 doesn’t block disabled ciphers (CVE-2015-3197)
- Divide-and-conquer session key recovery in SSLv2 (CVE-2016-0703)
SSLv2 is considered an obsolete protocol (it dates back to February 1995). It is no longer recommended for usage in any production environment. However, on many servers SSLv2 is still supported for legacy reasons. Server administrators want to ensure that their services are available to as many users are possible; they want to ensure that a user connecting to the server (even using an obsolete system) can access any available services.
An attacker carrying out a DROWN attack must be in a position to carry out MITM attacks, as well as the capability to make multiple SSLv2 connections to the target server. If the attacker makes multiple SSLv2 connections to the server, he can then use brute force attacks to find the server’s private key. Once the key has been found, any intercepted traffic could then be decrypted.
A server is vulnerable to DROWN attack if any one of the following two conditions are met:
- If it supports SSLv2 requests
- Its private key is used on any other server that allows SSLv2 connections, even for newer SSL/TLS protocol versions
The researchers who documented DROWN claim that 17% of the HTTPS servers still allow SSLv2 connections. Therefore, if a MITM attack is possible, the attacker could probe the server using SSLv2 connections (the victim’s machine would not send connections using this), find the server’s private key, and use it to decrypt even TLS traffic.
Taking key reuse into account, an additional 16% of HTTPS servers are vulnerable, putting a third of all HTTPS servers at risk. In addition, if other services (such as SMTP, POP, etc.) are also on the given server share the same private key, they could be at risk as well.
The researchers have released a scanner on GitHub which sends SSLv2 requests on a given port and waits for the server’s reply; this acts as test for this vulnerability. At no point is the server actually exploited.
Figure 1. DROWN detection tool demonstration (click to enlarge)
The fix for this vulnerability is relatively simple: as OpenSSL also recommends, server administrators need to ensure that SSLv2 is not being supported anywhere. SSLv2 is obsolete, has known vulnerabilities, and should no longer be in use today. In addition, server private keys should not be reused, especially on servers where SSLv2 was supported in the past.
OpenSSL 1.0.2 users should upgrade to 1.0.2g. OpenSSL 1.0.1 users should upgrade to 1.0.1s. Users of older OpenSSL versions should upgrade to either one of these versions.
Deep Security customers can use the DPI rule below to find out if SSLv2 is being used in their environment:
- 1005321 – Detected SSLv2 Request
There are other weaknesses in SSL/TLS which make finding the private keys easier, especially if Export Grade cipher suites are still in use. The following rules help detect and mitigate the risks in such cases:
- 1006561 – Identified Usage Of TLS/SSL EXPORT Cipher Suite In Response
- 1006485 – SSL RSA Downgrade Vulnerability
- 1006562 – Identified Usage Of TLS/SSL EXPORT Cipher Suite In Request