[This was a first draft of an article to be published on the Flashpoint Threat Intel blog. Ultimately, parts of it were adopted for a different blog but the original remains considerably different. Curtis Kang contributed significantly to the finished blog below.]
Zero-days (0-days and other variations) are exploitable vulnerabilities that the general public is unaware of—often being known by only one or few people. But for many years, the term zero-day vulnerability has been overused by news outlets and some security providers—mythologizing it to become the ‘big bad wolf’ of the security world that can render an organization’s systems useless with one click of a mouse. While that is technically true, there is a lot more to it. Even the term itself has become convoluted, with different definitions depending on who you ask.
“Zero-days” are actually quite common
There are a substantial number of blogs and news articles on the topic of zero-day vulnerabilities, and we’ve written our fair share, including analysis of a RAND report [ref], their use in an attack on Kaseya [ref], and comparing zero-days to regular vulnerabilities. [ref] It’s a compelling topic because zero-days are used in high-profile breaches and can be dangerous to every organization. However, not all zero-days pose the same risk.
Nearly all vulnerabilities are zero-days at some point. At the heart of it, zero-days are just vulnerabilities that the vendor is unaware of, and therefore, can be quite common. Many issues don’t get reported to vendors and they are often missed by CVE/NVD, instead being found on other mediums like illicit forums or mainstream sources like GitHub. As such, having a quality vulnerability feed is critical. The best way to protect yourself against the majority of issues is to monitor as many vulnerability sources as possible, and patch non-CVE identified issues as soon as you detect them.
Discovered in the wild zero-days pose more risk
Zero-days that are discovered in the wild pose the most risk to organizations, since they are actively being used by threat actors with no patch being widely available—and not every reported “zero day” fits this criteria. To help organizations, Google’s Project Zero (P0) team announced back in May 2019 they were tracking “publicly known cases of detected zero-day exploits” [ref] and that they would make it available to everyone. But does that list fully capture every discovered-in-the-wild vulnerability, or are there some caveats that organizations might want to consider?
The main caveat to consider is that Project Zero tracks high-end, high-profile 0-day vulnerabilities used primarily in “APT” style attacks. This was confirmed [ref] in a Twitter thread, by Ben Hawkes of the Project Zero team. [ref] [ref] With this in mind, organizations should be aware that this means that the list likely won’t include 0-day discovered in the wild issues outside of Project Zero’s scope. A couple of examples of excluded issues would be those affecting WordPress plugins or ones affecting blockchain technology. While these 0-days may not be extremely valuable in terms of national security, they could be timely to enterprises deploying those technologies.
But in terms of 0-days used in APT attacks, the 0day “In the Wild” sheet has tracked 221 vulnerabilities as of July 7, 2022. Consider that number; 221 known zero-days exploited in the wild that were used to compromise an organization. That is a scary figure.
However, if we back up and ask a few basic questions, it begins to put that number in a more understandable light: Over what time period? How many unique organizations were targeted? How many affect software in my organization? While the answers to those questions may lower the overall risk posed, we have to ask three questions that may make it worse.
How many exploited in the wild zero-days are not included in this sheet? How many had a considerable delay before a patch was available, or are still unpatched? How many were used targeting a given sector or country? While the sheet has a concise list of vulnerabilities used with technical information, it is missing a lot of context that could make it more valuable. More analysis and root cause analysis would be beneficial, both things P0 tries to collect. Additionally, more information on which threat actors are known to use it, the date it was disclosed, clear solution availability, and more.
Are zero-days increasing?
With zero-days getting more attention, some sources like CSO have observed that “more [zero-days] are being found”. However, the article then gives some numbers that are a bit confusing:
BLOCKQUOTE: During the first half of this year, Google Project Zero counted almost 20 zero-days… But in 2021, the number of in-the-wild zero-days was even higher. Project Zero found 58 vulnerabilities, while Mandiant detected 80–more than double compared to 2020.
In order to create this tagline, the CSO article combined two statistics. One being P0’s findings and the other was a Mandiant paper published in April, titled, “Zero Tolerance: More Zero-Days Exploited in 2021 Than Ever Before”. However, the problem is that these two sources conflict with one another—where one suggests that zero-days are not increasing while the other suggests that they are growing. So which is it?
Comparing Google’s P0, Mandiant’s, and Flashpoint’s data shows a considerable discrepancy in the aggregated data. It also shows what the trend lines look like based on the different data sets. It also shows that Google’s data and trend line deviates from the other two, which largely agree despite the difference in aggregated data. Here’s what we see looking at Flashpoint + Risk Based Security data which has a longer history:
The Why?
Per Flashpoint data, we’re on-track to see roughly the same number of zero-days this year as last.. However, the nature of zero-days makes it hard to predict. What we can say is none of the three aggregators are showing an actual upwards trend. Moving to the question of why we’re seeing “more” zero-days, Liam Tung, a contributor to ZDNet, says “Half of zero-day exploits linked to poor software fixes”. Their solution being that “software companies need to do better root cause analysis of the security bugs they patch.”
Given that Google’s P0 sheet has a column for ‘Analysis URL’ and ‘Root Cause Analysis’ , we can use that to see that only 44 out of 222 have had the root cause figured out. Only 73 of the 222 link to an Analysis URL which may be external and sometimes as short as a Twitter thread.
Tung’s article goes on to attribute that roughly half of zero-days are due to poor software fixes. Looking deeper into Flashpoint data, we might disagree. VulnDB creates an entry for each distinct vulnerability, meaning that an incomplete patch for a vulnerability typically results in a merge of subsequent information—including a new CVE ID, into the original. Our practice gives us an easy way to determine if Tung’s hypothesis is accurate. By simply looking at the 222 P0 zero-day vulnerabilities and counting how many have multiple CVE IDs within them, only five meet this criteria.
Digging deeper, we see Brian Krebs succinctly cite a Google P0 analysis that summarizes their findings:
In terms of zero-days, semantics matter
This is where choice of words becomes important. There is a difference between an “incomplete fix” (Flashpoint), “poor software fixes” (ZDNet), and “variant” (P0). Looking at one example in the table, Google says that CVE-2021-26084 is a variation of CVE-2022-26134. However, even looking at public analysis of the former and additional analysis, it’s not clear if this is a “variant” any more than calling an SQL injection vulnerability in two different endpoints a “variant”.
We have seen researchers use ‘variant’ before in a very broad sense, but without a factually correct and precise meaning, the word loses any significance. If you think of a variant as a variation in an attack, such as the difference in Spectre, Spectre-v2, Spectre-v3, Spectre-NG, ret2spec, and others, the term makes sense. But when we talk about an incomplete fix, which is where a vendor has fixed a specific vulnerability but something was lacking, resulting in that same vulnerability being exploited with a slight variation (e.g. in the payload), both can be called ‘variants’. However, the root cause is significantly different.
Conclusion
[A conclusion wasn’t written in this draft. If one was written, it would have been marketing anyway. =)]