< Previous | Contents | Next >
11.2.1. Vulnerability Assessment
A vulnerability is considered a weakness that could be used in some manner to compromise the confidentiality, integrity, or availability of an information system. In a vulnerability assessment, your objective is to create a simple inventory of discovered vulnerabilities within the target envi- ronment. This concept of a target environment is extremely important. You must be sure to stay within the scope of your client’s target network and required objectives. Creeping outside the scope of an assessment can cause an interruption of service, a breach of trust with your client, or legal action against you and your employer.
Due to its relative simplicity, a vulnerability test is often completed in more mature environments on a regular basis as part of demonstrating their due diligence. In most cases, an automated tool, such as the ones in the Vulnerability Analysis7 and Web Applications8 categories of the Kali Tools site and Kali desktop Applications menu, is used to discover live systems in a target environment, identify listening services, and enumerate them to discover as much information as possible such as the server software, version, platform, and so on.
This information is then checked for known signatures of potential issues or vulnerabilities. These signatures are made up of data point combinations that are intended to represent known issues. Multiple data points are used, because the more data points you use, the more accurate the iden- tification. A very large number of potential data points exist, including but not limited to:
• Operating System Version: It is not uncommon for software to be vulnerable on one op- erating system version but not on another. Because of this, the scanner will attempt to determine, as accurately as possible, what operating system version is hosting the targeted application.
• Patch Level: Many times, patches for an operating system will be released that do not in- crease the version information, but still change the way a vulnerability will respond, or even eliminate the vulnerability entirely.
• Processor Architecture: Many software applications are available for multiple processor architectures such as Intel x86, Intel x64, multiple versions of ARM, UltraSPARC, and so on.
5https://en.wikipedia.org/wiki/Executable_space_protection#Windows 6https://en.wikipedia.org/wiki/Address_space_layout_randomization 7http://tools.kali.org/category/vulnerability-analysis 8http://tools.kali.org/category/web-applications
In some cases, a vulnerability will only exist on a specific architecture, so knowing this bit of information can be critical for an accurate signature.
• Software Version: The version of the targeted software is one of the basic items that needs to be captured to identify a vulnerability.
These, and many other data points, will be used to make up a signature as part of a vulnerability scan. As expected, the more data points that match, the more accurate the signature will be. When dealing with signature matches, you can have a few different potential results:
• True Positive: The signature is matched and it captures a true vulnerability. These results are the ones you will need to follow up on and correct, as these are the items that malicious individuals can take advantage of to hurt your organization (or your client’s).
• False Positive: The signature is matched; however the detected issue is not a true vulnera- bility. In an assessment, these are often considered noise and can be quite frustrating. You never want to dismiss a true positive as a false positive without more extensive validation.
• True Negative: The signature is not matched and there is no vulnerability. This is the ideal scenario, verifying that a vulnerability does not exist on a target.
• False Negative: The signature is not matched but there is an existing vulnerability. As bad as a false positive is, a false negative is much worse. In this case, a problem exists but the scanner did not detect it, so you have no indication of its existence.
As you can imagine, the accuracy of the signatures is extremely important for accurate results. The more data that are provided, the greater the chance there is to have accurate results from an automated signature-based scan, which is why authenticated scans are often so popular.
With an authenticated scan, the scanning software will use provided credentials to authenticate to the target. This provides a deeper level of visibility into a target than would otherwise be possi- ble. For instance, on a normal scan you may only detect information about the system that can be derived from listening services and the functionality they provide. This can be quite a bit of infor- mation sometimes but it can’t compete with the level and depth of data that will be obtained if you authenticate to the system and comprehensively review all installed software, applied patches, running processes, and so on. This breadth of data is useful for detecting vulnerabilities that oth- erwise may not have been discovered.
A well-conducted vulnerability assessment presents a snapshot of potential problems in an organi- zation and provides metrics to measure change over time. This is a fairly lightweight assessment, but even still, many organizations will regularly perform automated vulnerability scans in off- hours to avoid potential problems during the day when service availability and bandwidth are most critical.
As previously mentioned, a vulnerability scan will have to check many different data points in order to get an accurate result. All of these different checks can create load on the target system as well as consume bandwidth. Unfortunately, it is difficult to know exactly how many resources will be consumed on the target as it depends on the number of open services and the types of
checks that would be associated with those services. This is the cost of doing a scan; it is going to occupy system resources. Having a general idea of the resources that will be consumed and how much load the target system can take is important when running these tools.
Scanning Threads Most vulnerability scanners include an option to set threads per scan, which equates to the number of concurrent checks that occur at one time. Increasing this number will have a direct impact on the load on the assessment platform as well as the net- works and targets you are interacting with. This is important to keep in mind as you use these scanners. It is tempting to increase the threads in order to complete scans faster but remember the substantial load increase associated with doing so.
Scanning Threads Most vulnerability scanners include an option to set threads per scan, which equates to the number of concurrent checks that occur at one time. Increasing this number will have a direct impact on the load on the assessment platform as well as the net- works and targets you are interacting with. This is important to keep in mind as you use these scanners. It is tempting to increase the threads in order to complete scans faster but remember the substantial load increase associated with doing so.
When a vulnerability scan is finished, the discovered issues are typically linked back to industry standard identifiers such as CVE number9, EDB-ID10, and vendor advisories. This information, along with the vulnerabilities CVSS score11, is used to determine a risk rating. Along with false negatives (and false positives), these arbitrary risk ratings are common issues that need to be considered when analyzing the scan results.
Since automated tools use a database of signatures to detect vulnerabilities, any slight deviation from a known signature can alter the result and likewise the validity of the perceived vulnerabil- ity. A false positive incorrectly flags a vulnerability that does not exist, while a false negative is effectively blind to a vulnerability and does not report it. Because of this, a scanner is often said to only be as good as its signature rule base. For this reason, many vendors provide multiple sig- nature sets: one that might be free to home users and another fairly expensive set that is more comprehensive, which is generally sold to corporate customers.
The other issue that is often encountered with vulnerability scans is the validity of the suggested risk ratings. These risk ratings are defined on a generic basis, considering many different factors such as privilege level, type of software, and pre- or post-authentication. Depending on your environment, these ratings may or may not be applicable so they should not be accepted blindly. Only those well-versed in the systems and the vulnerabilities can properly validate risk ratings.
While there is no universally defined agreement on risk ratings, NIST Special publication 800-3012 is recommended as a baseline for evaluation of risk ratings and their accuracy in your environ- ment. NIST SP 800-30 defines the true risk of a discovered vulnerability as a combination of the likelihood of occurrence and the potential impact.
9https://cve.mitre.org 10https://www.exploit-db.com/about/ 11https://www.first.org/cvss
12http://csrc.nist.gov/publications/PubsSPs.html#800-30