December 26, 2010
Nessus 4.2 Provides Improved Exploit Availability Information

Back in September, I’ve blogged about a relatively new feature added to Nessus that provides information about the availability of an exploit for vulnerabilities identified during the scan. I wrote then:

This is an incredibly valuable information that will allow you to prioritize your remediation actions. For instance, you could elect to plug critical vulnerabilities for which there is a public exploit then move on to the medium ones for which there is also a public exploit and so on.

This feature has recently improved. The .nessus v2 XML reports tells you now if the exploit is available in Immunity CANVAS and/or Metasploit.

If an exploit is available in CANVAS, the exploit_framework_canvas subnode of the ReportItem XML node will be set to true. Moreover, the canvas_package subnode will tell you in which CANVAS package the exploit can be found.

If an exploit is available in Metasploit, the exploit_framework_metasploit subnode of the ReportItem XML node will be set to true. In case Metasploit has an exploit for the identified vulnerability, the metasploit_name subnode will provide its name. Here is an example:

<metasploit_name>Microsoft ASN.1 Library Bitstring Heap Overflow</metasploit_name>

This is particularly interesting as Metasploit 3.5.x allows you to control Nessus, import the scan results and display only the vulnerabilities for which there is a Metasploit exploit.

9:09am  |   URL: http://blog.upbeat.fr/post/2467152981/nessus-improved-ea
(view comments) 
FILED UNDER: Nessus CANVAS Metasploit exploit security vulnerability 
September 24, 2010
Checking the Availability of Public Exploits with Nessus 4.2

On September 22, 2010, Renaud Deraison announced on the Tenable Network Security discussion forums the availability of new versions of the Nessus 4.2 Flash interface and Web server. This is yet another reminder that you need to check those discussion forums on a regular basis if you are serious about using Nessus.

With these new versions, Nessus 4.2 adds a new field to the scan report which purpose is to tell whether a public exploit exists for a given vulnerability or not. This is an incredibly valuable information that will allow you to prioritize your remediation actions. For instance, you could elect to plug critical vulnerabilities for which there is a public exploit then move on to the medium ones for which there is also a public exploit and so on.

This new field or, more exactly, subnode of the ReportItem XML node of the .nessus v2 report format is called exploit_available. It is a boolean. For more information on the .nessus v2 report format, please see my Nessus 4.2: .nessus v2 file format for the masses blog post.

Using the Web interface, you can find out which vulnerabilities have a public exploit by checking the Exploits exist checkbox in the Show Filters menu as shown by the screenshot below:

This filter will then show up under the Active Filters section:

Now you can see which vulnerabilities are really worth mitigating ASAP:

11:35pm  |   URL: http://blog.upbeat.fr/post/1180745142/nessus-public-sploit-check
(view comments) 
FILED UNDER: Nessus Nessus 4.2 vulnerability public exploit exploit New feature 
September 20, 2010
HTML 5 Security: Good, Bad, or Both?

In a recent and excellent post, Paul Roberts from ThreatPost explored the security of HTML 5, the upcoming version of the markup language that fuels the Web.

The post provides an overview of the major security features of the new specification. It also conveys the concerns security experts have with what will probably be the vector of a new Web revolution.

Quoting Adam Barth of the University of California, Berkeley, Paul Roberts writes:

HTML5 actually specifies how HTML code should be parsed by Web browsers. Previous iterations of the language left it up to individual platform vendors to develop their own interpretations of how the code should be parsed, which led to differences in how the language was rendered on different browsers. That also created opportunities for attackers to exploit quirks in the HTML parsing of specific browsers in Cross Site Scripting and other Web based attacks…

While this might be considered good news, given the current difference in HTML 4 implementation among browsers, I am bothered with the use of should instead of must in the sentence above. At any rate, I don’t see how HTML 5 would enforce similarity in parsing. Would a website refuses to display an HTML 5 page unless the browser which made the request is on a list of 100% compliant browsers?

Let’s assume that HTML 5 can tell browsers how they must parse it. Will we end up with a class break across all HTML 5 ready browsers shall the specification suffer from a vulnerability that affects its design?

Further down, still quoting Adam Barth, Paul Roberts writes:

New features are also intended to make HTML5 more secure than its predecessors. Among them is a new sandbox attribute that allows Web sites that use iFrames to aggregate untrusted content from external sources to run it in a secured environment. The postMessage() feature, for cross document messaging, allows secure communication between different web sites in the browser…

This sounds like a major security feature in HTML 5. The ability of controlling external input while serving it to the browser looks like a good way to thwart the problems we currently have with mash-ups and similar content aggregation techniques. However, problems have already been found with the technique:

