Another SSL/TLS vulnerability made waves back in March of this year known as the DROWN attack (CVE-2016-0800). The DROWN (Decrypting RSA with Obsolete and Weakened eNcryption) vulnerability allows attackers to break encryption, revealing sensitive information like communications, passwords, credit cards and other private data by forcing a server to use SSLv2 instead of TLS. Systems that are vulnerable include any infrastructure utilizing TLS such as websites, mail servers and other encrypted services.
The flaw occurs in servers that are still supporting SSLv2, a version with known vulnerabilities that dates back to the 90s before TLS was created. It was initially believed that there was security through obscurity since most modern day clients did not support SSLv2, so having it supported by your server was not considered a significant risk.
How DROWN happens
To further explain how it actually occurs, an attacker sends probes to a server that supports SSLv2 and uses the same private key. Because many servers still support SSLv2 and due to many companies having the same private key used across different servers, the traffic can be sent over SSLv2 regardless of protocol. Companies re-use keys either to save money (signed certs are not cheap) or, if it’s self-signed, it could just be a time saver. Either way, it doesn’t matter if the server is set to use TLS 1.2 so long as the private key is a RSA exchange. By sending crafted malicious handshake messages to the server, the attacker can create modifications using RSA cipher text from the victim server. Unpadded RSA is malleable and will cause the server to respond to the attacker in plain text, potentially revealing the TLS private key.
The information is displayed in plain text in one of two ways. The first and most common is that the attacker probes with a cipher of 40 bits of RSA-encrypted secret key material. The attacker verifies whether the modified ciphertext was validly formed by comparing the server’s response to all 2^40 possibilities. While this is a large computation to make, advancements in modern GPU technology allow graphics cards to process data at speeds that were once thought impossible by CPUs. The second vulnerability is due to a bug in OpenSSL that results in an easier version of the attack. With this vulnerability, the attacker is immediately able to determine if they have the right form without any large computations.
On a fast PC this can be performed in under one minute, allowing the attacker to make 17,000 probes and obtain one of 260 TLS connections.
According to the official DROWN attack website, 17% of servers scanned on the web still support SSLv2 and an additional 16% of HTTPS servers use the same key in their organizations, making the number vulnerable jump up to 33% or roughly 1/3 of the internet.
How to protect yourself
To protect your organization, it’s important to ensure private keys are not shared with any servers that require or have SSLv2 supported or enabled. This means everything from your web servers to your IMAP/POP3/SMTP servers – literally any software that supports SSL/TLS of any kind. In the case of OpenSSL, upgrading the latest version available will resolve this issue (1.0.2g or later and 1.0.1s or later). On Windows Server, it’s important to note that SSLv2 is enabled by default on any OS versions that use IIS 7.0 and 7.5 which includes but is not limited to Vista/Server 2008/Windows 7/Server 2008R2. You can learn more in this Microsoft Knowledge Base article.
Users of Network Security Services need only upgrade to a version of 3.13 or above as SSLv2 is disabled by default in those versions. Other possible systems that might be affected include Apache, Postfix, Nginx, and CentOS. Please check the vendor pages for information on how the drown attack might affect your architecture.