So tonight, I added that. New commands added are:

• nessus_save: this will save those 4 items to ~/.msf3/nessus.yaml
• nessus_logout will now remove that file when invoked.
• nessus_connect will look for that file and use it’s contents if invoked with no arguments.  If the file doesn’t exist, it will display usage.

So basically, load nessus, nessus_connect admin:admin@myserver:8834 and then nessus_save.  Now each time you load nessus you just need to nessus_connect and it will reuse those saved creds, until you wiped them out with nessus_logout.

Up next is investigating a way to have the nessus.yaml house multiple sets of creds and let you invoke nessus_connect with the set name to login to that server (or the default set if no set name is given).  also need to modify nessus_save to take an argument that it will use for the set name.  Tackle that later this week I guess.

It’s been merged, so svn up and you are set.  Report bugs to me or via the metasploit redmine.

thanks!

1. Nessus IVIL wrapper for Seccubus V2 – I had a wonderful talk with Frank from seccubus a couple of weeks back and we came up with the idea of “IVIL” which is basically a common XML format to report findings in from just about any tool.  I’m going to write an example IVIL aware wrapper for Nessus that will let you create scans, download reports and output in IVIL format to be loaded into seccubus V2.  Ideally anyone could write a wrapper for any tool and convert the tools output to IVIL to be loaded into seccubus for reporting.
2. Bug fixes for the Nessus plugin.  I need to diff out all the new things in the code that are not currently in metasploit and submit that.  Also work on a couple of tweaks and new features people have suggested.
3. Watch some more ruby videos and read some more of my ruby book.
4. Fix up my dev environment.  I am trying to swap over to using Netbeans as my IDE and SVN over SSH to connect to remote servers to test.  Carlos Perez has been great in showing me how this works.  Probably look at moving my dev to a vm on my laptop to repurpose the current hardware as an Astaro box.
5. Look into using meterpreter more and learning about meterpreter scripting in order to use meterpreter as an OVAL interpreter.
6. Work more on learning nasl.  Also looking to create a nasl script to do OVAL scanning of remote hosts directly with nessus.  Lots to do here and nasl is a bit clunky after working with ruby.  Funtimes though.
7. Keep working on my highly threaded http scanning engine.  Basically want something that is fast and scalable for finding http(s) servers on any port.  If one exists now that grabs all kinds of info on what the server/service is, love to see it.  Emphasis on the fast and scalable, talking scanning thousands of hosts and all ports.

That’s all that springs to mind right now.  Still getting over being sick and the whole family being sick after returning from Hack3rcon.

Speaking of Hack3rcon, I had a blast.  I’ll sign off here by embedding my talk on Nessus/MSF Integration.  My first ever talk and I learnt a great deal about presenting with live demo’s.  Redt of the talks are available on irongeek.com

Nessus Bridge for Metasploit Zate Berg from Adrian Crenshaw on Vimeo.

I’ll post the presentation up here once it’s done for everyone else to take a look at.  Actually going to be presenting a few new commands that are not in the metasploit svn version of the plugin.

After Hack3rcon I’ll be back into high gear adding some new functionality to the plugin and branching out into writing a wrapper for Nessus to speak IVIL for Seccubus v2.  This is pretty exciting stuff for me.  Coming up with a xml format to speak “findings” that is tool agnostic is going to be a great thing.  It will mean moving findings between tools, or comparing findings between tools, will be much much easier.  Keep a look out for that one.

There has been some talk on the metasploit mailing list this week about using tools such as Nessus to scan through a MSF pivot and into another network.  Some interesting discussion and I think it’s something I will dive into in these next few weeks.  Start to examine what some of the limitations are and how we might overcome or avoid them.

that’s it for now.  have a good weekend.

Should probably be in the Metasploit svn in a few days, I know those guys are super busy with an upcoming release.

In the mean time you can download it from the GitHub – http://github.com/Zate/Nessus-Bridge-for-Metasploit

Changes:

