Vulnerability Scanning – Vulnerability discovery is an integral part of any security assessment. While we prefer manual, specialized tasks that leverage our knowledge and experience during a security audit, automated vulnerability scanners are nonetheless invaluable when used in proper context. In this module, we will provide an overview of automated vulnerability scanning, discuss its various considerations, and focus on both Nessus and Nmap as indispensable tools.
How Vulnerability Scanners Work
Vulnerability scanner implementations vary, but generally follow a standard workflow. Most automated scanners will:
- Detect if a target is up and running.
- Conduct a full or partial port scan, depending on the configuration.
- Identify the operating system using common fingerprinting techniques.
- Attempt to identify running services with common techniques such as banner grabbing, service behavior identification, or file discovery.
- Execute a signature-matching process to discover vulnerabilities.
Notice that this process basically mirrors what we do during a manual assessment. As penetration testers, we may mentally execute some type of signature-matching process. For example, we may remember that a particular version of an application we spot in the field is vulnerable to a remote exploit. An automated scanner, however, performs this step with the assistance of unique vulnerability signatures.
As a part of this signature-matching process, many scanners use banner grabbing, a simple technique where text strings generated during an initial interaction with an application are obtained and analyzed. Some applications generate very specific banners, such as OpenSSH, which may return “SSH-2.0- penSSH_7.9p1 Debian-10”, allowing us to precisely pinpoint the application version, while others, such as Apache Tomcat versions 4.1.x to 8.0.x, return a generic HTTP header of “Apache-Coyote/1.1”. Naturally, more specific headers and banners make it easier for the scanner to determine the application version and by extension, to accurately detect potential vulnerabilities.
Some vulnerability scanners can be configured to exploit a vulnerability upon detection. This can reduce the likelihood of a false positive but also increase the risk of crashing the service. Always check scanner options carefully.
Most automated scanners inspect a wide variety of other target information during the signature matching process. Nevertheless, even a strong signature match does not guarantee the presence of a vulnerability. This means automated scanners can generate quite a few false positives 220 and by contrast, false negatives, 221 in which a vulnerability is overlooked because of a signature mismatch. False positives and negatives can also occur because of backporting, 222 in which package maintainers “roll back” software security patches to older versions. Backporting may result in the scanner flagging software as a vulnerable version when the vulnerability has actually been repaired.
Because of this, we should carefully inspect and manually review vulnerability scan results whenever possible. Given the ever-changing and complex technology landscape, vulnerabilities can show up in unexpected places. As good as some of the best commercially available scanners are, none are perfect. However, by updating the signature database before every engagement, we ensure that our scanner has the best chance of discovering the latest vulnerabilities.
This signature-matching process is quite efficient, and is much faster than a fully manual review, making automated vulnerability scanners an excellent choice as a first-pass during an assessment and a perfect companion to a manual review.
Taking time to understand the inner-workings of any automated tool we plan to use in the field is an extremely valuable exercise. This will not only assist us in configuring the tool and digesting the results properly, but will help us understand the limitations that must be overcome with manually-applied
Manual vs. Automated Scanning
We should combine manual and automated scan techniques during an assessment, but the proper balance becomes more evident with experience.
Let’s discuss the primary advantages and disadvantages of manual and automated scanning in order to help strike the proper balance during an assessment.
A manual review of a remote target network will inevitably be very resource intensive and time consuming. Since this approach relies heavily on human interaction and repetitive tasks, it is also prone to errors in which vulnerabilities may be overlooked. Nevertheless, red-teaming 223 in particular, requires surgical precision and a minimal network footprint in order to remain undetected as long as possible. Using an automated scanner in these types of situations would not be the best approach. Furthermore, manual analysis allows for discovery of complex and logical vulnerabilities that are rather difficult to discover using any type of automated scanner.
However, automated vulnerability scanners are invaluable when working on large engagements under the typical time constraints associated with traditional security assessments. Whether using a general scanner across the entire target network or against a single dedicated host, we can establish a baseline in a much shorter period of time. These baselines allow us to validate easily-detected vulnerabilities, or at the very least help us understand the general security posture of the target.
While invaluable, vulnerability scanning can have disadvantages. Scan configurations can be extensive and complicated with defaults that could harm the target. For example, many scanners can and will attempt to brute force weak passwords. During an engagement, brute-force techniques should be tightly regulated as they can lead to account lock-outs, which can incursignificant downtime for the client. It is important to understand how a vulnerability scanner works and what its capabilities are before executing a scan.
Remember, when using an automated vulnerability scanner, our job as a penetration tester is to provide value above and beyond the output of any tool.
Internet Scanning vs Internal Scanning
Vulnerability scanners can easily scan Internet-connected targets as well as those connected to a local network. However, our scan results may be incomplete or inaccurate if we treat these targets as equals. Our network placement in relation to the target can affect our speed threshold, access rights, likelihood of traffic interference, and target visibility.
The speed of our connection to the target network dictates not only the raw bandwidth available to our scanner, but other factors such as the number of hops to the individual hosts. This means that we can conduct more intrusive and comprehensive scans more quickly against locally-connected hosts. However, we must be mindful of our traffic at all times, realizing that older equipment may be adversely affected by heavy scans. For optimal results, consider the guidelines established in the port scanning discussion in previous modules.
To achieve better scan results, consider throttling scan speeds and timeout values at first. Once you are comfortable with the quality of the results, you can start increasing the speed incrementally until a good balance is achieved.
Our positioning on the network can also affect our access rights and likelihood of traffic interference when communicating with our targets. Firewalls or Intrusion Prevention Systems (IPS), for example, could block our access to hosts or ports and may drop our traffic while generating security alerts. These devices limit our capabilities and subsequently mask vulnerabilities on targets behind them, which will negatively affect the end product we provide to our client.
Finally, our network positioning can affect target visibility. For example, a typical vulnerability scanner will attempt to discover targets with a ping sweep or ARP scan. However, Internet connected targets would not be able to receive ARP traffic from external subnets and may block ICMP (ping) requests, meaning the scanner could miss the targets entirely if it has been configured to rely solely on these discovery options.
We need to take the time to thoroughly understand the target network, the exact network location we will be operating from, and the target access our network positioning provides. And as we always say, it is important to know your tools and how they work behind the scenes.
If You Like This Blog Please Comment Down
For More Hacking Content Click Here