TLS Coverage Improvements in Nexpose 6.0.2

Last updated at Thu, 31 Aug 2017 14:23:53 GMT

Over the last couple of years, some of the most serious and widely publicized vulnerabilities have been related to the Transport Layer Security (TLS) protocol and its predecessor, Secure Sockets Layer (SSL). Because TLS is so fundamental to keeping network communications secure, new flaws that are discovered can have a disproportionate effect on an organization's risk.

From Heartbleed to POODLE, FREAK to Logjam, system administrators dread the next vulnerability announcement with a catchy name or custom designed logo that will require patching and/or reconfiguring any services using TLS. The October 14th release of Nexpose (6.0.2) contains a number of improvements related to TLS that will make it easier for administrators to track which versions of the protocols are supported by assets, along with which cipher suites are enabled. We've also broken up our weak cipher vulnerability into multiple vulnerabilities to make it clearer why particular cipher suites are flagged as insecure. (Note that we will continue to ship the old ssl-weak-ciphers vulnerability alongside the new ones for a period of time to give customers who typically do content-only updates a chance to get the required product changes without losing coverage.)

Cipher Suite Enumeration

The most significant enhancement with this release is that Nexpose now enumerates the protocol versions (SSLv2 and v3, TLS v1.0, v1.1 and v1.2) and associated cipher suites for each TLS endpoint that gets scanned. This information is stored in the service configuration, accessible by clicking on the Service Name under the SERVICES section of an asset's page:

A number of new configuration settings are available:

The new ssl.protocols configuration setting is a comma-delimited list of protocol versions supported by the endpoint. As a convenience, the sslv3, tlsv1_0, tlsv1_1, and tlsv1_2 settings contain "true" if that protocol is supported, or "false" if Nexpose was unable to connect via that version. In this case, we can see that only SSLv3 is supported. The sslv3.ciphers setting is a comma-delimited list of cipher suites available when using SSLv3 to connect to the service. There are also dh.keysize settings indicating the size of the key used by cipher suites that use Diffie-Hellman key exchange.

Exporting Cipher Suite Data

Although having all the cipher suites in the service configuration is convenient for taking a quick look at how a service is configured, it does not lend itself well to bulk or offline analysis. To facilitate this, the data can be exported as a SQL Query Export with a row per cipher suite. This is done by going to the Reports tab, choosing Create a Report, giving it a name (here "ciphersuite export"), choosing the Export tab and then the SQL Query Export template:

Next, define the query that will expand the comma-delimited list into individual rows:

The query:

SELECT ds.name AS site_name, da.ip_address, da.host_name, dos.asset_type, dasc.port,  
       split_part(dasc.name, '.', 1) protocol_version,  
       unnest(string_to_array(dasc.value, ',')) cipher_suite  
FROM dim_asset da  
   JOIN dim_operating_system dos USING (operating_system_id)  
   JOIN dim_host_type dht USING (host_type_id)  
   JOIN dim_asset_service_configuration dasc USING (asset_id)  
   JOIN dim_site_asset dsa USING (asset_id)  
   JOIN dim_site ds USING (site_id)  
WHERE dasc.name ILIKE 'sslv2.ciphers'  
   OR dasc.name ILIKE 'sslv3.ciphers'  
   OR dasc.name ILIKE 'tlsv1_0.ciphers'  
   OR dasc.name ILIKE 'tlsv1_1.ciphers'  
   OR dasc.name ILIKE 'tlsv1_2.ciphers'  

will convert the comma-separated list into an array (string_to_array) and then expand it into a row per cipher suite (unnest).

Now, select the site and scan of interest, then save and run the report:

Once the report has finished, you can download it as a CSV file containing rows with the site name, host name, IP address, protocol version and cipher suite:

New Weak Cipher Checks

In addition to the cipher suite enumeration, we have also changed how our vulnerability checks for ciphers are performed. Our old vulnerability checks each connected to the server and requested SSL/TLS handshakes using the vulnerable ciphers. This meant that it was possible for multiple handshakes to be performed with the same cipher if the cipher was listed in multiple vulnerabilities. This led to unnecessary requests to the scan target. With the new cipher enumeration, we are performing the vulnerability checks against the configuration settings of the scan target, without performing any additional requests. This results in better, scalable vulnerability checks.

We have also expanded our three previous vulnerability checks into seven new checks.  This allows more direct explanations as to why a cipher is weak and vulnerable. To accommodate customers who will only perform content updates this release, we are shipping the new vulnerability checks alongside the old checks. This is just for a transition period and it is recommended to update Nexpose to prevent loss of coverage when the old checks are deprecated.

The seven vulnerabilities are:

1. ssl-anon-ciphers: The server is configured to support anonymous cipher suites with no key authentication. These ciphers are highly vulnerable to man in the middle attacks.
2. ssl-cbc-ciphers: The server is configured to support Cipher Block Chaining (CBC) ciphers. These ciphers have problems with the way TLS implements CBC mode and can be vulnerable to multiple attacks. Known attacks include the "BEAST" attack (CVE-2011-3389) and the "Lucky Thirteen" (CVE-2013-0169).
3. ssl-des-ciphers: Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346) include cipher suites based on DES (Data Encryption Standard) and IDEA (International Data Encryption Algorithm) algorithms. DES and IDEA are no longer recommended for general use in TLS, and have been removed from TLS version 1.2.
4. ssl-export-ciphers: The TLS/SSL server supports export cipher suites, intentionally crippled to conform to US export laws. Symmetric ciphers used in export cipher suites typically do not exceed 56 bits.
5. ssl-null-ciphers: The TLS/SSL server supports null cipher suites. Null cipher suites do not provide any data encryption and/or data integrity.
6. ssl-rsa-export-ciphers: The TLS/SSL server supports RSA-based cipher suites intentionally weakened due to export control regulations. This may enable an attacker to launch man-in-the-middle attacks and monitor or tamper with sensitive data against clients susceptible to the FREAK vulnerability. These cipher suites can typically be identified by the word "EXP" or "EXPORT" in their name.
7. rc4-cve-2013-2566: Recent cryptanalysis results exploit biases in the RC4 keystream to recover repeatedly encrypted plaintexts. As a result, RC4 can no longer be seen as providing a sufficient level of security for SSL/TLS sessions. It has many single-byte biases, which makes it easier for remote attackers to conduct plaintext-recovery attacks via statistical analysis of ciphertext in a large number of sessions that use the same plaintext.

Note that ssl-rsa-export-ciphers and rc4-cve-2013-2566 already exist in Nexpose. The more generic ssl-weak-ciphers vulnerability will be deprecated in an upcoming release.

Along with all these additions, this release fixes various outstanding issues with Nexpose's TLS coverage. These changes also lay the groundwork for further TLS improvements, coming soon!