Using Obsolete and Weakened eNcryption (DROWN), decrypting RSA is a cross-protocol attack that exploits a vulnerability in the SSLv2 protocol version. Specifically, it is a version of the Bleichenbacher RSA padding oracle attack.
DROWN can also be used against modern servers that use the SSLv3 or TLS encryption protocol but still support the obsolete protocol if both protocols use the same public key. The vulnerability is also present along the same lines if the same public key certificate is used on another SSLv2 server.
If a DROWN attack is successful, it may lead to sensitive communications and data, such as emails, instant messages, personal authentication details, and financial data like credit card numbers being read and stolen.
DROWN Attack Security Assessment
CVSS Vector: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
SSL DROWN Vulnerability Information
The DROWN attack was officially announced by a group of security researchers in March 2016 and was assigned CVE-2016-0800. The full technical description of the attack is available in the DROWN: Breaking TLS using SSLv2 paper.
DROWN uses several different tactics to achieve its goal. On the one hand, it is a cross-protocol attack which means that part of its strategy is to make use of differences in protocols to exploit a particular vulnerability present in the SSLv2 protocol.
It is also a Bleichenbacher padding oracle attack (i.e., a ciphertext attack). Once the attacker has exploited the cross-protocol vulnerability, they send thousands of modified handshake messages to the server and monitor its responses. Due to the nature of the server’s responses when using an RSA key exchange under SSLv2, the attacker can slowly begin to gather pieces of the server’s session key, eventually revealing them entirely. As a result, all servers are at risk, including websites and mail servers.
There are two main types of DROWN attack – a general DROWN attack and a special DROWN attack.
The general DROWN makes use of the RSA encryption of the master secret in SSLv2, whereas the special DROWN makes use of an OpenSSL vulnerability in its implementation of SSLv2. As a result, the latter attack is significantly easier, cheaper, and faster to execute.
How does the DROWN attack work?
The DROWN attack goes through several stages. First, the attacker must observe and record sessions between the server and the client that use any version of SSL or TLS. For DROWN to work, these sessions must also use RSA cipher suites. Eventually, one of these recorded sessions will be decrypted.
The researchers who announced the DROWN vulnerability estimated that about 1,000 such sessions are sufficient for the subsequent description of the session key. These sessions can either be intercepted over time, or attackers may be able to trick users into following a link that creates such connections in the background without the user’s knowledge.
At the second stage of the attack, the attacker has captured the usual client/server handshake. They then create multiple connections to the server using the cross-protocol vulnerability. They establish SSLv2 connections to the server, and since the server allows these connections, it is open to exposure.
These connections are modified handshake messages that target the RSA ciphertext – because unpadded RSA, as used in SSLv2, can be changed. The attacker monitors the server’s responses which gradually provide hints about whether they are guessing the 40-bit encryption key correctly or not, and brute forces their way in through trial and error.
Ultimately, after about 40,000 such attempts, the master secret is revealed by the attacker in the general DROWN vulnerability scenario. This can be executed successfully in less than 8 hours.
For the particular DROWN scenario, about 17,000 connections and roughly 260 recorded sessions are required, and it can be executed in less than a minute. Given how fast the special DROWN attack can be performed, it also opens the door to man-in-the-middle attacks (MITM), allowing the attacker to impersonate standard and modern servers. A quarter of all HTTPS servers are vulnerable to this attack. If this is achieved, even perfect forward secrecy (PFS) cannot help prevent DROWN since a MITM situation allows attackers to interrupt PFS connections.
Once the master secret is revealed, the attacker obtains the session key, and they can use it to decrypt the previously recorded sessions. This reveals sensitive data such as authentication credentials and, more, exposing clients.
Prevention Guide
Learn how to detect and prevent different kinds of SSL/TLS vulnerabilities.
How to prevent the DROWN vulnerability?
To prevent the possibility of being exposed to a DROWN attack, server operators must make sure that their server does not support the use of SSLv2 cipher suites. They must also ensure that the server’s private keys are not used anywhere else, such as in web servers, email servers such as SMTP, IMAP, or POP servers, etc., and server software that support SSLv2 connections.
To learn more about preventing DROWN and other similar security vulnerabilities, refer to the guide on securing TLS configuration.
