SSLv2 DROWN Vulnerability Can Decrypt TLS Traffic

SSLv2, the encryption protocol from Netscape, released in 1995 and out of date already in 1996, would seem to be disabled in all software using SSL / TLS encryption in 2016, especially after the SSL-3 POODLE vulnerabilities, which allow to decrypt 1 byte per 256 requests, and FREAK , associated with weakened (export) versions of ciphers.

And if client software (for example, browsers) does not support SSLv2 connections for a long time, and, more recently, SSLv3, then the server software is not so simple.
')
A group of researchers from Tel Aviv University, Munsten University of Applied Sciences, Ruhr University Bochum, University of Pennsylvania, University of Michigan, Two Sigma, Google, Hashcat and OpenSSL discovered a vulnerability called DROWN - D ecrypting R SA using O bsolete and W eakened e N cryption, which allows decrypting TLS-client traffic, if the server-side SSLv2 protocol is not disabled on all servers operating with the same private key.

According to the study, 25% of the million most visited websites are affected by this vulnerability, or 22% of all scanned servers using certificates issued by public certification authorities.

Why is this possible?

Despite the fact that most web servers have SSLv2 disabled by default, and no one will intentionally enable it, this attack allows you to decrypt TLS traffic, having access to any server that supports SSLv2 and uses the same private key as web server. You can often come across using the same certificate for the web server and mail server, as well as for FTPS.

The generic attack exploits the SSLv2 export cipher vulnerability, using 40-bit RSA keys.
In order to successfully launch an attack, if the information is transmitted without using ephemeral keys agreed on the Diffie-Hellman protocol or its version on elliptic curves, the attacker must passively listen to hundreds of TLS connections of the victim and send specially formed packets to the server using SSLv2 using such same private key.

The attack is possible due to leakage of information about the correctness of the packet decryption in the SSLv2 protocol. Using Danel Bleichenbacher’s attack and sending captured client packets with an encrypted 48-bit pre-master secret, a hacker will be able to fully decipher one of the approximately 900 client TLS sessions. To execute the attack, it is required to send about 40000 requests to the server with SSLv2 enabled, selecting the key for weak symmetric encryption for each sent message.

The researchers were able to restore the client's TLS session for 8 hours using 200 Amazon EC2 machines: 150 g2.2xlarge type with nVidia GPU, and 50 g2.8xlarge with 4 nVidia GPU. The cost of such an attack was $ 440.

The researchers note that the versions of OpenSSL, released from 2010 to January 2016, made an annoying error related to export ciphers.

In 2010, the OpenSSL developers decided to disable all weakened ciphers by default, but not completely disable SSLv2. Thus, it would seem that, even though SSLv2 remained technically enabled, it would not be possible to use it with weak ciphers. Unfortunately, there was an error in the code, which actually turned off the check, and allowing you to specify any export cipher to the server. Only versions of OpenSSL released in January 2016 have been fixed.

"Private" DROWN

In addition to the general case, there is a much faster special case of attack, exploiting another error in OpenSSL, which remained unnoticed at least since the start of the OpenSSL project (1998), and maybe also SSLeay (1995), and was accidentally corrected during research other problems March 4, 2015.
Vulnerability allows restoring master secret byte-bye, making a total of 1920 requests to the server to restore a 128-bit key.

The attack is so computationally simple that it is possible to make it on a regular computer in a minute.

About 9% of the Alexa Top Million servers are affected by this attack.

In addition, the attack can be carried out including the QUIC protocol, a transport protocol using UDP created by Google.

TLS sessions that use ephemeral keys are also vulnerable, but they require intervention in the form of a “man in the middle”.

How to protect yourself?

If you are using OpenSSL 1.0.2 (no letter), 1.0.1l or earlier, you need to update it immediately. If possible, it is better to use the latest version of OpenSSL 1.0.2g and 1.0.1s, from which support for SSLv2 is excluded. Otherwise, disable SSLv2 support in the software you use yourself.

If you are using an Apache web server, you must disable support for the SSLv2 protocol (both for one and SSLv3 so that the web server does not remain vulnerable to the POODLE attack):

SSLProtocol All -SSLv2 -SSLv3 

For nginx, it is enough to leave only the TLS protocols enabled:

 ssl_protocols TLSv1 TLSv1.1 TLSv1.2 

Postfix mail server in versions 2.9.14, 2.10.8, 2.11.6, 3.0.2 and newer is by default configured without SSLv2 support. If you have an older version, use the sample configuration from the researchers page .

If you do not have the ability to disable SSLv2 support (for example, on an embedded device), make sure that this server uses a unique private key that is not used anywhere else.

If you are using Linux, you may need the needrestart utility, which detects services that use old versions of libraries and restarts them.

Links

Website vulnerabilities
Academic Publishing
Non-interactive scanner (checks the site against a database that was collected before publishing vulnerability information)
A scanner application that checks for SSLv2 support and OpenSSL vulnerabilities
Vulnerability information on openssl.org
Details on Ars Technica and technical details from cryptographer Matthew Green