Our Reports Clickbait? No. Click Here To Find Out Why…

Last week, we published our 2018 mid-year report that included an overview of the vulnerabilities that we have tracked and included in VulnDB. We highlighted a key takeaway from the report in the title: “Over 3,000 [vulnerabilities] You May Not Know About”. This statement is based on our aggregation of over three thousand vulnerabilities in the first half of 2018 that were not included in MITRE’s Common Vulnerabilities and Exposures (CVE) database, mirrored and enhanced a bit by the National Institute of Standards and Technology (NIST) National Vulnerability Database (NVD).

When we talk about our vulnerability database and service, VulnDB, in any context (e.g. sales or otherwise), there are two questions we typically get regarding the vulnerabilities that don’t appear in CVE/NVD:

  1. Do those vulnerabilities affect any major vendors?
  2. Are those vulnerabilities serious? (e.g. above a CVSSv2 ~ 5.0 score)

The answer to both questions is a resounding yes. These vulnerabilities cover the same wide range of vendors and products as the vulnerabilities found in CVE/NVD. In our case, we just have a whole lot more of them. The vulnerabilities range from low-risk path disclosures (CVSSv2 5.0) to remote code execution issues (CVSSv2 10.0). More to the point, from the report:

“An important and compelling statistic is that of the 3,279 vulnerabilities not reported by CVE/NVD, 44.2% have CVSSv2 scores between 7.0 and 10 (High and Critical severity). While other criteria than just CVSS scores are important to consider when managing and prioritizing vulnerabilities, it is highly problematic if an organization is not aware of higher severity vulnerabilities that pose a risk to their assets.” said Carsten Eiram, Chief Research Officer for Risk Based Security.

Shortly after the report was released, Twitter user lo_security posed an additional question:

We welcome all questions and challenges of our reports, but before we answer this question and provide proof of critical vulnerabilities without CVEs that are actively exploited, we’d like to first point out that we believe the premise of this question to be flawed. Without additional context, we can only presume that the tweet is suggesting that only vulnerabilities with a CVSS score between 9.0 and 10.0 AND that are also being exploited in the wild are worth assigning CVEs for or prioritizing for remediation. Hopefully, no organization with a reasonable security team responsible for the vulnerability management has such a view.

Our goal with our reports is to provide as complete a summary of the vulnerability intelligence landscape as possible. We strive to highlight the risks to organizations that are using sub-par vulnerability intelligence, and our phrasing is intentional to encourage organizations to research the foundation upon which their security strategy is based. With some disclaimers behind us, we are happy to address this question because there are missing vulnerabilities in CVE/NVD being exploited in the wild.

We were challenged to name only one, but could actually name at least six vulnerabilities without a CVE that were disclosed/discovered between January 1, 2018 and June 30, 2018 (the period covered by our 2018 mid-year report), have a CVSSv2 score of 9.3 or higher, and that were exploited in the wild, leading to their discovery by security companies and researchers.

Before going into more detail, it is important to understand the nuances and pitfalls of this question. First, a majority of security products are based on CVE/NVD. That means that the vulnerability intelligence used to create signatures are typically based only on those vulnerabilities, not the missing ones we have aggregated in VulnDB. As such, Vulnerability Scanners and Intrusion Detection/Prevention Systems (IDS/IPS) won’t have signatures for these vulnerabilities. In some cases more broad signatures may detect these vulnerabilities (e.g. generic XSS, SQLi, or payloads), in other cases they do not. So while that number may seem low, the circumstances that lead to such discoveries work against the question being asked.

Now, one of those vulnerabilities not only allowed remote code execution, but it garnered some attention. The Qihoo 360 Netlab team discovered that TheMoon botnet was using a new vulnerability to exploit GPON-based routers including some from D-Link and DASAN. So an active, known botnet is exploiting two routers from different vendors to remotely execute code and gain control of the devices, and almost three months later the vulnerability still doesn’t have a CVE ID.

As history shows, these issues highlighted for 2018 are not isolated cases. If we look back we know that on May 11, 2016, Threatpost reported that “Attackers [were] Targeting Critical SAP Flaw Since 2013”. From the article:

The attacks were carried out between 2013 and are ongoing against large organizations owned by corporations in the United States, United Kingdom, Germany, China, India, Japan, and South Korea, spanning 15 critical industries, researchers at Onapsis said today.

The vulnerability used in this attack was added to VulnDB early in 2013, giving Risk Based Security’s customers warning well before the exploitation started. Meanwhile, CVE issued an ID to cover this issue on May 13, 2016, over three years later! Even worse? CVE claimed at the time of assignment, and for a decade before, that they covered SAP vulnerabilities. Another example from 2016 can be found in a remote code execution exploit in Ubiquiti devices that was being exploited in the wild. That vulnerability still doesn’t have a CVE assignment two years later.

In summary, the vulnerabilities we aggregate that are not included in CVE/NVD are just as real a threat as many other vulnerabilities disclosed. In this blog post, we haven’t even discussed all the other critical vulnerabilities with exploits available but no CVEs assigned, where there are no immediate reports of active exploitation (131 vulnerabilities). Organizations need to operate based on the best vulnerability intelligence they can find, use it to better gauge risk, and more accurately prioritize mitigation strategies. The presence of a CVE ID for a given vulnerability has no bearing on if it is a critical issue that an organization needs to address or if it is being actively exploited or not.