The DROWN vulnerability is a cryptographic flaw with the SSL v2 protocol which was disclosed on the 1st of March and would allow an attacker to decrypt the contents of encrypted communications between a server and clients.
One of the most critical parts of the vulnerability is the ability for an attacker to calculate the server side private key by sending crafted requests to the server. Once an attacker has the private key they are able to not only decrypt messages protected by SSL v2, but also decrypt any other messages encrypted by the same private key, including those using an otherwise secure modern protocol such as TLS 1.2.
This is especially dangerous for systems that share private keys between different exposed services, for example HTTP may be protected by TLS 1.2, but the FTP service instead protected by SSL v2. If these services share the same private key, an attacker could target the exposed FTP service to reveal the private key, the use the private key to decrypt the HTTP communications protected by TLS 1.2.
Is my organisation vulnerable?
Although the SSL v2 protocol has been deprecated since 2011 and the majority of systems should already have it disabled, it is still found to be enabled on legacy, embedded and misconfigured systems.
SureCloud platform scanning
A detection method using SureCloud Vulnerability Manager has been established, and a Tool Policy template has been created for customers that use this service. To use this policy template to identify any vulnerable ASAs please use the ‘Vulnerability: DROWN (CVE-2016-0800)’ Tool Policy within your vulnerability scans. All other (non-specific vulnerability targeted) scanning policies have also been updated to include this detection.
The best defence against the DROWN attack is to disable SSL v2 and export grade cryptography cipher suites and ensure that private keys are not used anywhere with server software that supports SSL v2 connections. Additionally, you may want to generate new key-pairs for services that were previously vulnerable to DROWN as a compromised private key would remain compromised even after a fix has been implemented.
Whilst every effort is made to ensure the accuracy and robustness of any information presented, it is not possible for SureCloud to test every possible scenario an organisation may face, and SureCloud cannot be held liable for any loss or damage which may arise from taking action on any of the contents provided. SureCloud strongly advises that all recommendations, solutions and detection methods detailed, are thoroughly reviewed and tested in non-production environments before being considered suitable for production release, in-line with any existing internal change control procedures.