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!

February 24, 2010
Sample Nessus 4.2 login script (in Ruby)

As a follow-up to Automating Scans on Nessus 4.2, I’ve posted a sample Nessus login Ruby script that connects to the scanner using an HTTP POST request containing the username and password you supply as constants in the script and display a login token. You can then use this token in other scripts to do other, more useful things such as executing a scan, downloading a report etc.

Of course, this is kind of rough but it works. It doesn’t rely on any external library/gem and uses the standard Net::HTTP and URI libs. The code is commented so even if you are not familiar with Ruby, you can understand what’s going on. I’ve tested it on RHEL 5 with ruby 1.8.5 (default version provided with RHEL 5).

If you want to build an (almost) fully-automated environment around Nessus 4.2, this is the first building block. In my case, I integrated similar code in modules/methods for my own automation needs.

Sample run:

$ ruby nessus-connect.rb
e4b692b1d0ffdf69f619561fe7dd22639b7d7fbdc3865b66

If you have comments, please let me know.

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!

Liked posts on Tumblr: More liked posts »