How to use Nexpose to find all assets affected by DROWN

Last updated at Fri, 30 Aug 2024 20:01:43 GMT

Introduction

DROWN is a cross-protocol attack against OpenSSL. The attack uses export cipher suites and SSLv2 to decrypt TLS sessions. SSLv2 was developed by Netscape and released in February 1995. Due to it containing a number of security flaws, the protocol was completely redesigned and SSLv3 was released in 1996. Even though SSLv2 was declared obsolete over 20 years ago, there are still servers supporting the protocol. What's both fascinating and devastating about the DROWN attack, is that servers not supporting SSLv2 can also be vulnerable if they use the same RSA key as a server that does support SSLv2. Since SSL/TLS is application agnostic, it is possible to decrypt HTTPS traffic between clients and a server that doesn't support SSLv2 if it's using the same RSA key as, for example, an email server that supports SSLv2.

We have implemented a DROWN vulnerability check in Nexpose to detect if an endpoint is vulnerable to the attack by allowing SSLv2 connections. The check has the Nexpose ID ssl-cve-2016-0800. To find other services that don't support SSLv2 but are also vulnerable to DROWN as they are using the same RSA key as a vulnerable endpoint, we need to use the power of all the data collected by Nexpose during a scan.

Generate a report of vulnerable endpoints

After a scan of our site, we can see that we have 44 instances of the vulnerability.

The report is generated by selecting SQL Query Export as the report model and pasting the SQL query we generated above. This will give us a csv file with the exported data which shows us that we actually have 70 endpoints affected by the DROWN attack.

Generate the SQL Query

There are a few steps we have to complete to generate our DROWN report. First, we need to get the vulnerability ID used by Nexpose internally. We can get the ID from the dim_vulnerability table using the Nexpose ID.

SELECT vulnerability_id  
      FROM dim_vulnerability  
      WHERE nexpose_id = 'ssl-cve-2016-0800'  

Now when we have the vulnerability ID, we need to find all the vulnerable assets and get the certificate fingerprint. The certificate fingerprint is stored in the table dim_asset_service_configuration and all the vulnerabilities for an asset are stored in the table fact_asset_vulnerability_instance. We are ensuring we are only getting the certificate fingerprints from the vulnerable endpoints by matching the port for the vulnerability instance and the port for the service configuration.

SELECT dasc.value  
  FROM dim_asset_service_configuration dasc  
JOIN fact_asset_vulnerability_instance favi USING     (asset_id)  
WHERE dasc.name = 'ssl.cert.sha1.fingerprint' AND dasc.port = favi.port)  

Finally, we put it all together and select all assets which are using the vulnerable certificates:

WITH  
   drown_vulnerability AS (  
      SELECT vulnerability_id  
      FROM dim_vulnerability  
      WHERE nexpose_id = 'ssl-cve-2016-0800'  
   )  
SELECT da.ip_address, dasc.port, dasc.value  
FROM dim_asset_service_configuration dasc  
   JOIN dim_asset da USING (asset_id)  
WHERE dasc.value IN (  
   SELECT dasc.value  
   FROM dim_asset_service_configuration dasc  
      JOIN fact_asset_vulnerability_instance favi USING (asset_id)  
   WHERE vulnerability_id = (SELECT vulnerability_id FROM drown_vulnerability) AND dasc.name = 'ssl.cert.sha1.fingerprint' AND dasc.port = favi.port)  
ORDER BY dasc.value, da.ip_address, dasc.port  

Remediation steps

Start by disabling SSLv2 on the endpoints which have it enabled and generate new certificates with a new private key for affected endpoints.