Problems of Vulnerability Prioritization and Detection. It’s the third part of our talk with Daniil Svetlov at his radio show “Safe Environment” recorded 29.03.2017. In this part we talk about Vulnerability Prioritization and Detection:

• Common Vulnerability Scoring System (CVSS)
• Environmental factor
• Manual and  automated vulnerability detection
• Unauthenticated and authenticated  scanning
• Why vulnerability scanners are so expensive and why the can’t detect everything

Video with manually transcribed Russian/English subtitles:

Prioritization

– Here also the question how to prioritize vulnerabilities properly. Because if you have, as you said, two Linux servers and 20 workstations running Windows, then in principle, you may not need to do prioritization. But if you have fifteen hundred servers: some of them are on perimeter, some are in your DMZ, some are in the internal network. It is still necessary, probably, to understand correctly which vulnerabilities and where should be patched in in the first place.

Yes, this is absolutely true and it’s a very good question. How to prioritize?

Common Vulnerability Scoring System

A natural way. If we look at vulnerabilities with a CVE identifier, for them in the US National Vulnerability Database we can find CVSS Base Score. It is an assessment of vulnerability criticality level.

How is it calculated?

Some person fills the questionnaire: can it be remotely exploited – no, is there public exploit – no, etc.

The result is a CVSS vector – this is a line in which you can see the main characteristics of this vulnerability and CVSS Base score is the score from 0 to 10 depending on criticality.

This is a natural way of prioritization. But sometimes this method does not give very good results.

There was OpenSSL Heartbleed vulnerability, for example. Medium level vulnerability. Although it was a massively exploited, the whole Internet was talking about it: “What should we do? It’s the end of security!”

In fact, sometimes CVSS does not give quite adequate results. Although it seems like everything is filled correctly, but a Base Score turned out small.

Therefore, many researchers say: “let’s take into account how vulnerability can be used by an attacker.” The existence of public exploit in Metasploit or other database is a much more important characteristic than the CVSS Base Score. And the most important part in the CVSS vector itself, is can this vulnerability be exploited remotely or not. Because if the vulnerability is remotely exploitable, the attacker can use it to gain primary access to the host in our network. And this is considered the most dangerous. But in general, yes, indeed. Prioritization is a complex process. See also “Vulnerability Quadrants” about vulnerability assessment.

Environmental factor

– But probably it is still necessary to consider the influence of your infrastructure in prioritization process. Because even if you have a remotely exploitable vulnerability and even if there is an exploit in Metasploit, but at the same time your server is somewhere in the internal network behind the three firewalls and only system administrators can access it. Then it’s probably easier for you to make some compensatory measures and monitor the administrators than patch this vulnerability.

Absolutely right. Even if we look at the CVSS standards, the CVSS vector consists of 3 parts:

• Basic metric
• Temporal metric
• Environmental metric

The last one, in principle, must take your environment into account. Yes, some vulnerabilities even critical can be completely unexploitable within your particular organization.

Vulnerability Detection

But aside from the prioritization issue, vulnerability detection is still a big problem.

From manual to automated

I usually say that the easiest vulnerability detection is in CentOS Linux, if all applications were installed from the standard repository. You just take the versions of the packages that were installed, take the distribution version and look in security bulletins.

The security bulletin says: all package versions that are less than this one are vulnerable.

You do reconciliations, and on an output you receive the list of CESA vulnerabilities with the full description. Very simple. You can make such a scanner yourself. Read more about it in “Vulnerability Assessment without Vulnerability Scanner“.

If you don’t want to do it yourself, you can go to vulners.com. Advertising! 🙂

There it is possible to upload the list of packages installed on the server, specify distribution version and get a list of vulnerabilities.

This can be done with graphical interface, or API.

You automatically throw on the Vulners server information, and on the output receive a list of vulnerabilities. Very convenient. Read more about it in “New Vulners.com services for Linux Security Audit and Vulnerability Alerting“.

But this works for Linux, for example. But try to do the same for Windows.

Windows, of course, has its own security update services. But there is a bunch of software that is installed like this: you downloaded exe-file and install it. To collect information on all the vulnerabilities for all kinds of software is a big problem for vulnerability scanner developers.

