After we published last week’s blog, A Comparison of Exploit-DB and 0day.today, readers suggested additional data points they thought might be interesting. Those suggestions sparked a wave of ideas. Building on last week’s material, this blog looks deeper at the types of vulnerabilities in Exploit-DB and 0day.today and their use in the wild.
We mentioned this last week, but it bears repeating: 0day.today has a huge volume of exploits (~38,000), but only about 20% of those are associated with a CVE. Exploit-DB has even more exploits (~45,000), and they’ve associated CVE with more than half of those. That can make comparisons look a little skewed. Regardless, we think there’s a lot of value in discussing the exploits and their associated CVE, so that is where this blog is focused.
Digging into the Exploit’s CVE
The suggestion that really got the ball rolling was from /u/No-Succotash4783 on Reddit:
Nice job pulling that report. It would be nice to also show the top CWEs / class of vulnerabilities for which exploits exist.
We were able to quickly produce “Top 10 Database CVE CWE” graphs by cross-referencing the exploits against our vulnerability data.
Exploit-DB CVE Top 10 CWE
0day.today CVE Top 10 CWE
The high volume of cross-site scripting (XSS) exploits might suggest the databases don’t have the real-world application that attackers might hope for. While XSS is useful for bug bounties, they’re rarely associated with any real threat group. Proofpoint’s recent discovery of Winter Vivern using a Zimbra XSS (CVE-2022-27926) in the wild is the only one we can recall in recent memory.
Otherwise, the databases have similar Top 10 CWE. The only real surprise is the absence of Command Injection (CWE-78) in Exploit-DB and the absence of Code Injection (CWE-94) in 0day.today. Last week, we discussed that 0day.today assigns more CVEs to new vulnerabilities than EDB has. Perhaps this shows that Code Injection is on the way down and, somehow, Command Injection is on the rise.
Of course, CWE doesn’t tell the full story. One of the weaknesses of CWE is that it doesn’t necessarily describe how a vulnerability is used. For instance, a generic buffer overflow might be used over the network (with or without credentials). It could be used locally during privilege escalation. Maybe it’s used during a user interaction exploit (e.g., in a document-oriented attack). All three of those scenarios represent significantly different attacks.
VulnCheck attempts to address this short-coming by automatically categorizing CVE according to their most likely attack scenario: initial-access, remote-with-credentials, infoleak, denial of service, local, client-side, and, of course, the dreaded “other”.
Exploit-DB Exploit CVE Categorization
0day.today Exploit CVE Categorization
The most popular categorization in Exploit-DB is initial-access. These vulnerabilities allow remote and unauthenticated attackers to gain access to a victim network. They’re the type of vulnerabilities VulnCheck believes are most important.
The most popular categorization in 0day.today is client-side attacks. Client-side attacks are user-interaction oriented attacks like XSS, CSRF, or document-based attacks. For example, Follina, is a document-based attack that we categorize as “client-side”. They can be dangerous (Follina has been used widely), but they typically aren’t as dangerous as an initial-access vulnerability.
VulnCheck’s vulnerability categorization doesn’t necessarily capture the severity of a particular group. Initial-access is obviously bad, but we just discussed the wide range of vulnerabilities that are captured by client-side. Other categories, like remote-with-credentials and infoleak, have similar broad impact ranges. To better understand the overall impact in the databases, we mapped the exploit CVEs to their CVSS severity.
Exploit-DB Exploit CVE CVSS Severity
Exploit-DB Exploit CVE CVSS Severity
Exploitation in the Wild
Of course, a freely available exploit doesn’t mean the vulnerability will be exploited in the wild. To predict which of these exploits might be used in the wild, we turn to the Exploit Prediction Scoring System (EPSS). As its name suggests, the scoring system attempts to predict which vulnerabilities will be exploited in the wild.
When discussing EPSS, we find it easier to discuss the percentile rank instead of the raw probability. The scaling is easier to understand for our monkey brains. For example, two vulnerabilities are assigned an EPSS probability of 25% and 50%, respectively. Those sound like very different probabilities, but their percentile rank (ranked against all other vulnerabilities) is 95%+. Despite their gap in probability, they are both very bad vulnerabilities with a very high likelihood, compared to all the others, of being exploited in the wild.
We mapped the EPSS percentile rank for both databases, and due to the volume of data points, we had to break out Excel (so please excuse the lack of a fancy graphic).
Exploit-DB Exploit CVE EPSS Percentile
0day.today Exploit CVE EPSS Percentile
These graphs aren’t quite what we expected. There’s a long-running stigma in our industry that publishing an exploit inevitably leads to exploitation in the wild. That sort of makes logical sense. The presence of a vulnerability in an exploit database means at least two things:
- Someone has taken precious time out of their lives to figure out how to exploit a thing.
- They shared that exploitation knowledge with the world.
A logical next step, that many have accepted as fact, is: “Bad actors use that freely shared knowledge against the innocent.”
Naively, we’d expect the probability of exploitation for any vulnerability in these databases to be nearly 100%. That isn’t what we are seeing here. While there are a disproportionate amount of 90%+ vulnerabilities, it’s interesting to see data points across the entire range, from 0% to 100%.
The reality is that the vast majority of these vulnerabilities aren’t used in the wild. VulnCheck tracks CVE exploited in the wild, and we found only a few hundred vulnerabilities in each database fit that bill.
CVE Exploited in the Wild (Tracked by VulnCheck)
Consider that Exploit-DB contains exploits for nearly 25,000 CVE, but only 500 of those have been exploited in the wild. 500 CVE is only 2% of the CVE in the database. What does that say about the other 98% of vulnerabilities of the database? What does it say about the actual harm associated with publishing an exploit?
Of course, you don’t have to exclusively trust our exploited in the wild data. The CISA Known Exploited Vulnerabilities Catalog produces similar results.
CVE Exploited in the Wild (Tracked by CISA Kev Catalog)
With all the time and effort expended discovering these vulnerabilities, developing exploits, sharing the exploits, and curating these databases, it’s wild to think only a tiny percentage ever get used.
Conclusion
This blog took a deeper look into the types of vulnerabilities in Exploit-DB and 0day.today. The databases contain a wide range of exploits for attackers to enjoy. There are exploits for initial access, pivoting, and escalation. There are exploits for phishing and drive-by attacks. But each database also has a huge amount of low hanging (and possibly useless) exploits too. At the end of the day, only a select few exploits from these databases will ever be known to be exploited in the wild.
Thank you to those of you who reached out with questions!
Do you like exploits? So do we! VulnCheck maintains the largest collection of exploits. For more information, register for a VulnCheck account today by loading https://vulncheck.com and clicking “Register”.