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)
- “CVE-2016-2107-PCIDSS”:”The server is not vulnerable to OpenSSL padding-oracle flaw (CVE-2016-2107). ”
- “CVE-2016-2107-PCIDSS”:”The server is vulnerable to OpenSSL padding-oracle flaw (CVE-2016-2107), consider upgrading OpenSSL. ”
- “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. ”
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.
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.