• Streaming Parser for Nessus V2 Reports.
  • This streams the file from the nessus server and processes each host as it finds it instead of loading the entire file into memory which can be very intensive on large reports.  Performance is much better though it can take a while to interate through large numbers of hosts.
• Added activity indicator on nessus_report_get
• nessus_report_get now displays the OS information as reported by nessus for each host it imports.
• Fixed a bug where you could try to import a running scan.  Now checks to make sure a scan is not currently running when you import.
• added nessus_template_list to show templates.  More work on templates coming.
• Changed nessus_policy_list to use scans/list as the point it gets it’s info from, much faster.
• Added experimental support for a new search index system I am working on that might replace how searches are done in msf.  makes an index on local (or in memory) for searching.  Access is via nessis_exploits
• Fixed bug so that it now checks that the policy exists when creating a new scan.
• added “return” to the -h option in all the commands so that it will not run the command when -h is specified.
• fix various whitespace issues.
• One existing bug is how the scanner gets displayed in db_hosts.  It takes up 2 lines. Working on it.

In Progress:

I am working on redoing the whole search functionality in msf, not just the Nessus Plugin.  This includes typing search at the command prompt, and the searching done by modules and things like db_autopwn.  I think we can move it to searching through index files on local much much faster than  the current way.

Nessus has added exploit information to the reports for each plugin that has a viable exploit in Metasploit (and other exploit engines).  I’m going to try to add this information as a “ref” to each vuln listed in db_vulns.  I still need to go through and check the accuracy of the mappings of plugin to exploit though.

If it’s accurate the next step is to create something like nessus_find_exploits that creates a Nessus scan policy that ONLY scans for vulns with plugins that have a Metasploit exploit attached.  This could be a good recon tool for scanning a network for hosts that are Metasploitable.

Lastly, I’m thinking we need a precision scanning mode, to be able to find an exploit we’d like to use and “scan” a given range of addresses (or just one) for the vuln associated with that exploit.  Two ways I see this working.

1. We could use the vuln scanner of your choice (probably Nexpose or Nessus to begin with) for that specific vuln on that specific port on that host, or any port on any host.
2. Inversely, perhaps now is the time to add a generic “scanner” module to Metasploit that will allow you to lightly and quietly test a host for that vuln for that exploit.

I am leaning towards number 2.  Number 1 would be much easier and quicker to build and use but I also seeing it as being much more “loud” on the network.  I’d almost prefer a precision, tactical, quiet probe of a host to verify that the vuln exists, not a blast across a host or network testing the way a traditional vuln scanner does.  So I’m thinking it’d be hand crafted checks, perhaps added to each exploit module?  Checks that do things like, is the remote host supported a supported target.  Can we actually connect to RPORT and if we send a specific set of information over, does it indicate the host is vulnerable to this exploit.  Need to think on this more.

So, thats the state of the Nessus Plugin for Metasploit right now, sent to msfdev for review and hopefully with less bugs in it than it had before.  It could really use some testing though.  My own test network is very primitive and I am sure there are things I’m missing from my imports.

Thanks.

Next up are the plugin commands.  These helpful little beasts are all about showing you what plugins are available on your nessus server, and how many of them you have.

• nessus_plugin_list
• nessus_plugin_family
• nessus_plugin_details
• nessus_plugin_prefs

Given that nessus has over 38,000 plugins, simply asking it to list them all would result in a very large list returned from the server.  Nessus gets around this by breaking the request down into several parts.

nessus_plugin_list

This will list all the plugin families and show you how many plugins are in each family.  They can range from just a few, to thousands.  The plugin family names returned here are used in further commands.

nessus_plugin_family

Now armed with our plugin family name from the list command above, we can request the names of the plugins from one of the families.  Be warned, for some families this can result in a long list.  Returned from this command is a table showing the plugin ID, plugin name and plugin file name. The file name is what we use to get the plugin details (this strikes me as odd, I would have used the plugin ID as the identifier, the file name is annoying to use.)

nessus_plugin_details

