The DROWN attack (Decrypting RSA with Obsolete and Weakened eNcryption) makes it possible for an attacker to decrypt previously recorded TLS encrypted connections and then to obtain sensitive information in these communications. By sending a large number of specially prepared handshake messages to a server supporting SSLv2, attackers can obtain the session key. Moreover, in a similar way an attack can also be performed against other servers which use the same private key as long as just one of the servers involved in the communication supports SSLv2.
A vulnerability in SSLv2 is used in one general variant of DROWN which requires high amounts of computing power. The risk of a DROWN attack being successful dramatically increases because of two vulnerabilities in OpenSSL:
1. OpenSSL versions before 1.0.2f or 1.0.1r also allow DROWN attacks with deactivated SSLv2 cryptoalgorithms. Servers that merely support SSLv2 connections are vulnerable.
2. Furthermore, the majority of servers prone to DROWN attacks are still using versions of OpenSSL before 1.0.2a, 1.0.1m, 1.0.0r or 0.9.8zf. These versions have a security vulnerability which further simplifies the process used in the attack.
Scans from the researchers who discovered the weaknesses show that a large portion of servers used worldwide still support SSLv2, making them vulnerable to DROWN attacks.
To protect yourself from DROWN attacks, please make sure that private key material is not used with server applications that allow SSLv2. This applies not only to web servers, but also, for example, to SMTP, IMAP, and POP servers and to any other application which supports SSL/TLS. You can find additional information about DROWN and recommendations for how to secure your servers against a DROWN attack here [1]. Security updates with patches for the vulnerabilities are included in the new OpenSSL versions 1.0.2g and 1.0.1s.
References:
[1] The DROWN attack: https://drownattack.com
[2] OpenSSL Security Advisory: https://mta.openssl.org/pipermail/openssl-announce/2016-March/000066.html
Monday, March 7, 2016