Breaking down the DROWN attack and SSLv2 vulnerability

How the DROWN attack works

However, attacks on the cryptographic algorithms and modes of operation used in TLS over the last few years have unnerved security experts, as we all rely on it to provide privacy and data integrity when communicating over the Internet.

An international group of researchers found that by combining brute-force decryption of export-grade cipher suites with a Bleichenbacher padding oracle, they could decrypt an intercepted TLS connection by repeatedly using SSLv2 to make connections to a server. A server that allows SSLv2 connections or has its private key used on another server that allows SSLv2 connections, which is a common but unsafe practice, is vulnerable to the DROWN attack and puts users who connect to it at risk. For example, an HTTPS Web server that doesn't support SSLv2 may be vulnerable because it shares its public key with a Simple Mail Transfer Protocol (SMTP) server that does, as an attacker can take advantage of the SMTP server to break TLS connections to the Web server. According to wide-scale Internet scans run by the DROWN researchers, 17% of all HTTPS-protected machines directly support SSLv2 and are vulnerable to DROWN, and another 16% are vulnerable to key reuse attacks.

Like most attacks against TLS, a DROWN attack works only when an attacker has the ability to monitor traffic between an end user and the server, and as it is nontrivial to implement, it may not appear in the wild just yet. However, attacks on the cryptographic algorithms and modes of operation used in TLS over the last few years have unnerved security experts, as we all rely on it to provide privacy and data integrity when communicating over the Internet. Many of the attacks, particularly protocol vulnerabilities, allow for man-in-the-middle attacks, enabling an attacker to decrypt sensitive information. Some can be mitigated by using the latest security mechanisms. For example, SSL Stripping attacks, which remove the use of SSL/TLS altogether, can be mitigated by enforcing HTTP Strict Transport Security. Downgrade attacks, which force connections to use weaker cryptographic algorithms, like FREAK, POODLE and Logjam, and side channel attacks such as BEAST, Lucky Thirteen and Padding Oracle exploit issues with the TLS implementation of certain ciphers and require configuring services to use non-default options for encryption. Attacks like CRIME, TIME and BREACH, which exploit HTTP compression to read encrypted cookies, are harder to combat as Web servers rely on compression to improve data transmission speeds and so require constant traffic monitoring to detect attempted attacks.

Mitigation techniques

The DROWN attack has been assigned CVE-2016-0800 and the industry has moved quickly to provide patches. OpenSSL 1.0.2g and 1.0.1s make it impossible to configure a TLS server in such a way that it is vulnerable to DROWN. Developers of the Network Security Services cryptographic library have SSLv2 disabled by default and are working to remove all support for the protocol. Microsoft had already disabled SSLv2 for all supported versions of IIS, and servers that run Apache httpd 2.4.x are not affected because SSLv2 is unconditionally disabled.

Apart from applying patches, network administrators need to ensure that private keys are not reused on any Web servers, SMTP servers, IMAP and POP servers or any other legacy or unmanaged software that supports SSL/TLS and allows SSLv2 connections. The DROWN attack website provides a form to check whether a server appears to be exposed to the attack. Once that task has been completed, IPS devices should be set to filter out SSLv2 traffic. Embedded devices that have to use SSLv2 should use a different RSA private key from any other servers and devices, but should also be marked for an upgrade -- SSLv2 was retired almost two decades ago because of its crippling weaknesses. Administrators who are concerned they may have been attacked should check all their server logs for a large number of SSLv2 connections.

According to NIST, there are no fixes or patches that can adequately repair SSL or early TLS, so enterprises should begin migrating to a minimum of TLS 1.1 but preferably TLS 1.2, and disable any fallback to either SSL or early TLS. Waiting is not recommended, even though the Payment Card Industry Security Standards Council has pushed back the date its members must change to TLS 1.1 or higher to June 2018. It's also vital to ensure TLS implementations are configured securely. This means using secure TLS cipher suites and key sizes and disabling support for cipher suites that are not necessary for interoperability.

Security teams need to be cognizant of the fact that hackers have access to enormous computing power through cloud services, so the robustness of encryption algorithms and network protocols is being tested all the time, and new attacks will be discovered. When a new vulnerability is announced, patches and mitigation strategies need to be applied quickly. This requires an up-to-date software and asset inventory list so the patch management team can easily locate all affected services and devices.