Last updated at Tue, 22 Aug 2017 14:02:30 GMT

On July 9, 2015, the OpenSSL team has announced a vulnerability in specific versions of OpenSSL 1.0.1 and 1.0.2. This vulnerability is listed as “high severity” because it can fail to correctly validate that a certificate presented is issued by a trusted Certificate Authority, leaving systems vulnerable to man-in-the-middle (MITM) attacks. To learn more, see Tod Beardsley's blog post at /2015/07/09/cve-2015-1793-ope nssl-certificate-authority-impersonation and the OpenSSL advisory at https://www.openssl.org/news/secadv_20150709.txt.

The good news is that these versions of OpenSSL are not widely deployed, and not included in most Linux distributions.

One of the great features within Nexpose is the ability to create dynamic asset groups. A dynamic asset group allows users to create a grouping of discovered assets based on a set of user-defined criteria across the entire organization. In addition, the lists are dynamic. Therefore, every time Nexpose runs any scan in your environment, the list of assets in the dynamic asset group are dynamically updated based on the filter criteria that you have chosen. This dynamic asset group can then be used in reporting, so that you can tailor your reports based on the asset filter criteria that you have developed.

So for the OpenSSL vulnerability, you don't have to scan your assets again to determine this information. Nexpose will use the information discovered in the last scan, so you can easily start any needed mitigation process instantly after the creation of the Dynamic Asset Group. You can scan your assets again if you so choose, as the asset information will be updated with any new information after every scan.

One of the criteria that a user can use to create a Dynamic Asset Group is the installed software discovered on an asset. If you are already using Nexpose to conduct authenticated scans of your Linux systems, you can quickly create a Dynamic Asset group to search for systems that have these vulnerable versions of Open SSL. (If you are not already conducting authenticated scans, see below for another option).

Note: Administrator-level authentication is required so that the scans will have been able to check the software versions on the target machines. For more information on scan credentials in *nix machines, see the Nexpose Help or User's Guide under Discover- Configuring Scan Credentials – Authentication on Unix and related targets.

To create a Dynamic Asset Group that searches for machines with vulnerable versions of OpenSSL:

  1. On the Nexpose home page, select New dynamic asset group.

  1. Under Filtered Asset Search, select Software name from the menu, make sure the condition is contains, and enter OpenSSL 1.02c.
  2. Click the plus sign to add additional filters.
  3. Repeat the process with OpenSSL 1.0.2b, OpenSSL 1.0.1n, and OpenSSL 1.0.1o.
  4. Toggle the setting to Match any of the specified filters.

  1. Click Search.
  2. In many cases, there will be no results found. This means no vulnerable versions of distributions with OpenSSL were found on your scanned machines.

  1. If there are results found, mitigate the vulnerability as indicated in the advisory.

If you do not have existing authenticated scans, or if you want to cross-check the results of the previous method, you can create a different Dynamic Asset Group that checks for specific services, and then you can manually check those machines for vulnerable versions of OpenSSL.

To search for assets running relevant services:

  1. On the Nexpose home page, select New dynamic asset group.


2. Under Filtered Asset Search, select Service name from the menu, make sure the condition is contains, and enter HTTPS.
3. Click the plus sign to add additional filters.
4. Repeat the process with FTPS, SMTP-S, IMAP-S, and POP3-S
5. Toggle the setting to Match any of the specified filters.

  1. Click Search.
  2. You will likely find a number of results.
    You can manually investigate the software versions on each machine.

Using Dynamic Asset Groups to search for potentially affected machines can save you a lot of time, since you don't have to perform a new scan. This method can be modified and applied to similar scenarios.