Vulnerability Scanning – CompTIA Security+ SY0-501 – 1.5

A vulnerability scan can tell you a lot about potential threats. In this video, you’ll learn about different vulnerability scan types, the results of a vulnerability scan, and how to deal with false positives.

<< Previous Video: Penetration Testing Next: Vulnerability Types >>


Unlike a penetration test, a vulnerability scan usually is not very invasive. It’s simply gathering information about what can be found without actually performing any exploits on a system. We might perform a port scan to see what services might be open on a particular server and find out what version of those services may be running. All of this can be done without logging in or performing any type of exploit on those systems.

You can perform vulnerability scans from outside the network, but you can also perform your own vulnerability scans from inside the network. It’s usually a good idea to do both so that if somebody did gain access to the inside, you’d know exactly what they would see. A Vulnerability scan will gather a large amount of information. Some of the details in the vulnerability scan will be informational and low priority, and others may be high priority and critical. You want to gather as much as possible, and then you can sort it out after the vulnerability scan is complete.

The vulnerability scanners that we use these days are very powerful. They use a lot of different techniques to try to find out information about a server or an application. One method of scanning is a non-intrusive scan, where we’re simply gathering information about what we’re seeing on the network. This might be simply a packet capture process, and then looking through those packets to determine what conversation might be going on.

The scan may be a little more intrusive, where we’re checking a vulnerability to see if it exists without actually taking advantage of that vulnerability. This might also be a non-credentialed scan, where you don’t have any access to that server, you don’t have a username and password that you could use to authenticate. The scanner is going to act just like everyone else who’s sitting on the outside and trying to get into that system without any specific credentials.

Some scanners will act as a credentialed attacker. So you provide the scanner with a legitimate username and password, it uses that to get into the system as a normal user, and then tries to find ways to get around the existing security. I’m running a vulnerability scanner on my system called nikto. It’s designed to scan web servers and find out information about what might be running on those web servers.

I’ve, also got a web server running as a virtual machine in my network that is designed to be vulnerable. The first scan I’m going to do, though, is going to be against my network-attached storage device, which I think is relatively secure, but let’s find out. We’re going to run this nikto scan, and it will tell us that it does have a root page that redirects. That’s pretty normal.

There’s no CGI directories found, and that was it. There were zero errors, and only that single item reported. Now let’s try to run this same vulnerability scanner against a known vulnerable web server. I’ve got it running on my internal network, and we’ll start the scanner.

You can see immediately, we have a page of information about vulnerabilities that might exist. Most of these are relatively low priority– there’s different applications that appear to be outdated– but some of these might allow an attacker into my system. For example, there is a default script that’s executable that gives server environment variables. There are different applications running that provide access to my SQL database. These are clues that the bad guys can use to find vulnerabilities and find a way into your systems.

As you can see, the scanner appears to look for almost anything. But in reality, it’s going through a well-defined list of known vulnerabilities based on what it’s seeing in that system. The vulnerabilities that we just saw can all be cross-referenced online. Each one of them has an error message or vulnerability number, and you can go to the National Vulnerability Database at nvd.nist.gov, and you can of course, if this is a Windows operating system, look at the Microsoft Security bulletins on the Microsoft web site.

The vulnerability scan is going to provide you as much information as it can, but it’s not going to try to perform an exploit. That would be the process that occurs next if you decide to perform a penetration test. But the scanner will give you some clues and help you understand if certain parts of your network are more vulnerable than others.

The vulnerability scan results will give you information on where you can start to make your systems more secure. It may tell you that you’re not running a firewall, or that your anti-virus signatures are outdated. There might be a notice of open shares or guest access into parts of your operating system. And it might tell you about real vulnerabilities that are well-known with that operating system so that you can go and patch those systems.

Since the vulnerability scan is not performing an exploit, it’s really making a best guess on what might be vulnerable in your systems. It’s up to you to really determine if the information from a vulnerability scan is accurate or not. Very often, you’ll get false positives, where the vulnerability scanner will tell you that there is indeed a vulnerability on your system, but the reality is that the vulnerability is not one that could be exploited.

This might be a little different than something that’s a low severity vulnerability. The vulnerability scanner might give you an informational vulnerability or a low priority vulnerability, but those are still valid. So you need to make sure that you accept those as being real, and not something that might be a false positive. On the other side of the coin, we have a false negative, which means there was a vulnerability on that system but the vulnerability scanner didn’t see it and didn’t notify you that the vulnerability was there. That’s why it’s important to always have the latest version of your vulnerability scanner, and make sure you’re running with the latest signatures. And if you’re working with a vulnerability scanner that’s well-known, you might want to work with the development team or the company that makes that vulnerability scanner. They may be able to customize these signatures to work best in your environment.