My next class:

Automating Vulnerability Scans

Published: 2016-02-03. Last Updated: 2016-02-03 07:44:21 UTC
by Xavier Mertens (Version: 1)
4 comment(s)

Today, I’ll explain you how to automate vulnerability scans. There are plenty of vulnerability scanners on the “market” (commercial or free solutions). Usually, I'm using OpenVAS mainly because it is free.  A lot has been said about this solution, it makes also me sometimes frustrated but, at the end, it is doing a good job. The OpenVAS architecture is based on different components: a manager, one (or more) scanner, command line tools and a web frontend called "Greenbone Security Assistant". Let's focus on the command line tool called "omp" which uses the OpenVAS Management Protocol. This tool proposes a set of command to interact with an OpenVAS manager like:
  • get-targets
  • get-tasks
  • create-tasks
  • start-tasks

The number of action is quite limited and allow only basic tasks. But it provides the “-X” or "--xml” argument which allows us to send raw XML data to the server! This is much more powerful! (a complete reference is available here). To use omp, the very first step is to create a configuration file to automate the connection. Create a $HOME/omp.config file like this:

[Connection]
host=127.0.0.1
port=9390
username=xavier
​password=mystrongpassword
(Don't forget to restrict access to the file because it contains sensitive data!)
 
We are now ready to talk to the OpenVAS manager and to retrieve some data ('--pretty-print' is recommended to increase the visibility):
$ omp --pretty-print --xml "<get_targets/>"
<get_targets_response status_text="OK" status="200">
     <target id="dcc82d64-1c87-44d8-aef5-24c1f552ddcd">
          <owner>
               <name>xavier</name>
          </owner>
          <name>Local Hosts</name>
          <comment></comment>
          <creation_time>2016-02-02T22:12:08+01:00</creation_time>
          <modification_time>2016-02-02T22:12:08+01:00</modification_time>                            
          <writable>1</writable>
          <in_use>1</in_use>
          <permissions><permission>
          <name>Everything</name>
          </permission></permissions>
          <user_tags>
               <count>0</count>
          </user_tags>
          <hosts>192.168.254.0/24</hosts>
          <exclude_hosts></exclude_hosts>
          <max_hosts>254</max_hosts>
          <port_list id="c7e03b6c-3bbe-11e1-a057-406186ea4fc5">
               <name>OpenVAS Default</name>
               <trash>0</trash>
          </port_list>
          <ssh_lsc_credential id="">
               <name></name>
[... stuff removed ...]
Let's create a new scan from the command line. Considering that OpenVAS has already been configured for your environment, the different steps are: 
  • Create a target
  • Create a tasks (and assign the target to it)
  • Start the task
  • Get results
First, to create our target, we send the following XML data. XML data is returned by the command with results (good or bad):
$ omp --xml '
<create_target>
     <name>My New Scan</name>
     <hosts>192.168.254.0/24</hosts>
</create_target>'

<create_target_response id="dcc82d64-1c87-44d8-aef5-24c1f552ddcd" status_text="OK, resource created" status="201"></create_target_response>
The next step is to create a new task. A limitation of the XML interface is that some parameters can be specified by their name while others must be referenced with their internal ID (like the newly created target). We can use command line tools to parse the returned XML and extract the required information:
$ omp --xml ‘...’ | xmlstarlet sel -t -v /create_target_response/@id
dcc82d64-1c87-44d8-aef5-24c1f552ddcd
Now we can create the task:
$ omp --xml '
<create_task>
        <name>My New Scan</name>
        <preferences>
                <preference>
                        <scanner_name>source_iface</scanner_name>
                        <value>eth0</value>
                </preference>
        </preferences>
        <config id="74db13d6-7489-11df-91b9-002264764cea"/>
        <target id="dcc82d64-1c87-44d8-aef5-24c1f552ddcd"/>
</create_task>'

<create_task_response id="8fc4cccd-243f-4edb-a390-5f83d04f90b6" status_text="OK, resource created" status="201"></create_task_response>
We are now ready to launch the vulnerability scan. Let's review the available tasks:
$ omp --xml ‘<get_tasks/>'
And start the one with our new ID:
$ omp —xml ‘<start_task task_id="8fc4cccd-243f-4edb-a390-5f83d04f90b6"/>

<start_task_response status=“200" status_text="OK"/>
Once the task is completed, you can get results in any defined formats:
$ omp --xml '
<get_reports report_id="cc995c30-0a5d-486d-a02f-a03eba63172a"
format_id="c402cc3e-b531-11e1-9163-406186ea4fc5”/>’
Let's think further... If we can talk to an OpenVAS manager via XML, it could be easy to integrate OpenVAS with other tools? Good news: there is a Python library available to control OpenVAS: openvas.omplib.
 
Xavier Mertens
ISC Handler - Freelance Security Consultant
PGP Key
Keywords: automation omp openvas vulnerability scanner xml
4 comment(s)
My next class:

Comments

Nice write-up, but that is a horrible way to have to talk to a tool.

Powerful, but still horrible.

I'll throw in a comment that will insult the Linux peeps, but might give hope to the administrators of Microsoft environments: The communication with this tool can be improved greatly with Excel and Word Mail merge!

Create Word "letters" that build correctly formed XML files. And feed them with data from Excel spreadsheets. I tried this combination with Nagios, and as much as I love vi and other Linux command line tools the Excel + Word combination made me a lot more productive! Add one or 50 IP addresses, and generate/update all the configuration files and settings needed.

And don't underestimate the fact that this allowed me to document my choices and settings with the help of others! They happily assisted with checking boxes in or nominating systems to the inventory spreadsheet we updated each month. I could also pull feeds from other systems.

I actually use the same approach for WSUS now, we extract list of new updates and collections to csv files, collect go/wait decisions from the various teams by area of responsibility and by collection of systems. We mail-merge the input into a PowerShell script that performs the actual WSUS changes. It also reduced the potential of approving the wrong update for a collection!

dotBATman

Anonymous

Feb 4th 2016
8 years ago

Interesting approach! Thank you for sharing.
From a human perspective, it's horrible but the goal is to _automate_. Examples in my diary are just to understand how it works.

Anonymous

Feb 4th 2016
8 years ago

The biggest challenge I have faced with vulnerability scanning is managing the remediation workflow. It's a real chore to keep track of multiple vulnerabilities on hundreds of systems, assign that work to responsible parties, manage exceptions, follow up on progress and deduplicate subsequent scan findings if the initial task hasn't yet been completed. Any suggestions in this area?

Anonymous

Feb 22nd 2016
8 years ago

[quote=comment#36497]The biggest challenge I have faced with vulnerability scanning is managing the remediation workflow. It's a real chore to keep track of multiple vulnerabilities on hundreds of systems, assign that work to responsible parties, manage exceptions, follow up on progress and deduplicate subsequent scan findings if the initial task hasn't yet been completed. Any suggestions in this area?[/quote]

1. (sorry to necro an old thread) :)

But this is an really interesting topic imho.
And not often talked about.

It's easier to test out features, and manage them after a scan.
But when you are handling hundreds of host, things are getting interesting.

We are trying to implement some kind of integration with our ticketing system for Ops ppl.
But so far it's cut'n paste into tickets and monitor the tickets manually.... :(

It works, but it's a horse load of work to manage :)

Any other thoughts?

--
Regards Falk

Anonymous

Oct 11th 2017
7 years ago

Login here to join the discussion.


Top of page
Diary Archives