Top takeaways from the DROWN vulnerability

DROWN, an acronym for “Decrypting RSA with Obsolete and Weakened eNcryption,” is a serious vulnerability that affects HTTPS and any other services that use SSL and TLS, the foundations for privacy on the Internet. DROWN is a great example of a “cross-protocol attack,” in that weaknesses in SSLv2 are leveraged as a vehicle to indirectly attack the much more secure TLS.

The DROWN vulnerability exists not because of a bug in any particular codebase (e.g., OpenSSL) but rather due to the inclusion of 40-bit encryption in SSLv2. This weak encryption was included due to U.S. government export restrictions in force during the 1990s. With modern computer hardware, it is now computationally feasible to decrypt 40-bit keys in a reasonable amount of time. 

A server is vulnerable to DROWN if either one of these conditions is met: 

  • The server allows both SSLv2 and TLS connections

  • The server’s private key is used on any other server that facilitates SSLv2 connections

The researchers who discovered this vulnerability say that approximately 33 percent of the HTTPS servers on the Internet meet one or both of these conditions and thus are exposed to this risk.

Application Security Research Update: The State of App Sec in 2018

How DROWN works

To exploit the DROWN vulnerability, the attacker must capture both the initial RSA handshake and the encrypted TLS traffic. This means that this is not an active attack but rather a passive one, requiring that the client/server traffic be observed. For the attack to work, the attacker captures the normal client/server RSA handshake, repeatedly modifies it, and sends thousands of these modified handshake messages to an SSLv2-capable server. The responses from the server to the attacker to these modified handshake messages yield “hints” about what the TLS session key is. Once the session key is recovered, the captured TLS traffic can then be decrypted. 

About 1,000 handshakes need to be captured to find a handshake that has a recoverable key, with about 40,000 queries to the SSLv2 server, and about 2^50 offline computer operations. The researchers were able to execute the attack in a few hours using Amazon EC2 at a cost of slightly more than $400. A second variant of the attack, called the “Special Drown Attack,” was inadvertently discovered during the research. This variant, which exploits a specific vulnerability in OpenSSL, allows for the decryption of TLS RSA encrypted data in around one minute on an ordinary PC.

There is one characteristic of DROWN that helps mitigate its virility: the fact that the attacker needs direct access to the client/server packet flow. This means that the attacker would need to be on the same network as the victim, with a technical way to intercept the network traffic. This may be impractical for “casual” opportunistic attacks but may be useful for very targeted attacks where there is sufficient motivation to gain the necessary access. 

What we can draw from DROWN's existence

The fact that the DROWN vulnerability exists at all brings up some key observations. One is the fallacy of including weakened security protocols in any implementation. Originally, 40-bit encryption was included due to Clinton-era regulations that required weakened algorithms for export. Protocols, it seems, last forever, and DROWN is an example of the undesired long-term consequences of intentionally weakening a security protocol. A decision made in the 1990s is impacting security in 2016. 

Another observation is that DROWN exposes inherent weaknesses in how we manage our systems and infrastructures. In security, there is the long-held rule of thumb that “less is more.” Every single protocol that is available for use is “more” and results in an increased threat surface. SSLv2 is a great example of this. This protocol is now an incredible 21 years old and has been depreciated since 2011. No modern browser would use it, and certainly no modern browser would request very weak 40-bit encryption. There is no legitimate reason for any server connected to the Internet to have this geriatric protocol enabled! Yet it continues to exist on many servers because:

  • Many server configurations have it enabled by default

  • Many organizations may believe they need it for “legacy” purposes

  • Many IT administrators may not have even been aware that it was there in the first place

These facts make it clear that many operators just don’t know what’s on their networks and why something is there. This results in many legacy services and protocols that are left operational for no real-world reason. 

What you don't know can hurt you

This vulnerability also indicates how seemingly unrelated systems may in fact be very related. Consider the case where:

  • The web server has SSLv2 disabled and is properly hardened

  • The seemingly unrelated email server has SSLv2 enabled

  • The web server and email server share the same digital certificate, hence share the same public/private key pair

In this case, the attacker could use the SSLv2-enabled email server to attack the web server’s TLS traffic. This case also shows one of the dangers of sharing certificates—a frequent money-saving practice in many organizations. This sharing creates relationships that should not exist.

Prevention is the best medicine

Beyond the obvious action of applying the latest SSL patches and disabling SSLv2, the actions that operators should take to react to DROWN are clear and apply to good security hygiene in general:

  • Audit your servers for obsolete or otherwise unused protocols, services and software—and remove what’s not required

  • Perform frequent vulnerability assessments to identify any obsolete or vulnerable software, services, or configurations that may be exposing you to unnecessary risk

  • Monitor your network traffic for unwanted or undesired protocols—and shut down what you don’t need

Organizations that were proactive in performing the simple cyber-hygiene steps enumerated above have nothing to fear with DROWN. Those that weren't are left scrambling to fix it.

Topics: Security