The Journey to 300,000 Vulnerabilities: The Good, The Bad, and The Bizarre

Recently, our VulnDB team reached a tremendous milestone in our pursuit of best-in-class vulnerability intelligence: aggregating our 300,000th vulnerability disclosure. While that is a significant accomplishment and cause for celebration, it is also a grim reminder of what security teams face every day.

Instead of constantly reminding vulnerability managers and information security teams how bad software can be, we want to showcase the sometimes weird path our research has taken us. Here are some of the most interesting and colorful vulnerability disclosures we’ve come across.

Vulnerability zero: The origin story

When many think about the computer security industry, they tend to believe that it is relatively young. However, it is actually over a century old! In a previous post, we took a deep dive into the world’s oldest vulnerabilities affecting Guglielmo Marconi’s wireless telegraph. And although these issues are more than a hundred years old, something can still be learned.

The first two recorded vulnerabilities resulted in the world’s first Man-in-the-Middle (MitM) interception, with Marconi’s vulnerabilities being unencrypted message transmissions that can trivially be intercepted, and a message spoofing weakness due to no authenticity being established. But looking now, this same kind of attack has been seen as recently as September 29, 2002, where a disclosure detailed MitM issues affecting multiple Mitsubishi Electric products. 

The second, message spoofing due to lack of authenticity checking, can be seen in a variety of spoofing issues ranging from improperly verifying SSL/TLS certificates, to relying on e.g. IP addresses as the authenticity check. Over 120 years later and many vendors still don’t heed the lessons that Marconi experienced in such a grand, albeit embarrassing, manner.

SQL injections and cross-site scripting: Low-hanging fruit

In the early 2000s, the world witnessed a mass migration to web applications as the desired interface for users and computer nerds alike. Accessing the web was easy, and the popularity of the internet helped create a single application designed to access an incredibly wide variety of systems and resources. But with this new technology came some hard lessons in writing secure code that led to a significant number of web application vulnerabilities such as cross-site scripting (XSS) and SQL injection (SQLi).

Since XSS flaws are arguably the easiest to find, it is no surprise that we saw significant numbers in the decade after 2000, and another significant spike in 2012:

SQL injection, which is easy to trigger a potential flaw, also took off in 2005 and a second significant spike in 2008. Many researchers, especially neophytes, would input a single character in an attempt to trigger an SQL error before definitively declaring they found a vulnerability. That error message is indicative of a potential SQL injection flaw, but it most certainly is not definitive. That made it difficult for the majority of vulnerability databases to weed out what was legitimate, but not VulnDB.

Rounding that out we saw significant spikes in the disclosure of cross-site request forgery (CSRF) flaws in web applications in 2010 and 2012. These flaws are relatively easy to discover and until 2010 there was no significant knowledge of the issue in developer circles. One might argue it is still that way given how prevalent CSRF flaws are—even in some of the most high profile applications and products.

Megavulns: Log4Shell, POODLE, Spectre, and more

In VulnDB, we have some entries that are simply incredible. Often the vulnerabilities with familiar names like Log4Shell, POODLE, Spectre, or Heartbleed to name a few, contain thousands of references and many thousands of affected products. We have dubbed these “megavulns” due to the sheer size each one represents and how prevalent they are. 

Examining these megavulns by number of products affected, Log4Shell comes in first place, followed by POODLE, Spectre v2, Spectre, and SWEET32. While the name is more common than some listed, Heartbleed only comes in at number twelve. Looking at the top 30 megavulns by product affected, 10 are in the Linux Kernel, five in OpenSSL, four in Oracle Java, four in multiple CPU vendors, and three are in Apache libraries. As of this blog, Log4Shell is now the king of all vulnerabilities with the most references, unique products, unique vendors, and vendor/product combinations.

In the scope of a vulnerability database, these entries are challenging. When given a name that becomes popular due to news coverage sticking to it, it results in more vendors feeling compelled to issue their own advisories. As more vendors do that, we have to aggregate all that data and constantly update these entries. Sometimes, we find ourselves still updating megavuln entries five years later.

Fun oddities

Along the way we have seen some interesting, to say the least, vulnerability disclosures. Twenty four years ago, the r00t group posted a dark-humored advisory to Bugtraq warning of a serious race condition in a LitterMaid product. The automated kitty litter box, they said, could crush the cat “forcing the administrator to find a new best friend.” While this was a parody advisory, it still stands out as a fairly amusing one.

Adding on to the list of oddities, throughout the years, there have been disclosures related to Red Star OS, a North Korean Linux distribution. Apparently, the operating system suffers from default permission issues, client-side code execution issues, and many more. 

Aside from that, somehow, we’re still seeing vendors include default passwords for newly installed devices rather than forcing an administrator to set a unique one upon installation. Worse, we’re still seeing new products released with hardcoded passwords that cannot be changed by the administrator. With so many things moving to the ‘Internet of Things’ (IoT) approach, these include irrigation systems, thermostats, wind turbines, building control systems, and more.

Myths and NAVs

At time of publishing, VulnDB has officially crossed the 300,000 threshold of legitimate vulnerabilities. While we did announce that VulnDB reached 300,000 vulnerability entries, practitioners should be aware that a comprehensive vulnerability intelligence source also collects “illegitimate” disclosures. Including these types of entries is valuable to customers and should not be interpreted as a tactic to inflate numbers. By including “Myth/Fake” or “Not a Vulnerability”, a.k.a. NAV (a valid stability bug, but not a vulnerability) entries, our customers can quickly determine that we have evaluated the issue and clearly marked it as such, with reasons as to why—preventing them from wasting their time.

It’s worth taking a brief look back at these illegitimate disclosures since they are a growing part of our life. The first we have cataloged, a local buffer overflow in the ‘su’ program on Slackware Linux, dates back to August 1998. After the disclosure, the moderator of Bugtraq pointed out that no one had been able to reproduce it, and since the exploit code was derived from something he published, he was considered an authoritative source in two ways. Since then, the problem of invalid disclosures has become tremendous.

Arbitrary numbers and information on how we got here

Before we end this fun journey through the good, bad, and the bizarre, we’ll share a few arbitrary numbers and other tidbits of information about how we got here. Some may wonder what vulnerability is actually the first to appear in VulnDB. That would be “ColdFusion Application Server exprcalc.cfm OpenFilePath Parameter Arbitrary File Disclosure”. Many will see ColdFusion and have various feelings, including contempt, especially administrators charged with security systems with it installed.

VulnDB’s 300,000 entry ended up being “Linux Kernel SCSI WRITE SAME Command NDOB Bit Handling NULL Pointer Dereference Local DoS”. A little secret about the VulnDB team—we do our best to make sure either weird, fun, or high-profile vulnerabilities end up on big numbers. Originally, we had picked a vulnerability in “Oracle Unbreakable Linux” for our 300,000th entry, but subsequent examination showed it was actually a vulnerability in the Linux kernel instead. Foiled again.

Remediate vulnerabilities with Flashpoint

VulnDB is the most comprehensive source of vulnerability intelligence available—detailing over 300,000 vulnerabilities affecting all manners of IT, OT, IoT, and third party libraries and dependencies. Using VulnDB, security teams have everything they need to identify known vulnerabilities affecting their deployed assets and remediate or mitigate them. Sign up for a free trial today.