This is the first of two blogs with my thoughts on Known Exploited Vulnerabilities (KEV) tracking and the challenges that come with tracking them.
Introduction
On November 03, 2021, Cybersecurity and Infrastructure Security Agency (CISA) announced a Binding Operational Directives (BOD) titled “BOD 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities“. This BOD established the CISA Known Exploited Vulnerabilities (KEV) catalog tracking vulnerabilities that the agency has confirmed, with high certainty, have been exploited against software of interest to CISA and associated stakeholders. For many, this KEV catalog was the first introduction to tracking exploited vulnerabilities in such a fashion.
Managing a list of KEV in any form can be extremely beneficial as it better directs organization on patch management. Such information is basically the short list of what to patch immediately to mitigate risk. Before CISA’s KEV catalog, several companies did the same to varying degrees, with mixed success. The reporting from these companies and the news outlets that followed, however, has been confusing at best. One of the more interesting questions in the vulnerability world is simple; “How many disclosed vulnerabilities are actually exploited in the wild?” Unfortunately, the answer is a lot more complicated.
I’ll break down what all of this means and why this is not so easy to figure out. I hope by the end of this I have brought up enough points that might not have been considered by many in our industry.
Definition of a KEV
Based on the wording, one might think a ‘Known Exploited Vulnerability’ is simple to define. That would be a vulnerability that is known to be exploited. However, there are actually different shades of gray as far as the work ‘known’ goes. On one hand, you can require rigorous proof of exploitation, typically beyond a doubt, like CISA’s KEV catalog. You can read more about their standards in my blog on the topic, based on information from CISA at VulnCon 2024. While this is a great set of standards to maintain, it can also be a disservice to stakeholders to some.
That level of evidence is great but the time it takes to investigate and include in CISA’s KEV catalog means it lags behind mass exploitation of some vulnerabilities. Organizations that rely on CISA’s KEV catalog are often at a disadvantage of others that use vulnerability intelligence that has a looser definition. That leads to another definition in so many words, “active attempted exploitation rather than active successful exploitation”. If you feel this definition is too lax then consider the following.
If a large security organization deploys hundreds of sensors around the world and sees scanning at most sensors of a particular vulnerability, with an exploit payload, it is clear that threat actors are attempting to exploit it. Their sensors or honeypots may not be configured to mimic successful exploitation, but it stands to reason that at least one host out there will get exploited as a result. While this technically doesn’t meet the bar of “known (successful) exploitation“, it does meet the bar for “known (attempted) exploitation“.
While you may be prone to argue the difference, and you would be correct to a degree, companies that rely on this definition and the associated vulnerability intelligence are getting faster warnings and are able to triage more intelligently. It’s a small trade-off for a large gain for these security teams to be able to focus on what they know to be a bigger threat. If you still have doubts, consider that the data used to seed the Exploit Prediction Scoring System (EPSS) includes exploitation from both definitions.
Whatever vulnerability intelligence you use, make sure you fully understand their definition of a KEV catalog. I strongly advise you to go with the latter of the examples above and triage accordingly to better reduce risk in a more timely fashion.
Does Age Matter?
Some may think that vulnerability age matters, you are only after the latest and greatest vulnerabilities that are being exploited. However, that is not a good approach and not the best way to manage risk when it comes to such vulnerabilities. Even if a vulnerability was disclosed ten years ago, it may not see active exploitation until years later. In other cases it may see exploitation shortly after the disclosure, but also continue to see it years or decades later.
If you need a solid example of that, one that still surprises and disappoints me, is CVE-2017-11882. “Microsoft Office Equation Editor Font Record Name Handling Stack Buffer Overflow” as we title it has been exploited for a long time. What’s more baffling is that it is still successfully exploited almost seven years later. Just do a Google news search and refine the results to show you the most recent. The sad part is, if you are reading this a year after I publish this blog, you will likely still see the same thing.
Ultimately, age does not matter. You want as complete of a data set as possible irrespective of when a vulnerability was disclosed, when it was first seen in the wild, or when it was last seen. Exploitation of a given issue may slow down or stop entirely for some length of time; it could go dormant for years, then pick back up. Threat actor whim, technical ability, or finding a bypass that allows renewed exploitation may all contribute to this.
Challenges in Mapping
With so many security companies, government agencies around the world, and a wide array of intrusion detection (IDS) / prevention software (IPS), along with a theoretically simple mapping to e.g. Common Vulnerability Enumeration (CVE) IDs, you might expect this to be fairly trivial. In reality, it is surprisingly difficult to answer with any degree of certainty. There are many facets to mapping that make it challenging to say the least.
Ask your favorite IDS pro about the best IDS for mapping to CVE, and I suspect none will have an easy answer. I asked one and he basically said that none really do it well anymore; instead, they focus more on general patterns and less about mapping to a specific vulnerability. This is understandable as the job is to detect attacks, not specifically the mapped CVE, or prevent an intrusion attempt regardless of what it might map to. These days, with a high volume of script kiddies, a medium volume of decent criminals, and a substantial amount of botnets and skilled threat actors, the amount of exploit attempts across the Internet is ridiculous.
When thinking about the barrage of exploit attempts against web servers, consider The Shadowserver Foundation and their efforts to map “Web CVEs”. They have a slick dashboard that gives a nice visual map that lets you select a variety of criteria for displaying HTTP-based attacks that map to CVEs (mostly). I say mostly, because they also occasionally map to vulnerabilities with an Exploit-DB (EDB) or Chinese National Vulnerability Database (CNVD) ID that do not have a CVE. I have recently been in contact with them regarding a few questions about their data as a result of them mapping to CVE, which is historically inconsistent on abstraction.
What is “abstraction”? From a previous blog I wrote:
Abstraction bias is a term that we crafted to explain the process that VDBs use to assign identifiers to vulnerabilities. Depending on the purpose and stated goal of the VDB, the same 10 vulnerabilities may be given a single identifier by one database, and 10 identifiers by a different one. This level of abstraction is an absolutely critical factor when analyzing the data to generate vulnerability statistics. This is also the most prevalent source of problems for analysis, as researchers rarely understand the concept of abstraction, why it varies, and how to overcome it as an obstacle in generating meaningful statistics. Researchers will use whichever abstraction is most appropriate or convenient for them; after all, there are many different consumers for a researcher advisory, not just VDBs. Abstraction bias is also frequently seen in vendors, and occasionally researchers in the way they disclose one vulnerability multiple times, as it affects different software that bundles additional vendor’s software in it.
When I say that CVE has not been consistent, I mean almost over two decades there are times where three vulnerabilities will get three IDs, and in a very similar disclosure they might be lumped into one ID. So as a side note, all you “data scientists” doing fancy graphs and analysis of CVE data, your vulnerability numbers will always be wrong (fixing that is an entire blog series). Anyway, when a group like Shadowserver or GreyNoise detects an exploit attempt and references a CVE, it isn’t always clean. That means…
Tracking KEV is Tricky
Here are some real-world examples of what I outlined above, thanks to Shadowserver for being transparent and willing to answer questions. That kind of cooperation is great to see when it comes to KEV data and invaluable in better helping stakeholders. The following are a few cases where initial uncertainty of an exploited vulnerability led to clarity, but highlights why granular details matter.
Looking at the Shadowserver dashboard map, on June 25, 2022 it shows that EDB-40500 was observed being exploited. Unfortunately, that disclosure maps to 12 distinct vulnerabilities. Four of them are remote command execution and two are authentication bypasses. These are all viable to see in the wild so it isn’t clear which one, or more, of those were observed. After an email to their team and a quick response, they confirmed it was VulnDB 46233 aka “AVTECH Multiple Products /cgi-bin/nobody/Search.cgi username Parameter Remote Command Execution“.
The next one is interesting, and telling, for a couple reasons. First, “UNASSIGNED-2020-Samsung-WLAN-AP-RCE-01” obviously doesn’t match to a vulnerability database like CVE, CNVD, Exploit-DB, etc. The fact that there isn’t a CVE ID for this vulnerability, that is actively being exploited, is yet another reminder of the failure of the CVE ecosystem. Second, the possible matches I figured it might be are CNVD-2021-30050 or CNVD-2021-18482. Turns out I was wrong and it was actually from a disclosure by Omri Inbar. The world of vulnerability disclosure is vast and no matter what you hear from a VDB, we simply cannot monitor absolutely everything reliably. There are always new disclosure points tomorrow.
The third example is something that is likely a common issue in the IDS/IPS world. Looking at the Shadowserver dashboard again, we focus on CVE-2022-29007 in which the affected script “index.php” and the parameters “username” and “password“. These appear in hundreds of software packages and the payloads are often identical. Shadowserver confirmed that there are many packages with this endpoint and parameters, but confirmed this specific request was for “/dfsms/index.php” which narrowed it down nicely. This is another case of a CVE description not including an important piece of information.
Last, we have CVE-2021-35395 which is one CVE ID that maps to four buffer overflows and two command injection issues. But it gets worse, as the vulnerabilities are in an SDK used across multiple vendors. The ‘formSysCmd’ vector can be attributed to at least seven disclosures over eight years. So which one is being exploited? This is a reminder that abstraction, the way a VDB splits vulnerabilities and assigns IDs, can be key in tracking such things.
Stay tuned for part two!
Leave a Reply