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.

It’s been a few days that I decided to host my blog on Tumblr. The feature set, UI and companion applications offered by this popular blogging platform suits my needs and give me a lot of flexibility with regard to my posting patterns.

One of the features it offers is the possibility to publish posts by sending emails to a private email address. This is particularly nice if you are on the road with no or intermittent Internet access for example. You can just write the email and “send” it. It will be then queued for delivery by your mail client. Moreover, email posting is very flexible as you can use Markdown to nicely format your post.

However this flexibility comes at a cost in terms of security. Earlier today, Sascha and I tested the security of this service. I gave him my private email address -something an “attacker” might obtain while shoulder surfing for example- and he successfully posted to my blog using his own email address and without faking the email headers of my regular mail client. And as my blog is configured to automatically push posts to Twitter and FaceBook, his fake post appeared there as well.

Tumblr doesn’t notify when someone posts from an email address that was never used before and there is no access list functionality that allows you to whitelist the email addresses authorized to post to your blog. Last but not least, I haven’t found a way to turn off email posting altogether.

Sascha has a very nice write-up about this. Highly recommended read!

Conclusion: Protect your Tumblr private email address dearly.