This cool command returns us the details of exactly what the plugin does.  Included are such gems as the risk factor, cvss score(s), cvss vector(s), description, solution, any identifiers such as CVE/BID and details on exploit availability.  As yet the exploit availability does not link to the exploit, though I’d love to see us come up with some common reference method for exploits, similar to CVE (you listening NIST/SCAP people, hop to it).

nessus_plugin_prefs

Lastly, we have the prefs.  This shows the default server/plugin prefs and is quite long.  This is what things will default too if you do not change the setting to what you want in your policy. It returns 3 columns, Name, Value and Type.  Value shows what it’s currently set to and type tells you what kinds of settings it can have.  Really though it’s much easier to change these through the nessus web console right now for each policy.

I’m working on being able to create policies and templates from the command line to be used to do pinpoint scans for specific vulns on specific ports but it’s not there yet.  Missing is the ability to accurately and quickly tie a plugin to an exploit and working with these large entry/value pair lists on the command line is cumbersome.  End goal is to allow you to go through a process to create a scan template for a specific exploit and then scan for it and autopwn it when found.  Still a bit of work to do before I get there.

Thats all for plugins, up next in the series is User Commands.

What I’d like is a few people to test it.

So, grab the code from here, unpack it and then over write your metasploit install with the files in that archive.  Should be 4 of them.

Once you have done that, test it, connect to a Nessus server, import some reports, test all the other functions and maybe even just test some importing of nmap etc too if you like.

Report any bugs to me to be fixed and then when you want to remove these files, just delete these 4 from your metasploit install and then do “svn update”.

Their latest creation (which has been around for a while, just not public) is their very own URL shortener called goo.gl.  It does some of the usual things, it tracks metrics and it does one other things I think is really cool.  It creates a QR code for your url.

Here is one I created earlier (ha, sounds like a cooking show).

http://goo.gl/YgTu.qr for the url http://goo.gl/YgTu

Very cool.  I like QR codes.  For those of us with smart phones, a simple scan of the code and you can open the site.

I do wish the service had an easy way to copy the new urls to the clipboard though.

So what else can it do?  Well #1, I want it to tie in with their safe browsing serivce (http://www.google.com/safebrowsing/diagnostic?site=google.com) so that I can’t create a URL to a known bad site.  I’d also like them to regularly scan the urls and disable those that link to malware.  There are lots of URL shorteners and they definately pose a security risk and it’s about time someone took the step of removing bad URL’s.

Thoughts?

The nexpose importer and the nmap importer both use REXML Stream Processors.

So tonight I copied the nmap_xml.rb file and am working on making it process Nessus v2 files.  I am hoping that both the Nessus plugin, and the db_import will benefit from these changes.

I’ve been looking at it for a few days and kind of avoiding it because it’s difficult and is going to require large portions of my time fumbling through learning how the current one works enough to know how/what to modify.

Well turns out it’s simpler than I thought. In about an hour tonight I copied it, modified it, wrote some code to include it in the plugin and have the plugin send it data and got it parsing the hostname for each entry in a file.

Now I just need to work out what to call at what time with what values to get the hosts, vulns and services in the DB.  I know where that is in the code so I think this might not take me as long as I thought.

Harder will be making the right changes to db.rb to A) make it work, and B) still allow msf to function .. lol

The Scan Commands are where this plugin starts to really differ from previously importing nessus scans from flat files.  With these commands we can stay within the metasploit framework and reach out and examine things with Nessus.  We can then use the Report Commands we just learnt about to pull that data back to later pwn stuff.

Scan Commands are as follows:

• nessus_scan_new
• nessus_scan_status
• nessus_scan_pause
• nessus_scan_pause_all
• nessus_scan_stop
• nessus_scan_stop_all
• nessus_scan_resume
• nessus_scan_resume_all

Lots of those look similar, and in fact they are.  Only difference is one command acts on one scan ID, the other acts on all running scans.

Important to note that these work on scans, not reports.  The difference?  Scan becomes a report after it completes. (Yeah I know running scans show up in the output of nessus_report_list – set myself a task in github to fix that).

