A vulnerability assessment is an important element in understanding a company’s threat profile. When performing a threat vulnerability assessment, it should include more than just running a scan, printing a pretty report and sending it out to a client, management, or administrator. It must also be about confidence and accuracy. What makes you confident in the report you send to a client, your management, or administrator? What makes YOUR report more accurate than others? Validation. What is validation? Validation is testing a vulnerability that has been found. Depending on how far you dive into validation, it can contain many elements of a penetration test. What makes validation most important is identification of false positives. Every vulnerability scanner, no matter how many bells and whistles it has, will produce false positives. There is no scanner on the market that can find every vulnerability and not produce false positives.
Let’s say you are an intern or a co-op and your task is to run a vulnerability assessment on a specific range of IP addresses. The report shows a vulnerability where you can get to management interfaces on a Cisco device. You then validate this interesting vulnerability by using a great tool called telnet. Not only did you just validate a “Management Interfaces Vulnerability,” but you also just found a different vulnerability of using clear-text protocols. Now that you are being asked for a username and password on this Cisco device you enter “admin” for the username, and “admin” for the password. Now you see a place to enter commands. Congratulations, you just found and validated a “Default Passwords Vulnerability”. Let’s also say that during this assessment you find other vulnerabilities that deal with a vulnerable version of SSH and readable SNMP information, and through validation you were able to confirm these vulnerabilities exist. Because this was done, you were able to find out that someone put a Cisco device on the network, and somehow forgot to securely configure it. Knowing that validation was done on these systems, more confidence and accuracy can be put in the report.When performing threat vulnerability assessments I see a lot of “SSL Certificate – Subject Common Name Does Not Match Server FQDN” vulnerabilities. A majority of the time I come across this vulnerability it’s a false positive because of the common name (CN) of the certificate. There are many companies that use the wildcard (*) in the CN field, for example, *.myhappydomainname.com. It isn’t necessarily bad that companies use the wildcard, but because the scanner is unable to associate the wildcard with the FQDN of the system being scanned, this is flagged as a vulnerability. To exploit this vulnerability, an attacker could use a man-in-the-middle attack along with some DNS cache poisoning and then lure a client to another server and steal the encryption communication.