Tl; dr version – I made a thing that makes the bulk of CVE vulnerability details easy to grep for use when reporting. Get it here: https://github.com/cornerpirate/cve-offline. I update it once a month from the NIST database.
Anyone sticking around to read the rest gets a process for checking for known weaknesses in a service. Rationales for why, as well as a bit about how to use CVE-Offline.
Rationale and Process for vulnerability identification
When writing penetration test reports you will need to interact with many online resources to do that well. The simplest thing that you should do is include a summary of any known weaknesses within an installed version of software.
The biggest database of shared vulnerability knowledge is the CVE database. An overview of that is available at the URL below:
Almost every vulnerability in common services will result in a vendor patch AND an entry with a unique CVE identifier. When you are targeting a customer you need to compile a list of known flaws. This is so you can advise them of the exact technical risk posed by using version X of Apache on the day the test was conducted (as an example, not to pick on Apache).
To do this, you can follow the process outlined below:
- Identify a service version – “nmap -sV -p <portnumber> <ip>” will to this in most cases.
- Look for known vulnerabilities in version – If you are using Nessus, or an alternative vulnerability scanner, they do a pretty decent job of maintaining their database of CVE issues. “IF $version == x.x.x THEN vulnerable to x,y,z” is the logic they use.
- If the service is unknown to your vulnerability scanner you will have to find your own list of CVEs if possible. Look up the vendor and product on http://www.cvedetails.com/.
- They have an export facility of sorts so you can use the output for your product to achieve what CVE-Offline does when you have an Internet connection.
- Alternatively, you are going to have to find the release notes, bug tracker, or change log for your target service. They usually track security defects using CVE references. This is not universal though.
- Format your list for your report – now that you have a list you are going to want to present them to your customer.
- If your list of vulnerabilities is around 20 you can probably show a summary of each issue to the customer.
- If the list is ENORMOUS, then are you adding much value in creating 20 pages in your report? Probably not.
- In both scenarios you can present the most significant risks with fuller write ups. Go out looking for exploit code to help quantify the exploitability of the service, and present a statistical summary.
- For example, “The service had 200 known weaknesses within the CVE database. Of those X were in the high risk range, Y were in the the medium risk range, and Z were in the low risk range. The consultant would advise special attention is paid to CVE-….-…. and CVE-….-…. which allow remote code execution, and denial of service respectively.”
Following that process should get what you want in your reports.
A word on false positives
The above process is pretty simple. There is one massive caveat that you will need to be aware of. That process is, more often than not, based on the service banner returned by your target.
If the OS uses “backporting” to supply security updates, or the admin has mucked about, then the banner number will not necessarily reflect the target’s exploitability. In this case we can get into “false positives”. A quick Google gives us the following definition:
If the target is reporting a service banner which is inaccurate when clashed against the vendor’s official release history. Then your results will be inaccurate and you have a false positive.
If we are testing in a black-box scenario we have no access to the underlying operating system by default and cannot fully confirm the banner status in many cases.
What to do? Ensure that your report includes phrases like these:
- Vulnerability based on service banner only.
- Potential false positive result.
- Impact and risk based on assumption that banner was accurate as this is the worst case scenario.
The first line of your recommendations section should definitely be “Conduct an investigation to ensure that the service is vulnerable”. Be sure that you convey these sentiments on all phone calls with your customer and they should learn to trust the other results more as they do not have them!
With that caveat dealt with by the language in your report you can be sure to prevent awkward phone calls when customers call up going “we looked into it, and it was NOT vulnerable.”
Experience tells me that even if you include these caveats you have to justify yourself sometimes. Be aware of it coming by preparing some polite reasons to give.
Using CVE-Offline
It is pretty simple to obtain CVE-Offline. Just clone the git down:
git clone https://github.com/cornerpirate/cve-offline.git
You can then use your platforms “grep” of choice to find a CVE in the “cve-summary.csv” file. For example, lets look for “CVE-2016-0142” do the following:
grep "CVE-2016-0142" cve-summary.csv CVE-2016-0142,9.3,"Video Control in Microsoft Windows Vista SP2, Windows 7 SP1, Windows 8.1, Windows RT 8.1, and Windows 10 Gold, 1511, and 1607 allows remote attackers to execute arbitrary code via a crafted web page, aka ""Microsoft Video Control Remote Code Execution Vulnerability."""
This has given you a comma separated line of output that you can now work with. The format of this line is:
<cve-id>,<cvss-risk-score>,<summary>
You can pipe that bad boy into a .csv file, open it in excel and make pretty tables that you can paste into your report. You are welcome.
Updating CVE-Offline
I update the repository once a month from the nist export feeds. You can get the raw data from here if you want:
https://nvd.nist.gov/download.cfm
Otherwise you basically need to use git to update once a month. Enter your local “cve-offline” directory and do this:
git pull
Personally I have often forgotten how the heck to update a repository I use. So there you are, it is written down!
cornerpirate.com 