Log4Shell: How “Big” Is It?
February 16, 2022 • RBS
This article is derived from the 2021 Year End Vulnerability QuickView Report.
By now, the entire world is hopefully aware of what Log4Shell is, and why it’s a major problem. Since its discovery at the end of November last year, the news has been dominated by headlines touting its impact and how organizations need to pay attention, stop, and remediate Log4j issues. While more and more articles are published, each of them seems to be asking the same question, but they all seem unable to give a clear answer: Just how “big” is Log4Shell?
Log4Shell is a Mega-Vulnerability
If you are not familiar with what we do at RBS, or what VulnDB® is, we can start with the fact that it is the most comprehensive, detailed, and timely source of vulnerability intelligence available on the market. That means the data that we provide our customers is independently aggregated, containing vulnerabilities found in IT, OT, IoT, CoTS, and third party libraries and dependencies.
VulnDB details over 280,000 vulnerabilities, including over 91,000 that CVE/NVD fails to report. This context helps us fully explain and contextualize Log4Shell’s size and impact, since it has become what we call a “mega-vulnerability”.
This term describes entries that take up significant bandwidth in our database, and notable “mega-vuln” entries include Spectre, POODLE, and Heartbleed. At first glance, it may seem that there’s a correlation between size and infamy, but the amount of attention a vulnerability receives is not the defining factor. Rather, to qualify as a mega-vulnerability, entries need to have hundreds or even thousands of vulnerability references while affecting a tremendous amount of products and vendors. The accompanying charts illustrate how Log4Shell compares among its peer group.
Log4Shell’s Unprecedented Growth
Most mega-vulnerabilities take years to accumulate references and affected vendors/product information. But in just a month, Log4Shell has surpassed every other mega-vulnerability, except for one. At this time, there are over 1,850 vulnerability references specifically citing Log4Shell and its variants, and they affect over 6,200 vendors/product combinations. Of those, over 275 are unique vendors and 1,677 unique products, meaning that some organizations will likely be impacted several times over.
In terms of affected vendors and products, Log4Shell falls slightly behind POODLE. However, if Log4Shell-related vendor advisories continue at their current pace, it will likely surpass POODLE within the next month. Nevertheless, the main highlight is the incredible amount of Log4Shell references circulating on the web.
Out of all 280,000 known vulnerabilities, Log4Shell has the most references by a wide margin. This means that there is an incredible amount of existing information out there. But if that’s the case, why are organizations seemingly struggling to mitigate and remediate affected assets?
Vulnerability References Provide a Clearer Picture of Risk
Despite the plethora of available information, organizations typically don’t have a tool that aggregates every known reference in one place. Vulnerability references provide much needed context for an issue, making it essential for intelligence vendors to constantly update their entries (especially Log4Shell) with as many of them as possible.
Even though they should, most vulnerability intelligence vendors do not do this. References can contain new information that could drastically affect the impact, severity, or solution availability for a given vulnerability. It’s common to see a vulnerability disclosed that does not initially have every detail needed to properly triage it. Key details like location, exploitability, or solution information are often found after the vulnerability’s initial disclosure, and they can come from third-party sources that are unrelated to the originating vendor.
As such, vulnerability references play a critical role in contextualizing the risk that an issue poses to organizations. By taking advantage of a feed that captures them and includes them with the actual vulnerability entry, organizations will be better informed if they need additional details specific to a vendor or product. Without references, security teams may question the provenance of the information in the vulnerability database. And when it comes to Log4Shell, security professionals don’t have the resources to scour the internet for every mention.
But depending on where you get your vulnerability data, hours spent researching Log4j issues will only scratch the surface. This is especially true if using publicly sourced data from CVE/NVD:
Although CVE disclaims that its list of vulnerability references should not be considered complete, in the end, what is provided simply doesn’t benefit the end user. On the other hand, VulnDB catalogs over 1,850 Log4Shell references compared to MITRE’s list of around 100, meaning that CVE/NVD users will be forced to find as much as 95% of the information that is actually available themselves.
The Importance of Standardized Data
Some skeptics may argue that providing every reference could actually just overload security teams instead of providing a benefit. And in the age of overwhelming amounts of data, this concern has merit. If we were to dump every known reference on organizations without validating their value, the sheer amount of data may render the information unserviceable. But what if every vulnerability reference was sorted based on their contents and relevancy, with options to consume based on affected CPEs?
This is the importance of an independently researched, comprehensive, and detailed vulnerability database. By being proactive in searching and capturing published details, we are able to provide organizations with a more complete picture, allowing security professionals to make informed risk-based decisions.