- March 09, 2016
- Info notes
A team of security researchers published a paper presenting a novel cross-protocol attack called DROWN (Decrypting RSA with Obsolete and Weakened eNcryption). The attack allows them to decrypt passively collected TLS sessions. For the attack to work, the server must also support SSLv2 and use the same private key for both TLS and SSLv2 connections. For the technically-minded, the attack is a Bleichenbacher RSA padding oracle attack. According to the paper's findings 33% of the internet's reachable HTTPS servers (11.5 million) are vulnerable to this attack.
The DROWN Attack
The attack affects servers that employ TLS but still support the obsolete and deprecated SSLv2. The attack is effective even in the case where SSLv2 is disabled for HTTPS, but enabled for another protocol (e.g. SMTP) that uses the same private key.
Figure 1: The general DROWN attack
The general attack
The attack can be performed on any version of the SSL/TLS protocol as long as the SSLv2 RSA key exchange protocol is used. Initially the attacker must passively collect the TLS connections made between a client and a server. This means that the attacker has to either intercept traffic for a long period of time or use social engineering to trick users into visiting a website that makes many connections to the victim server.
Then the attacker modifies the captured RSA ciphertext from the intercepted TLS connections and sends specially crafted handshake messages to the SSLv2 victim server. The server's response to these connections differs based on whether the modified ciphertext decrypts to a plaintext with the right form. Despite the attacker not having the server's private key it is possible to infer information about the TLS secret key from the server's responses. The attacker deduces whether the modified RSA ciphertext has the right form by comparing the server's response to all the 240 possibilities of a 40bit RSA encrypted key used in SSLv2. According to the paper the interception of 1,000 TLS handshakes, the initiation of 40,000 SSLv2 connections and 250 computations are required to decrypt one RSA ciphertext corresponding to a cost of about €400 of cloud computing power.
A variation of the attack
An even more severe variant of the attack which requires less computational power takes advantage of an OpenSSL vulnerability (CVE-2016-0703). It allows the attacker to have immediate feedback on whether his specially crafted handshake messages have the right form or not. This time the interception of 260 TLS connections and the initiation of 17,000 SSLv2 connections are required to decrypt one RSA ciphertext with the computation not taking over one minute on a contemporary PC. This variation of the attack is fast enough to allow an attacker to perform a real-time man-in-the-middle attack to impersonate a vulnerable server to a victim client and compromise connections between modern browsers and TLS servers. This also allows the attacker to enforce the use of the RSA key exchange method instead of perfect-forward secrecy methods, i.e. Diffie-Hellman or Elliptic Curve Diffie-Hellman.
SSLv2 is a protocol introduced in the 90s and is now considered vulnerable and insecure. Even though web browsers stopped supporting SSLv2 a long time ago, it proves that server operators still allow SSLv2 connections either by default or due to misconfiguration, negligence, or compatibility reasons, e.g. support of old embedded devices. The server operators assumed that since browsers no longer support the flawed SSLv2 it was not risky to leave it enabled on their servers which led to a false sense of security. After SSLv3 was deemed insecure due to the POODLE vulnerability this attack makes it once again very clear that no server should use any version of SSL and that any unrequired functionality should be disabled from a server.
Export-grade cipher suites
Until 1996 the US government prohibited companies from exporting strong encryption algorithms that it could not easily break. Thus only weak variants of the encryption routines were exported typically by using shorter key lengths, i.e. 40 or 56 bit keys. SSLv2 belongs to this certain class of encryption algorithms dubbed "export-grade cipher suites". Although the export restrictions were lifted 16 years ago, they still have an impact on today's security. This shows that restrictions on the use of security technologies can have big consequences years later, because implementations of these technologies outlive the policies that constrain them.
The use of the same digital certificate across different protocols proves to be a serious security risk. This shows that certificates can only have a single use. This might be difficult to achieve for technical or financial reasons and adds a layer of complexity to the overall certificate management.
For systems administrators and operators of servers
One of the main reasons that made this attack possible is the support of the obsolete SSLv2. The root cause of the problem is not a technical issue but a policy one: the limitation of encryption strength in the 90s. Implementers of security features have the responsibility to respect the laws and implement any legal restriction in force. They must also remove any restriction when lifted by a change in the law and this does not go only as far as acknowledging the lift of restriction by allowing stronger protections, but also by removing all traces of restricted features. This is a key to the DROWN attack which could have been prevented if servers did not still support the export-grade SSLv2. Server operators must as soon as possible disable SSLv2 and not reuse private keys used in SSLv2 servers. If SSLv2 is mandatory for specific reasons, it must use its own key pair.
Server administrators who use OpenSSL 1.0.2 should upgrade to 1.0.2g and those who use OpenSSL 1.0.1 should upgrade to 1.0.1s. Any older OpenSSL version (dating before January 2015) should be upgraded to one of the latest versions as well.
In the meantime between patching and properly disabling SSLv2, server administrators can drop SSLv2 traffic at the firewall level. After disabling SSLv2 it is crucial for server administrators to actually perform post-configuration tests to ensure that their servers are properly configured.
More recommendations on protection against the DROWN attack are available on NCSC-NL's factsheet "Disable SSL 2.0 and upgrade OpenSSL".
For policy makers
ENISA has already argued against the weakening of security measures, and the importance of strong cryptography for the EU citizens:
"policy makers have the responsibility to pass laws that are just, equitable, and that have the least impact on people's and industry's freedom. Moreover, public policy tends to last for a long time. Computing costs are systematically decreasing, in ever shorter periods. Therefore, attacks that seem out of the reach of any one but a nation state will not remain so for the lifetime of the implementations. As such, policy makers:
1. Should refrain from limiting in any way security features in computer software
2. Should refrain from limiting in any way the export of security features in computer software
3. Should consider lifting any and all existing limitations for security features in computer software.".
The DROWN attack is a strong reminder that obsolete cryptography is dangerous and does not have its place in this world. Earlier vulnerabilities like FREAK and Logjam have the same root cause. It is time all the actors learn the lesson: policy makers, implementers, and systems administrators. Information security is an evolving field, and failing to follow its evolution will lead to incidents that could otherwise have been prevented.
About "Info Notes" from ENISA
With the "Info Notes" series ENISA aims at giving the interested reader some background and recommendations about NIS related topics. The background and recommendations are derived from past experiences and common sense, and should be taken as starting points for discussions on possible course of action by relevant stakeholders. Feel free to get in touch with ENISA to discuss or inquire more information on the "Info Notes" series (email@example.com).