There is a good official Tenable manual: Nessus v2 File Format. If you want to get a detailed description of this format i recommend you to read it.
Here I would like to share my impressions, explain how to retrieve useful information from the scan report easily and note some dangers during the processing that may lead to incorrect prioritisation of vulnerabilities.
Nessus report contains information about the actual scanning results (Report) and the scan settings (Policy). Sometimes it is very useful to look at a scanning policy for debugging. But in most cases we just need proper information about detected vulnerabilities. Therefore, we examine Report section.
The common task. Уou need to find all information about some vulnerability: how critical the bug is, whether there is a public exploit, which vendors already released patches, which vulnerability scanner can detect this bug in the system. Previously, you had to search it all manually in dozens of sources (CVEDetails, SecurityFocus, Rapid7 DB, Exploit-DB, CVEs from MITRE / NIST, vendor newsletters, etc.) and analyze the collected data. Today, this routine can be (and should be!) automated with specialized services. One of these services – Vulners.com, the coolest search engine for bugs. And what is the most important – it’s free and has an open API. Let’s see how it can be useful for us.
What is it?
Vulners is a very large constantly updating database of Information Security content. This site lets you search for vulnerabilities, exploits, patches, bug bounty programs the same way a web search engine lets you search for websites. Vulners aggregates and presents in convenient form seven major types of data:
Vendor’s security bulletins. This bug-reports are published by software vendors and contain information about vulnerabilities in their own products. At current moment Vulners supports various Linux distributions (Red Hat, CentOS, Oracle Linux, Arch Linux, Debian, Ubuntu, SUSE), FreeBSD, network devices (F5 Networks, Cisco, Huawei, Palo Alto Networks), popular and critical software (OpenSSL, Samba, nginx, Mozilla, Opera), including CMS (WordPress, Drupal).
Exploits from Exploit-DB, Metasploit and 0day.today. Exploits are parsed and stored in full-text form and you can read the sources in a convenient text editor.
We communicated with a Tenable customer support and it brought some results. Now you can find a new plugin #91572 “OpenSSL AES-NI Padding Oracle MitM Information Disclosure” in Nessus plugin search (by CVE id CVE-2016-2107).
I have tested a vulnerable server with High-Tech Bridge service:
Then scanned it with Nessus. Note, that you can select only one plugin “General -> 91572” in your Nessus scan policy to speed up the scanning. This plugin does not have any dependencies.
As you can see, now the Nessus detects this vulnerability correctly.
The screenshot shows that it took more than a month, but after all this detection plugin was realized. And I hope my support tickets also played some role.
Therefore, I recommend, if it is possible, to validate your vulnerability scan results with additional scanners/services and REPORT your vendor the differences. It will help to achieve a better security level for your infrastructure and will make the your vendor’s products better.
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.
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.
OpenSSL vulnerabilities appear regularly. Sometimes it is difficult to find out whether your vulnerability scanner can effectively detect specific vulnerability.
In fact, the only way to find this out is to scan a vulnerable host. Without this knowledge, it is dangerous to start a huge network scanning. You never know, the scanner did not find a vulnerability, because the infrastructure is safe or it wasn’t able to do it.
Let’s make the simplest stand: CentOS host with Apache and a self-signed OpenSSL certificate.
This is my personal blog. The opinions expressed here are my own and not of my employer. All product names, logos, and brands are property of their respective owners. All company, product and service names used here for identification purposes only. Use of these names, logos, and brands does not imply endorsement. You can freely use materials of this site, but it would be nice if you place a link on https://avleonov.com and send message about it at email@example.com or contact me any other way.