This blog post is about the process we went through trying to better interpret the masses of scan results that automated vulnerability scanners and centralised logging systems produce. A good example of the value in getting actionable items out of this data is the recent Target compromise. Their scanning solutions detected the threat that lead to their compromise, but no humans intervened. It’s suspected that too many security alerts were being generated on a regular basis to act upon.
The goal of our experiment was to steer away from the usual data interrogation questions of “What are the top N vulnerabilities my scanner has flagged with a high threat?” towards questions like “For how many of my vulnerabilities do public exploits exist?”. Near the end of this exercise we stumbled across this BSides talk “Stop Fixing All The Things”. Theses researchers took a similar view-point: “As security practitioners, we care about which vulnerabilities matter“. Their blog post and video are definitely worth having a look at.
At SensePost we have a Managed Vulnerability Scanning service (MVS). It incorporates numerous scanning agents (e.g. Nessus, Nmap, Netsparker and a few others), and exposes an API to interact with the results. This was our starting point to explore threat related data. We could then couple this data with remote data sources (e.g. CVE data, exploit-db.com data).
We chose to use Maltego to explore the data as it’s an incredibly powerful data exploration and visualisation tool, and writing transforms is straight forward. If you’d like to know more about Maltego here are some useful references:
What we ended up building were:
- Transforms to explore our MVS data
- A CVE / exploit-db.com API engine
- Transforms to correlate between scanner data and the created APIs
- Maltego Machines to combine our transforms
So far our API is able to query a database populated from CVE XML files and data from www.exploit-db.com (they were kind enough to give us access to their CVE inclusive data set). It’s a standalone Python program that pulls down the XML files, populates a local database, and then exposes a REST API. We’re working on incorporating other sources – threat feeds, other logging/scanning systems. Let us know if you have any ideas. Here’s the API in action:
Parsing CVE XML data and exposing REST API
Querying a CVE. We see 4 public exploits are available.
It’s also worth noting that for the demonstrations that follow we’ve obscured our clients’ names by applying a salted ‘human readable hash‘ to their names. A side effect is that you’ll notice some rather humorous entries in the images and videos that follow.
Jumping into the interesting results, these are some of the tasks that we can perform:
- Show me all hosts that have a critical vulnerability within the last 30 days
- Show me vulnerable hosts for which public exploit code exists
- Show me all hosts for which a vulnerability exists that has the word ‘jmx-console’ in the description
- Show me all hosts on in my DMZ that have port 443 open
- Given a discovered vulnerability on a host, show me all other hosts with the same vulnerability
- Show me a single diagram depicting every MVS client, weighted by the threat of all scans within the last week
- Show me a single diagram depicting every MVS client, weighted by the availability of public exploit code
- Given a CPE, show me all hosts that match it
Clicking the links in the above scenarios will display a screenshot of a solution. Additionally, two video demonstrations with dialog are below.
Retrieving all recent vulnerabilities for a client ‘Bravo Tango’, and checking one of them to see if there’s public exploit code available.
Exploring which clients/hosts have which ports open
In summary, building ‘clever tools’ that allow you to combine human insight can be powerful. An experiences analyst with the ability to ask the right questions, and building tools that allows answers to be easily extracted, yields actionable tasks in less time. We’re going to start using this approach internally to find new ways to explore the vulnerability data sets of our scanning clients and see how it goes.
In the future, we’re working on incorporating other data sources (e.g. LogRhythm, Skybox). We’re also upgrading our MVS API – you’ll notice a lot of the Maltego queries are cumbersome and slow due to its current linear exploration approach.
The source code for the API, the somewhat PoC Maltego transforms, and the MVS (BroadView) API can be downloaded from our GitHub page, and the MVS API from here. You’ll need a paid subscription to incorporate the exploit-db.com data, but it’s an initiative definitely worth supporting with a very fair pricing model. They do put significant effort in correlating CVEs. See this page for more information.
Do get in touch with us (or comment below) if you’d like to know more about the technical details, chat about the API (or expand on it), if this is a solution you’d like to deploy, or if you’d just like to say “Hi”.