The new sandboxing and postMessage() features are examples of tools that, if not used properly, could fail to provide protection against hacks, or even enable new types of attacks. Veracode, in its analysis of HTML5,  raised red flags about the security of the postMessage() feature, as well, noting that Web applications that use cross-document messaging could be vulnerable to attack from malicious Web sites, which could spoof rogue messages.

Among other concerns:

“HTML5 has an enormous amount of functionality. The (specification) is just huge,” said Jeremiah Grossman of Web security firm WhiteHat. The breadth of the new specification gives him concern. “I know that we’re still finding vulnerabilities in HTML4,” Grossman said.

And:

“With any new functionality you’re going to have new security concerns. HTML5 is going to increase the attack surface considerably,” said Neil Daswani of Web security firm Dasient.

So HTML 5 is a huge specification that offers a huge attack surface. Are we calling for disaster here? I hope that the persons who are involved in its development have more that functionality in their minds and agendas.

Moreover:

HTML5’s ability to support native rendering of audio and video files could allow attackers to take advantage of security vulnerabilities in supported audio and video file formats for Web based attacks…

During CanSecWest 2008, Thierry Zoller and Sergio Alvarez from the now-defunct n.runs company demonstrated many ways to exploit parsing bugs in anti-virus software to circumvent them or exploit them to get a foothold on the systems on which they run. This is due to their support of many, different file formats. I guess you see know what I am aiming at. Need another example? Wireshark, the ubiquitous network sniffing software, has suffered from many vulnerabilities due to parsing bugs in its implementation of a wide array of protocols. I clearly don’t see why HTML 5 wouldn’t suffer from the same types of mistakes.

One other area of concern is HTML 5 support for event handlers:

HTML5’s broader support of event handlers on HTML elements could defeat blacklist filters designed to allow HTML but block scripting.

And while this major revision of HTML is still under development, sites such as YouTube are already adopting it:

Grossman said he sees support for HTML5 in around 10% to 12% of the 2,000 Web sites his firm monitors. It could be three years or more before the security implications of the new capabilities in HTML5 are fully grasped, he said.

5:07pm  |   URL: http://blog.upbeat.fr/post/1156161291/html5-security
(view comments) 
FILED UNDER: HTML 5 security analysis vulnerability Threatpost 
March 11, 2010
Nessus 4.2: Displaying Scan Differences Using XMLRPC

On Tenable Network Security’s Nessus Discussions Forum, user Steve Chan asks whether it is possible to use the XMLRPC interface of Nessus 4.2 to display the differences between a scan report and another one, used as a comparison baseline.

This is one of the new features offered by Nessus 4.2 and one that I haven’t felt the need to fiddle with since I do all my comparisons using home-cooked scripts during .nessus v2 file post-processing. But those of you who’d rather use the native XMLRPC interface have a way out as Renaud Deraison pointed out:

to compare reports f2525b2f-8f30-70a0-2e12-2324323c96599c9136dce42ef3db (old) and fbaacdfb-6fc2-2a0c-168b-de748fd0c00dc6f8f750bde6933f (new), you’d do

wget --post-data 'token=xxxx&report=diff-fbaacdfb-6fc2-2a0c-168b-de748fd0c00dc6f8f750bde6933f-f2525b2f-8f30-70a0-2e12-2324323c96599c9136dce42ef3db' https://your.scanner/file/report/download/

As you can see you’d need to keep track of the report UUIDs (unique identifiers to distinguish between each report) and if you are scanning multiple sites, you’d need to keep track of which UUID corresponds to which site and what is the baseline etc. This usually means some kind of a database.

To spare myself the hassle of maintaining yet another piece of software and yet more code to talk to a database, I opted for another option. I generate my own UUIDs but instead of random numbers and letters I use the site’s name and current date (up to the usec) as the readableName (the human-readable name you can associate with each scan you submit to Nessus 4.2).

10:20am  |   URL: http://blog.upbeat.fr/post/440903554/nessus-4-2-displaying-scan-differences-using-xmlrpc
(view comments) 
(No. OF NOTES: 2)
  
FILED UNDER: Nessus Nessus 4.2 Scan Automation Scanner vulnerability xmlRpc 
March 1, 2010
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? ;-)

Nessus v2 report file format

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.

5:44pm  |   URL: http://blog.upbeat.fr/post/420089425/nessus-v2-file-format
(view comments) 
FILED UNDER: Nessus Nessus 4.2 .nessus XML XPath Description Vulnerability Scanner Security 
February 25, 2010
Nessus 4.2 and login tokens

