Knowing the structure of Nessus v2 (xml) report may be useful for those who want to analyze scan results in SIEM solution or with own scripts (in this case see also “Retrieving scan results through Nessus API” and “VM Remediation using external task tracking systems“).

Upd. Read this post about practical processing of such reports: “Parsing Nessus v2 XML reports with python”

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.

Scan results are grouped by the host identifier (ip of domain name). All vulnerabilities for the host 192.168.0.1 are stored in the block <ReportHost name=”192.168.0.1″>…</ReportHost>. And each vulnerability can be found in <ReportItem>…</ ReportItem> block in ReportHost.

Of course, sometimes it can be less optimal, for example if a big amount of hosts have the same vulnerabilities. But in my opinion, this report format is easier to handle. In addition, it allows you to store the output for every detection script for each host independently (and it may vary a lot).

Let’s see how OpenSSL vulnerability in Nessus v.2 report:

<ReportItem port=”443″ svc_name=”www” protocol=”tcp” severity=”1″ pluginID=”91572″ pluginName=”OpenSSL AES-NI Padding Oracle MitM Information Disclosure” pluginFamily=”General”>
<bid>89760</bid>
<cpe>cpe:/a:openssl:openssl</cpe>
<cve>CVE-2016-2107</cve>
<cvss_base_score>2.6</cvss_base_score>
<cvss_vector>CVSS2#AV:N/AC:H/Au:N/C:P/I:N/A:N</cvss_vector>
<description>The remote host is affected by a man-in-the-middle (MitM) information disclosure vulnerability due to an error in the implementation of ciphersuites that use AES in CBC mode with HMAC-SHA1 or HMAC-SHA256.
The implementation is specially written to use the AES acceleration available in x86/amd64 processors (AES-NI). The error messages returned by the server allow allow a man-in-the-middle attacker to conduct a padding oracle attack, resulting in the ability to decrypt network traffic.</description>
<edb-id>39768</edb-id>
<fname>openssl_AES_NI_padding_oracle.nasl</fname>
<iava>2016-A-0113</iava>
<in_the_news>true</in_the_news>
<osvdb>137896</osvdb>
<patch_publication_date>2016/05/03</patch_publication_date>
<plugin_modification_date>2016/07/19</plugin_modification_date>
<plugin_name>OpenSSL AES-NI Padding Oracle MitM Information Disclosure</plugin_name>
<plugin_publication_date>2016/06/13</plugin_publication_date>
<plugin_type>remote</plugin_type>
<risk_factor>Low</risk_factor>
<script_version>1.4</script_version>
<see_also>https://blog.filippo.io/luckyminus20/
http://www.nessus.org/u?37b909b6
https://www.openssl.org/news/secadv/20160503.txt</see_also>
<solution>Upgrade to OpenSSL version 1.0.1t / 1.0.2h or later.</solution>
<stig_severity>I</stig_severity>
<synopsis>It was possible to obtain sensitive information from the remote host with TLS-enabled services.</synopsis>
<vuln_publication_date>2016/05/03</vuln_publication_date>
<xref>OSVDB:137896</xref>
<xref>EDB-ID:39768</xref>
<xref>IAVA:2016-A-0113</xref>
<plugin_output>Nessus was able to trigger a RECORD_OVERFLOW alert in the remote service by sending a crafted SSL &quot;Finished&quot; message.</plugin_output>
</ReportItem>

Now compare how information about this vulnerability looks in Nessus csv report:

Plugin ID,CVE,CVSS,Risk,Host,Protocol,Port,Name,Synopsis,Description,Solution,See Also,Plugin Output
“91572”,”CVE-2016-2107″,”2.6″,”Low”,”vulnerable_host.com”,”tcp”,”443″,”OpenSSL AES-NI Padding Oracle MitM Information Disclosure”,”It was possible to obtain sensitive information from the remote host with TLS-enabled services.”,”The remote host is affected by a man-in-the-middle (MitM) information disclosure vulnerability due to an error in the implementation of ciphersuites that use AES in CBC mode with HMAC-SHA1 or HMAC-SHA256. […]”,”Upgrade to OpenSSL version 1.0.1t / 1.0.2h or later.”,”https://blog.filippo.io/luckyminus20\nhttp://www.nessus.org/u?37b909b6…”,”Nessus was able to trigger a RECORD_OVERFLOW alert in the remote service by sending a crafted SSL “”Finished”” message.”

As you may see XML report is much more informative:

If you look in the official manual, it will be clear that this xml does not contain all available parameters. The thing is these parameters are taken directly from the detection nasl script. If there is no such parameter in the script, it won’t be in the results.

Parameter initialization in nasl script:

….
script_cve_id(“CVE-2016-2107″);
script_bugtraq_id(89760);
script_osvdb_id(137896);
script_xref(name:”EDB-ID”, value:”39768″);
script_xref(name:”IAVA”, value:”2016-A-0113″);

script_name(english:”OpenSSL AES-NI Padding Oracle MitM Information Disclosure”);
script_summary(english:”Checks if the server sends a RECORD_OVERFLOW alert to a crafted TLS handshake.”);
…
script_set_attribute(attribute:”plugin_type”, value:”remote”);
script_set_attribute(attribute:”cpe”, value:”cpe:/a:openssl:openssl”);
script_set_attribute(attribute:”in_the_news”, value:”true”);
script_set_attribute(attribute:”stig_severity”, value:”I”);
script_end_attributes();
…

If some parameters are not set up in the script it may lead to errors. For example, in the case above we have a linke to Exploit-DB 39768, and nothing about exploit_available and exploitability_ease parameters. Thus, if we are using exploit_available or exploitability_ease fields for prioritizing, we may actually skip this exploitable vulnerability. Be careful!

It is great that Nessus scripts are human readable and parsable, so we can simply find out that the problem actually exists. In the case of a closed knowledge base, we may never know about it. Another argument in favor of openness of VM solutions (see my previous post “Vulnerability scanners: a view from the vendor and end user side“).

Alexander Leonov

Hi! My name is Alexander and I am a Vulnerability Management specialist. You can read more about me here. Currently, the best way to follow me is my Telegram channel @avleonovcom. I update it more often than this site. If you haven’t used Telegram yet, give it a try. It’s great. You can discuss my posts or ask questions at @avleonovchat.

А всех русскоязычных я приглашаю в ещё один телеграмм канал @avleonovrus, первым делом теперь пишу туда.