How a vulnerability scanner works

Vulnerability scanning is an essential part of any information security program. Unfortunately it’s also pretty widely misunderstood. In that light, let’s take a look at what a vulnerability scanner is, and how a vulnerability scanner works.

A modern vulnerability scanner is capable of performing nearly 100,000 checks on a system. That’s good. We want thoroughness. The problem is making that scale. A corporate network might very well have 16 million IP addresses in it. Your scan won’t ever finish if it has to perform 100,000 checks on 16 million IP addresses. A good vulnerability scanner has to build some logic into its scans to let it get the job done.

Every vulnerability scanner has its own nuances, but generally speaking, this is how scanners like Nessus and Qualys work.

Port scanning

The first stage of vulnerability scanning is a simple port scan. This helps the scanner determine if a system is alive on a given IP address. It’s also possible to determine a lot more about a system just based on how it responds. Based on timing and other responses in its network traffic, it’s possible to infer if a system is running Windows, System V Unix, or BSD Unix, for example.

Typically there’s no need to check all 65,535 ports on both TCP and UDP. By checking a few hundred ports, it’s usually possible to determine if a system is live.

It’s possible to learn a lot of other things at this stage too. Most services make it possible to query them to find out what they are and what version they are running. Even when they don’t, it’s often possible to infer what the service is, even if it’s not forthcoming (or outright lying). Most software behaves predictably.

By the time you probe a few hundred ports, you have a pretty good idea what a system is, and even a few of its vulnerabilities. You’ll also have a load of potential vulnerabilities–things the system may be vulnerable to, but you can’t confirm.

Authenticated scanning

how a vulnerability scanner works
Once a vulnerability scanner authenticates to a system and logs in, it can run commands to determine what’s installed on a system, then use that data to decide what to check next.

The second stage of vulnerability scanning is the authenticated portion, if possible. At this stage, the scanner logs into the system using credentials you provided. This ideally is a highly privileged account, as it needs to query the operating system at a deep level. Many checks can’t work without administrative or root privileges or the equivalent.

The authenticated scan issues a series of commands to learn more about the system, including what software is installed on it. Some systems can give the scanner a list of installed patches as well.

All of this narrows down the list of checks to perform. There’s no need to do Mac OS X checks on a Windows machine, for example.

Another nice thing about the authentication stage is that it can ask what ports are open. So some scanners skip the port scan at the beginning, see if they can authenticate, then check what ports are open, then circle back and scan those ports. This can allow a scanner to skip certain checks that are known to cause problems.

I always recommend authenticated scans.

Verification

Some vulnerability scanners more or less stop here, but they shouldn’t. A good vulnerability scanner looks at the potential vulnerabilities it found, then looks at the affected files. If the files match a vulnerable version, the system is vulnerable, regardless of what the other checks said so far.

This stage will confirm or refute a large number of potential vulnerabilities that came up in the port scan. If it can’t decide conclusively, it marks the vulnerability as “potential” in the results.

Most vulnerability scanners won’t do a full sweep of the filesystem. If the operating system doesn’t mention Adobe Photoshop, the scanner won’t go looking for it. This saves time. But it also means that if a program has a Java Runtime Environment embedded in it, the vulnerability scanner probably won’t find it. This is a trade-off vulnerability scanners make to keep scans from being too invasive and taking too long to complete.

No scan is exactly the same

Because of the sheer number of checks a vulnerability scanner can do, and since the checks are constantly changing, next week’s scan will probably do checks this week’s scan didn’t do. This makes it impossible to determine the least privilege necessary for scanning because the checks change all the time.

Reporting

Almost any vulnerability scanner provides results in multiple formats. The most useful format for analysis is CSV, which allows you to sort and filter the data. Many vulnerability scanners allow you to provide a PDF or RTF document containing the results, which is easier for a human to read. The results tell you how many vulnerabilities the scanner found, and the details of each vulnerability.

The details normally include a CVE reference number, some indicator of severity, a vendor reference number, a resolution, and the evidence that led the scanner to decide the system was vulnerable. This gives a good system administrator the information he or she needs to patch the vulnerability to make the system safe to use.

If you found this post informative or helpful, please share it!