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.
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.
Keep learning
Learn from your SecOps peers with TechBeacon's State of SecOps 2021 Guide. Plus: Download the CyberRes 2021 State of Security Operations.
Get a handle on SecOps tooling with TechBeacon's Guide, which includes the GigaOm Radar for SIEM.
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed on cyber resilience with TechBeacon's Guide. Plus: Take the Cyber Resilience Assessment.
Put it all into action with TechBeacon's Guide to a Modern Security Operations Center.