Nessus 4.2: .nessus v2 file format for the masses

Since the release of Nessus 4.2, a new report file format -dubbed v2 or .nessus v2- has been pushed forward. Quoting Tenable Network Security:

‘An updated .nessus file format (.nessus v2) is now available, which allows for easier parsing of report data Descriptions can now be split into different labels such as CVSS base scores, risk factors and more. A “HostProperties” section contains information about each host which can be extracted easily (MAC addresses, operating system, etc.)’

While maintaining the XML encoding of the old .nessus v1 format, the new .nessus v2 format is, as Tenable Network Security wrote, easier to parse. But enough talking and let’s delve a bit into this new format, shall we?

What Does It Look Like?

A picture is worth a thousand words, right? ;-)

If you were accustomed to the .nessus v1 format, one of the first things you would notice is that the root node is now NessusClientData_v2 instead of NessusClientData. Moreover, each scanned host (ReportHost node) has now a nice HostProperties subnode.

HostProperties provide a set of subnodes all named tag but which have different attributes. The following tag nodes are always present:

• tag name="HOST_END": time at which the scan has finished
• tag name="HOST_START": time at which the scan has started

The following tag nodes are not always present as they depend on whether or not Nessus is able to discover some extra information about the host:

• tag name="operating-system"
• tag name="mac-address"
• tag name="host-ip"
• tag name="host-fqdn"
• tag name="netbios-name"

Vulnerabilities, Defined

Often, I use Nessus to detect remotely-exploitable vulnerabilities only (as I consider that once an attacker has a foothold on a system, it’s game over for the defender no matter what privileges the attacker had at the beginning). In this particular case, the ReportItem node has 7 attributes:

• port: TCP/IP port on which the vulnerability was detected
• svc_name: service name
• protocol: do I really need to explain this one?
• severity: a value ranging from 1 (low) to 3 (high) evaluating how critical the vulnerability is
• pluginID: Nessus plugin identifier
• pluginName: human-readable name of the plugin
• pluginFamily: family to which the plugin belongs to.

Here is an example:

ReportItem port="80" svc_name="http?" protocol="tcp" severity="3" pluginID="33849" pluginName="PHP < 4.4.9 Multiple Vulnerabilities" pluginFamily="CGI abuses"

Each ReportItem node has several children, some of them not always present:

• synopsis: a brief description of the vulnerability
• description: a more thorough description of the vulnerability
• solution: vulnerability remediation
• risk_factor: human-readable form of the severity attribute (Low, High…)
• cvss_vector: CVSS v2 vector
• cvss_base_score: CVSS v2 base score
• see_also: contains a URL for further reference. There might be zero or more of such elements
• plugin_output: if present, this element provides the output of the plugin
• plugin_version: plugin revision information. This can be useful when you need to check whether you have the latest version or not
• bid: provides the Bugtraq ID. There might be zero or more of such elements
• cve: provides CVE data. There might be zero or more of such elements
• xfref: provides pointers to other vulnerability databases such as OSVDB
• plugin_publication_date: well, I guess you can see what it may contain. Not always present
• vuln_publication_date: same here ;-) and not always present too.

Important Note

As Renaud Deraison pointed out, the list of subnodes under ReportItem is meant to be “open”. Tenable Network Security can and will add new fields to it from time to time. So if you are writing a .nessus v2 format parser, it must ignore unhandled nodes instead of raising errors.

Well…

… I think this is pretty much what you need to know about the Nessus v2 report file format. If you spot any mistake or any missing important piece of information, please let me know by commenting on this blog entry.

Until, then I wish you some happy parsing and fiddling with XPath ;-)

—> Edited on 2010/03/02 to Add: Note about the list of ReportItem subnodes being “open” + remove XML tag “<” and “>” in the ReportItem example and the tag subnodes because they are not displayed correctly by Google Reader.