As I wrote in Automating scans on Nessus 4.2, scan automation on Nessus 4.2 is done over HTTPS using the XMLRPC interface introduced by this new major release of the popular vulnerability scanner. You do this by submitting POST requests to the scanner.

The first step toward automation is to obtain a login token (think cookie). There are many ways to do so. You can use wget for instance:

wget --no-check-certificate --post-data 'login=username&password=password' \ https://my.nessus.scanner:8834/login -O -

Or you can make your own code as I demonstrated with the sample Nessus login script in Ruby.

Given the login token, you can submit further POST requests for launching scans, downloading reports and making different sorts of interaction with your scanner. However, a login token, pretty much like a cookie, expires. And if someone/something logs to the scanner with the same user/password in the time between when your scripts obtained the token and when they started using it, your login token is no longer valid.

There is also the problem of sharing a freshly obtained login token between different scripts that may run in parallel: a script for submitting a scan, another for downloading reports, yet another one for deleting older reports etc.

One way of solving this issue is to use a method/subroutine that is called by your scripts whenever they need to use or grab a login token and a local file to store such token. I implemented one using the following flow chart:

Flow Chart

To check the validity of the token (the Is valid? part of the flow chart), you can do a simple POST operation such as listing the reports or the scan policies and checking whether the status of the reply is OK. If that’s not the case, this means the token is no longer valid.

You need also to make sure that you implement strong permissions on the file that will contain the token and if you need to write to it, you need to use an exclusive lock to avoid any concurrency troubles.

There are certainly other ways for doing this but this the way I implemented on my side and it pretty much works!

2:16pm  |   URL: http://blog.upbeat.fr/post/411118099/nessus-tokens
(view comments) 
FILED UNDER: Nessus automation scanner Vulnerability Token Nessus 4.2 
February 23, 2010
Automating scans on Nessus 4.2

With the release of Nessus 4.2, the nessus command-line client has been deprecated. Even if it still distributed with the new release, there is no new functionality introduced to it. Moreover, it is only able to generate Nessus v1 format reports and not the new Nessus v2 reports that are far easier to parse and better organized.

Automating scans with Nessus 4.2 can be performed by leveraging the new XMLRPC interface. All you need is something to generate HTTP POST requests with the right parameters and something to parse the XML responses you get back.

As of this writing, official Nessus documentation to do so is not available yet. However, a few mail exchanges with Renaud Deraison, Chief Research Officer at Tenable Security Inc. got me started and he provided very useful tips that I’d like to share with you in case you need to automate scans as I do.

To issue requests, you need to submit a login token (which you can think of as a cookie) to the Nessus scanner to prove your identity. So the first you need to do is to login to the scanner and retrieve a login token.

But first let me define a base URL that I am going to use throughout in this post: https://my.nessus.scanner:8834. Replace my.nessus.scanner with the FQDN of your Nesssus scanner, its IP address or even localhost if you are interacting with it on the same box that it is installed on.

Nessus uses a self-signed certificate so you’d need to make provisions in your programs/scripts for this. Also, please note that we are using the same TCP port that you’d use with a traditional browser.

Login to the scanner

When you issue a login request, Nessus will reply with a login token. You can think of this token as a cookie. This is all you need to authenticate to Nessus from now on. A login token looks like: 81d64733f78b6a6d34217bfedff12b3244ec20d015d26a0a

Launch a new scan

The policy_id parameter is the scan policy identifier. Obviously, you will need to use your browser to create a scan policy first so that you can have this ID. The scan_name is a human-friendly name for your scan. This is the same thing when you launch a scan using the Web UI. Please note that Nessus uses a unique scan identifier (uuid) that looks like this: 60c6eaa3-5063-0a70-bf33-c00b71d4cfaf97af24f344d0bfa1

To download or delete a scan report, you will need this uuid.

List current scans/reports

If a scan is completed (i.e. a scan report is ready), its status subnode in the XML response you receive back (each scan/report has a corresponding report node) is shown as completed.

Download a report

The report parameter is the report UUID.

Delete a report

This should be enough to get you started. In upcoming posts, I will give more detailed examples and some code snippets that might prove useful.

Big thanks to Renaud for providing some precious help!

EDITED TO ADD (2010.03.31): Apparently, you need to use a non administrator account to be able to interact with Nessus 4.2 the way I describe it as Chris Counselman pointed out in the comments below. Thanks Chris!

4:22pm  |   URL: http://blog.upbeat.fr/post/407107943/automating-scans-on-nessus-4-2
(view comments) 
FILED UNDER: Nessus Vulnerability Scanner Security I.T. Automation Scan Automation XML XMLRPC Security Tool Tenable Security Inc. 
Liked posts on Tumblr: More liked posts »