What’s a known vulnerability?

This post originally appeared on CSO Online, on December 15th, 2017.

We hear a lot about the importance of dealing with known vulnerabilities. Most annual security reports point out that known vulnerabilities account for the vast majority of successful exploits, and there’s no shortage of brand name vulnerabilities — ranging from Heartbleed to ImageTragick, to continue reminding us of their severity. So, if they matter so much, let’s take a moment to define what a known vulnerability is.

Answer 1: A vulnerability with a CVE ID

A term used practically synonymously with “known vulnerability” is CVE, short for MITRE’s “Common Vulnerabilities and Exposures.” When a new vulnerability is discovered, a CVE Numbering Authority (CNA) can assign it a CVE number, which is then used to identify this vulnerability across databases and tools.

It’s worth noting CVE is not a database, but rather an ID. The National Vulnerability Database (NVD) is the official home for CVE related information. When a CVE is added to NVD, it typically arrives with some amount of information, such as a short description and a definition of the products affected by the vulnerability in the form of a CPE (Common Platform Enumeration). The information in NVD varies greatly in quality, depending on the contributing source.

Except for CVEs that are reserved ahead of a future disclosure, it’s safe to say a vulnerability that has a CVE number is a known vulnerability. However, a large number of vulnerabilities have a CVE number but never make it to NVD, making it hard to truly understand them. In addition, many known vulnerabilities don’t have a CVE at all.

Answer 2: A vulnerability disclosed on the internet

Fairly often, vulnerabilities are discovered, shared and (hopefully) fixed without anyone filing a CVE for them. This is especially common in open source projects, where practically everything is done in public. It’s quite common for users to unwittingly disclose a vulnerability by opening an issue on a GitHub project, just like they report other bugs, not considering the fact they are drawing attention to an unfixed security flaw.

Even if issues are reported privately and responsibly, the vulnerability fix will inevitably be open source, at which point the vulnerability is often mentioned in the release notes, an issue or alongside the code change details. These details are added intentionally, as doing so is the only way to inform the users of the project the security risk (and fix) exists. Some project maintainers obtain a CVE for such vulnerabilities, but in practice that is rarely the case, due to lack of awareness or the effort involved.

These vulnerabilities are also known, and could be considered worse than those with a CVE. A consumer of a project can inspect a project for them, but that would be time consuming and hard to do at scale. On the flip side, an attacker can scrutinize popular library projects and find those issues fairly easily, as they only need to look at the popular projects to get wide reach.These are referred to these as unsurfaced vulnerabilities. Surfacing them into a database gets us to the next category of known vulnerabilities.

Answer 3: A vulnerability stored in open databases

While NVD is the most official vulnerability database, other databases do exist. VictimsDB, RedHat and Openwall are all examples of public vulnerability databases, accessible for all to browse. Many vulnerabilities on such DBs do not have a CVE, for instance the unsurfaced vulnerabilities mentioned before, or are published on those databases before a CVE is assigned.

A vulnerability in an open database is nearly as known as those with a CVE. It’s stored in a public location that is available to defenders and attackers both, and informs both about the risk involved. The only difference between NVD and these databases is the filtering process to get in, which differs from DB to DB.

Answer 4: A vulnerability captured in closed vulnerability databases

Not all vulnerability databases are open to browse. A good number of businesses build up and maintain a database of vulnerabilities, but keep this DB behind closed curtains. Customers can purchase access to the list of vulnerabilities, allowing them to triage the vulnerabilities and attempt to mitigate those that affect them the most.

Closed vulnerability databases are a useful way to uncover vulnerabilities you’ll have a hard time finding yourself, and protect yourself in case attackers find them as well. However, I wouldn’t call these vulnerabilities known. Unless the DB vendor sold this database to the attackers as well (which I doubt any of them do), the attacker is just as likely to find another vulnerability in your system as to find the one you just purchased.

Answer 5: A vulnerability shared in the dark web

Not unlike the legitimate vulnerability DB business, the dark web runs its own repositories of vulnerabilities, and sell those on the black market. Since the financial ROI is quite different for attackers, these vulnerabilities may cost millions for a single one, or given away for free or cheap.

These vulnerabilities are definitely not known vulnerabilities. In fact, they’re typically called “0-day” vulnerabilities, as attackers are aware of them before they become known (zero days after disclosure). At times, these vulnerabilities may be posted publicly, at which point I would deem them unsurfaced vulnerabilities per answer 2.

Zero-day vulnerabilities definitely matter, but the likelihood of attackers using them (before they’re made publicly known) is far lower than truly known vulnerabilities.

Summary

A vulnerability is a vulnerability, whether known or not. The key difference between the two is the likelihood of an attacker to be aware of this vulnerability, and thus try to exploit it. Therefore, the better known the vulnerability is, the more urgent its fix should be.

It’s recommended to prioritize the first three types of vulnerabilities, perhaps, in order. Once you have those under control, work towards fixing those further down the list.