I turn this way to vulnerability scanners. 😉

Vulnerability scanners

It is difficult to do these operations manually. Therefore there is a class of products that deal with vulnerability detection specifically.

– Software products?

Software and hardware.

They can be delivered in the form of hardware appliances, can be in the form of virtual machines, can be in the form of software. Now they will do it as it is convenient for you. For example, Qualys Virtual Scanner Appliance.

What does this product do: using indirect or direct symptoms it says what software is installed on the network host and what vulnerabilities exist for this software.

Unauthenticated scanning

It can do this with no authentication data. It simply looks what ports are open. “Yeah, these open ports are typical for Windows operating systems” And tries to connect to open ports, looks at service banners, if they exist. And says: “Yeah, this banner is typical for this version of such software.” On its base, it looks like this software is vulnerable. It shows that yes, there are some vulnerabilities.

Authenticated scanning

But of course the best results are shown by the vulnerability scanner when you give it an account for scanning. With which it passes authentication on the host, as a legit user, performs some commands, collects some data. Then scanner analyzes it and makes a complete inventory of the system, including vulnerabilities.

This is a standard tool for security expert who analyzes vulnerabilities in the organization.

– So, in fact, all commercial vulnerability scanners can use various methods to collect information about installed software, it version and what version of the operating system has. But still the most reliable way is to collect the information about the versions and do it with some kind of administrative credentials on the host. It is not by collecting banners, not by indirect evidence, but directly from the operating system and by asking the programs what their version is.

In fact, yes, but I would say that there are a number of tests that are much better than just comparing the versions that you collected from the system.

Exploit-based vulnerability checks

These are checks that attempt to exploit the vulnerability. These checks are the best, because I can send target name to the scanner and get a root access on the server in a good case.

– At the same time, they are probably the hardest to implement in a scanner. It is necessary in fact to write an exploit for every vulnerability.

In fact, yes. And such an exploit that does not disrupt the work of the server or workstation itself. If the scanner breaks the server scanner vendor will have some big problems. The task of developing these checks is the most difficult.

Why vulnerability scanners are so expensive

And scanners are usually expensive because the cost of the scanner is tied to the number of IP addresses. Practically for all enterprise solutions the more IP addresses it will scan, the higher price will be.

– Yes, but it’s probably those enterprise solutions that draw you different dashboards, reports, right?

The same enterprise solutions begin to draw you charts, reports. Because vendors believe that this is very important. All vendors have the dashboards, let’s make dashboards too. All have built-in ticket tracking, let’s also have tracking. I’m not a big fan of these whistles, which are built into scanners. But it is believed that this should be.

Why vulnerability scanners can’t detect everything

The cost of the product is large, so the person who approved the purchase may have the idea that scanner should detect all the vulnerabilities. If you use it correctly, then there should not be any problems with Vulnerability Management.

– But in fact, the scanner only finds vulnerabilities, it does not patch them yet. The first task is to find it.

But the problem is that scanner does not detect all vulnerabilities. It is declared that they, of course, detect everything. Read any marketing report of vulnerability scanning vendor. Or ask them:

– Which systems do you support?
– We support all the systems, we can do everything!

In fact, the problem is that it is impossible to detect everything. In all VM vendor there is a department in which the manager determines which systems will be supported. Because this systems are used in 90% of our enterprise customers who pay a lot of money. We support them well. And some products will not supported well. At a minimum, there will no exploiting checks for them. Because these products are only used by home users. And home users do not buy our enterprise product.

And if you’re at the stage of formation of your company decided to use some routers, for example, from the home series. And they are still in use. And have some critical vulnerabilities. An enterprise product that you use for detection were vulnerabilities, it will not find it.

Read more about differences in Knowledge Bases of Vulnerability Scanners in “Fast comparison of Nessus and OpenVAS knowledge bases“. Case with router support is also there.

It’s just not interesting to support these routers and make checks to find vulnerabilities in them. Because a very small number of customers use it. And so you will write to the vendor Vulnerability of Scanner: “What’s the matter? Why you do not you detect it? You should!” They will only say: “Your opinion is very important for us”