We all want to have a reliable and efficient Vulnerability Scanner. This scanner should be able to find any vulnerabilities immediately, as soon as the information about them is published. And, to be honest, no one wants to research how the scanner do it. Really. It’s not our job. We purchased the product, we trust the vendor and if this product does not work as we would like, it is a vendor’s problem. Is that right?

Not really. If we do not properly recognize the condition of our infrastructure and do not properly assess the risks, because of this vendor’s faults, this would be our problem. It’s relatively easily to find out that some detected vulnerabilities from scanning report are false positives, what if scanner didn’t find an existing vulnerability? How would you even know this happened?

That’s why we still have to understand how the scanners work, to watch the watcher.

A recent example. CVE-2016-2107: OpenSSL AES CBC cipher information disclosure.

upd. For this vulnerability Tenable released addition detection plugin: “Use multiple vulnerability scanners in the name of good”.

This vulnerability may be detected by free vulnerability scanning services and practically could not detected by Nessus via unauthenticated scanning. You can see on the screenshots how we have scanned the same host with Nessus and free service by High-Tech Bridge. And Nessus did not detect CVE-2016-2107.

You can easily test your services with this tool (see post: High-Tech Bridge service and API for SSL/TLS server testing)

Possible results:

• “CVE-2016-2107-PCIDSS”:”The server is not vulnerable to OpenSSL padding-oracle flaw (CVE-2016-2107). [4]”
• “CVE-2016-2107-PCIDSS”:”The server is vulnerable to OpenSSL padding-oracle flaw (CVE-2016-2107), consider upgrading OpenSSL. [5]”
• “CVE-2016-2107-PCIDSS”:”The server may be vulnerable to OpenSSL padding-oracle flaw (CVE-2016-2107), make sure that your OpenSSL version is up to date. [4]”

I also tested using Qualys SSL Labs. (see post: Qualys SSL Labs console client for automation)

Back to Nessus. How is it possible that it doesn’t detect this vulnerability?  What plugins has a link to CVE-2016-2107? I use Nessus plugin search.

Search results:

Full list for 08.06.2016:

90863	Slackware 14.0 / 14.1 / current : openssl (SSA:2016-124-01)	Slackware Local Security Checks
90864	Amazon Linux AMI : openssl (ALAS-2016-695)	Amazon Linux Local Security Checks
90874	Debian DLA-456-1 : openssl security update	Debian Local Security Checks
90876	FreeBSD : OpenSSL -- multiple vulnerabilities (01d729ca-1143-11e6-b55e-b499baebfeaf)	FreeBSD Local Security Checks
90887	Ubuntu 12.04 LTS / 14.04 LTS / 15.10 / 16.04 LTS : openssl vulnerabilities (USN-2959-1)	Ubuntu Local Security Checks
90890	OpenSSL 1.0.1 < 1.0.1t Multiple Vulnerabilities	Web Servers
90891	OpenSSL 1.0.2 < 1.0.2h Multiple Vulnerabilities	Web Servers
90896	Debian DSA-3566-1 : openssl - security update	Debian Local Security Checks
90898	Fedora 23 : openssl-1.0.2h-1.fc23 (2016-05c567df1a)	Fedora Local Security Checks
90913	SUSE SLED12 / SLES12 Security Update : openssl (SUSE-SU-2016:1228-1)	SuSE Local Security Checks
90914	SUSE SLED12 / SLES12 Security Update : openssl (SUSE-SU-2016:1233-1)	SuSE Local Security Checks
90933	openSUSE Security Update : openssl (openSUSE-2016-561)	SuSE Local Security Checks
90934	openSUSE Security Update : openssl (openSUSE-2016-564)	SuSE Local Security Checks
90949	Fedora 24 : openssl-1.0.2h-1.fc24 (2016-1411324654)	Fedora Local Security Checks
91017	CentOS 7 : openssl (CESA-2016:0722)	CentOS Local Security Checks
91029	Oracle Linux 7 : openssl (ELSA-2016-0722)	Oracle Linux Local Security Checks
91033	RHEL 7 : openssl (RHSA-2016:0722)	Red Hat Local Security Checks
91037	RHEL 6 : openssl (RHSA-2016:0996)	Red Hat Local Security Checks
91041	Scientific Linux Security Update : openssl on SL7.x x86_64	Scientific Linux Local Security Checks
91058	Fedora 22 : openssl-1.0.1k-15.fc22 (2016-1e39d934ed)	Fedora Local Security Checks
91067	openSUSE Security Update : openssl (openSUSE-2016-562)	SuSE Local Security Checks
91152	Oracle Linux 6 : openssl (ELSA-2016-0996)	Oracle Linux Local Security Checks
91154	OracleVM 3.3 / 3.4 : openssl (OVMSA-2016-0049) (SLOTH)	OracleVM Local Security Checks
91171	CentOS 6 : openssl (CESA-2016:0996)	CentOS Local Security Checks
91352	Citrix XenServer Multiple Vulnerabilities (CTX212736)	Misc.

As we can see, most of them require authorization (Local Security Checks). For this plugins detection is based on version of installed packages.

Only two plugins should work without authentication:

• 90890 OpenSSL 1.0.1 < 1.0.1t Multiple Vulnerabilities Web Servers
• 90891 OpenSSL 1.0.2 < 1.0.2h Multiple Vulnerabilities Web Servers

I will not publish the code of this plugins here because of Tenable copyright, but you can easily see find them in your installation of Nessus. These plugins only verify that detected version of OpenSSL is less than known safe version for this vulnerability. What is the output of this plugins:

Actually openssl/port was detected, but what about OpenSSL version?

And this is a problem. Nessus doesn’t try to exploit particular vulnerability, but insted tries to detect OpenSSL version by banners. And as you see, it is not work by default.

This check will only run if only “ServerTokens Full” and “ServerSignature On” are enabled on a HTTP server (see my post: Making vulnerable OpenSSL scanning target) and Nessus is configured in paranoid mode (“Assessment” -> “Override normal accuracy” -> “Show potential false alarms”).

Therefore, the only way to detect this vulnerability by Nessus is authenticated scnning with detection based on versions of the packages.
But there are also some problems. Look at the bulletins, which were used for Nessus CentOS plugins:

CESA-2016:0722 Important CentOS 7 openssl Security Update was published Mon May 9 08:40:50 UTC 2016

CESA-2016:0996 Important CentOS 6 openssl Security Update was published Mon May 16 10:25:52 UTC 2016

7days dellay. So, for a week there was no information what OpenSSL version is safe, Tenable couldn’t make CentOS 6 CVE-2016-2107 Local Security Check (plugin 91171), and Nessus didn’t show this vulnerability in CentOS 6 authenticated scans. All this time version of OpenSSL installed on the hosts was by fact vulnerable.

I don’t want to criticize Tenable or any other security scanning vendor in this post. I still consider Nessus one of the best scanning solutions available on a market (see my post: Tenable Nessus: registration, installation, scanning and reporting). The point is that there is no silver bullet in vulnerability scanning and management. You should not trust marketing and always try to find out how it actually works. Also, it is a good practice to use several scanners and services to detect and mitigate false negative errors.