Ok, lets start with the boring ones first.

nessus_scan_status

This command shows you the status of all currently running scans.  If you have no running scans, well it wont show you any (see, very accurate).  XML that comes back from the command involved also shows policies and templates.  Future functionality will display those, but for now it just lists running scans and some info about them (such as progress if it is multiple hosts).

(nessus_scan_pause || nessus_scan_stop || nessus_scan_resume) <scan id>

They do exactly what they sound like they might do.  They pause, stop and resume running scans (not reports).  You need to supply the scan id (from nessus_scan_status) and it will return confirmation that it has done the task.

You can also use all 3 commands with _all on the end and no scan ID.  This will iterate through all scans available and do the specified action on them.  Pretty simple.

Ok, that leads us to the bread and butter nessus_scan_new command.

nessus_scan_new <policy id> <scan name> <targets>

No more do you have to drop to a command line or tab over to the web console to start a nessus scan.  You simply need to provide the policy ID for the policy you’d like to scan with (get that from nessus_policy_list), name your scan (use “quotes are cool” for multiple words) and give it the hosts you’d like to scan.  Hosts scan be one (192.168.1.1), a network cidr (192.168.1.0/24) or a range (192.168.1.1-127).  Hit enter and it goes to work.

So with what we have discovered so far we can do the following:

• Auth to our nessus box.
• Start a new scan
• import the results of that scan to our metasploit workspace.

Nice. So what else could there be?

Next up we will learn about the plugin commands for getting all kinds of useful information about the vulnerabilities we discover.

Report commands are where we get to actually do things.  They concist of some commands to manage/import reports directly on your Nessus server.  No more going to the web console, exporting a report, moving it to your msf box and running db_import_nessus to get it into your workspace and available to db_autopwn or work with.

The implemented (so far) commands are:

Ok, make sure you are loaded up and authed to your server and we will check these out.

nessus_report_list

The basic “show me what ya got” command for reports.  It will list off all the reports on your server that your current user has access to.  You will see some big long string of characters, that is your report ID.  It is a unique identifier for each report.  Nessus allows you to call 2 reports the same name, this is how we know which one is which.  This view will be generally how you find the report ID for future commands.

nessus_report_get <report id>

This is the core command here.  This grabs the report from your Nessus server and passes it over to get imported to your msf workspace/db.  You need to have configured a db in msf (via db_connect) to use this command.  It is the same as doing db_import_nessus except that this pulls directly from your remote server.  Warning: dont try to pull a report with thousands of hosts, you will choke your box (need to change this to use a stream processor).  After you import with nessus_report_get you should be able to do db_hosts, db_services or db_vulns and see your data.  You can now proceed with db_autopwn as you would have before.

nessus_report_hosts <report id>

This will show you each host in your Nessus report and some information about each one.  The information is will display is the “severity” of the host (as measured by Nessus) and the number of vulnerabilities in each “severity” category from 0 to 3 with 0 being “info” and 3 being “critical”.  Shows current vs total progress (number of plugins).  If they are not the same it means some of the plugins didn’t complete correctly (i think).

nessus_report_host_ports <host> <report id>

This will show you the ports found on that host and how many vulns of each type per port.  Shows you the port number, the protocol and the severity (1-3).  Also includes the service name and a breakout of how many vulns of each sev type per port.  You will need the port number and protocol if you want details on each vuln for that port.

nessus_report_host_detail <hostname> <port> <protocol> <report id>

Here we see a breakdown of all the vulnerabilities discovered on that host, for that port.  Shows us the port name (and number/service), the severity (as assigned by Nessus), the plugin ID, the plugin name, the CVSS2 score, whether there is an exploit available (doesn’t yet link to a msf exploit if it exists, adding that to my to-do list), the CVE and lastly the CVSS vector (just incase you are into that stuff).  Quite a bit of information that should give you a good idea of what’s going on with that host.

Ok, that’s it for report commands, feel free to let me know if you think it needs to do something else or do something in a different manner.

On to “Scan Commands” the ‘do work!’ part of the run down.