Last updated at Mon, 31 Jul 2017 17:45:48 GMT

In vulnerability management and practices like it, including simple vulnerability assessment, down and dirty penetration testing, and compliance driven auditing, when a target is tested for the presence of a particular vulnerability, in addition to the binary answer for "Is it vulnerable or not?" oftentimes additional data will be provided that adds some confidence to that conclusion by explaining how it was reached. At Rapid7, for Nexpose, we typically refer to this data as the proof for a particular vulnerability. The purpose of this post is to talk briefly about proofs, what they are, and why they are important.

What is a Proof?

A proof in Nexpose serves to avoid reliving situations like this from Math classes in school, courtesy of the Frazz comic:

At the core of a VM solution is the fundamental ability to assess a target for the presence of a vulnerability.  This ability is not magic, and the method used to obtain the answer is often nearly as important as the answer itself.  In other words, while it is great for a VM solution to be capable of giving 100% accurate results, without this proof data for each finding, that VM solution may get a less than stellar report card.

A vulnerability proof in Nexpose is composed of the results of executing a variety of tests used to ascertain the existence of a given vulnerability.  Take a relatively simple vulnerability, like CVE-2007-6203, a reflected XSS vulnerability in Apache HTTPD.  Broken down into a series of smaller, simpler steps, Nexpose:

  1. Tests that an HTTP/HTTPS service exists
  2. Tests that this service looks to be Apache HTTPD
  3. Tests that a request with a malicious HTTP request method has this method reflected back in the error response unfiltered, allowing XSS, when the specified Content-Length header is too large

Each of these steps records its own proof result, and they are all combined to form the final proof for the vulnerability which is in turn stored and made available in a variety of places in Nexpose.  In a more complicated scenario, for example if there are multiple ways of checking for a vulnerability, such as the existence of a patch, version of a library or registry key, Nexpose will record all of the results from each method and until it is confident that the system is definitively vulnerable or invulnerable.

Why Proofs?

As to why these proofs are important, consider some of the people who might need benefit from knowing the how or why and not just the what:

  • Security Teams: while a vulnerability with a CVSS score of 10 may warrant an immediate response, security teams may be considerably more confident in their response if Nexpose can provide some level of proof that this vulnerability really does exist
  • Operations Teams: simply saying that a target is vulnerable may not be enough to justify risking applying a patch or taking down a critical system
  • Rapid7 support and development: false positives and false negatives in VM are, arguably, an unavoidable fact of life in the VM space. So when a team at Rapid7 is involved in a such a case, it can be invaluable to see this proof data, which allows us to retrace Nexpose's steps

Where is my pudding?  Where are the Proofs?

While the proofs are a critical part of Nexpose, proofs are only displayed in situations where the proof data is useful. In general, you'll find no hint of any proof-like data until you start drilling down into the finer vulnerability details at the individual asset level.  For example, you can find it in the UI when viewing the vulnerability results for a single asset:

Proof data can also be found in appropriately detailed reports, for example the Nexpose Audit Report or the everything-including-the-kitchen-sink report, the XML export.

As previously mentioned, the core of a VM solution is its vulnerability assessment capabilities, but a frequently ignored topic is that of the invulnerable results.  Proof data for invulnerable results can be used to validate a VM solution's negative findings, but because Nexpose and tools like it are essentially just vulnerability scanners and not invulnerability scanners, the proofs for invulnerable results are not currently readily available except through an XML export report that explicitly enables them:

Be warned, though, that any report that contains the invulnerable results will likely be significantly larger than its vulnerable-results-only counterpart for the simple fact that most targets will invulnerable to vastly more vulnerabilities than not.

Finally, we'd love to hear your feedback on vulnerability proofs, so please leave a comment here, drop a message in our Nexpose community forum or use the appropriate support mechanism.  We'd love to hear about how you are using vulnerability proofs or how we could improve them to assist in your VM practice.

Enjoy!