What is DROWN ?
DROWN is the latest in a long line of recent vulnerabilities discovered in SSL/TLS. It is a cross-protocol attack which uses a combination of brute-force decryption of weak ciphers and a Bleichenbacher padding oracle attack on SSLv2.
The RSA algorithm used in TLS and SSL uses a particular form of padding called the RSA-PKCS#v1.5, the implementation of which was known to be vulnerable to an information leakage attack called the Bleichenbacher padding oracle attack. Most SSL/TLS implementations resorted to fixing this vulnerability using a hack that works around one of the preconditions for this attack to succeed. This fix has mostly been found satisfactory from SSLv3 onwards, but has just been found to be inadequate for SSLv2 which has fundamental differences in the way it works.
What does a generic attack look like?
The general variant of this attack involves first observing and storing a number of TLS connections. Then a specially crafted handshake message, with a modified RSA cipher text from the original TLS connection is sent over an SSLv2 connection. Because of the Bleichenbacher padding oracle, the attacker would be able to deduce whether the cipher text was successfully decrypted to the plain text or not. The attacker would then be able to repeat this over several attempts to fully decrypt the original TLS connection.
Ideally around 40000 connections and around 250 offline brute force computations would be required on average to decrypt a single TLS connection. Even though the amount of computing power required for this seems high, the researchers who identified the vulnerability were able to make use of GPU computations and perform the attack in around 8 hours.
If you are lucky – You might see this “Improvised” Attack
A variant of this attack exists which makes use of identified vulnerabilities in OpenSSL to significantly speed up the attack process. In the special case, the researchers were able to decrypt the TLS connection in just a minute on a standard computer by exploiting vulnerabilities in OpenSSL. The OpenSSL vulnerability (CVE 2016-0703) is in the SSLv2 code and accepts any non-zero value for a cipher. This allows an attacker to perform the DROWN attack using only 17000 connections and significantly lesser rounds of brute-force computations compared to the generic version of the attack.
Who should worry?
Weaknesses in SSLv2 have been known for over two decades now and its use has been deprecated ever since. But even though modern clients do not have support for SSLv2, many servers still support SSLv2 either to ensure backwards compatibility or because of default configurations. Measurements by the research team has shown that 17% of all HTTPS servers allow SSLv2 connections.
Compounding this issue is the fact that most organisations use the same private key pair across multiple servers. That is, even if a web server did not explicitly support SSLv2, it was enough if another server such as the VPN server or a mail server also supported SSLv2. All an attacker requires is to have at least one server with a shared private key that supports SSLv2.
Some implementations of OpenSSL (CVE 2015-3197) allow SSLv2 connections to a server with SSLv2 support built-in even though it has been explicitly disabled in the configuration.
How bad is this really?
An attacker using this vulnerability needs to have privileged access within a network and make a large number of requests to decrypt a single TLS connection. The private key is not accessible, but only the master key used for a particular connection can be obtained. This makes it less severe than the Heartbleed vulnerability. Most security research firms categorise it with medium severity and have assigned the CVE a CVSS score of 5.9.
How to fix the Vulnerability
Fixing the vulnerability is merely a matter of disabling SSLv2 support on all servers (Web, Mail, VPN, etc.) and ensuring the SSL/TLS library used is updated to the latest version possible. Since the attack does not impact the confidentiality of the private key, it is not required to change the certificate.
If it is not possible to immediately disable SSLv2 because of backward compatibility reasons, it is recommended that a firewall be implemented to block multiple consecutive failed SSLv2 connections to a server.
