My Apple Watch needs an update. Usually, I just initiate the software update and sit back and let it do its thing.

This time, out of curiosity, I clicked the link for more information about the patches for watchOS 11.6.

On the page is a list of various software patches. Under each patch is a summary that contains the impact before patching, a description, and a corresponding CVE number.

There were many names that I hadn’t seen before, with only a few that I was familiar with, such as libxml2. There were several sections headed with the same name: “WebKit.” It appears that this software had a lot of issues that were patched in this update.

At the very bottom was a surprisingly wholesome section, titled “Additional recognition.” Under each software was a sentence acknowledging so-and-so for their assistance. That was cute.

As I doom-scrolled this page, it got me curious.

What the heck is CVE?

At a very high level, it appeared to be some sort of cataloging or ID system for various vulnerabilities. But it got me curious to dive a little deeper into the details. So, here is what I’ve learned so far.

Purpose

You can find CVE’s official website at https://www.cve.org as of today, where they just celebrated 25 years of existence. The legacy website is https://cve.mitre.org.

What gave birth to the idea for CVE in the first place? We can credit that to The MITRE Corporation, where it was first suggested in 1999.

Its mission statement says that the goal is “to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities” (Common Vulnerabilities and Exposures, n.d.).

Think of it as a coalition composed of different organizations, a place where people can come together and raise awareness of vulnerabilities as they are discovered. Of course, this assumes that people will do the right thing and report vulnerabilities instead of keeping the knowledge to themselves and exploiting them or selling the information.

First, based on their website, anyone can find a vulnerability and report it to CVE. There have been vulnerabilities reported by the casual user, but the more common avenues that vulnerabilities are discovered and added to CVE are via independent security researchers, bug bounty hunters, security firms, and open source entities. This makes sense since cybersecurity professionals or enthusiasts are actively hunting down vulnerabilities, compared to the average user who happens to discover an exploit.

A bug bounty hunter is someone who gets paid for finding vulnerabilities and exploits and reporting them ethically to the company.

The CVE Rating System Explained

CVE uses a rating system to label how severe or critical a vulnerability is, and it is called CVSS aka Common Vulnerability Scoring System. The scale goes from 0 to 10, with 0 being not severe and 10 being the most severe.

The way CVSS scores are determined are based on a few different factors, such as how the attack happens (is it remotely, locally, or physically?), how difficult it is to exploit (simple or complex?), if the exploit can be done with or without elevated admin privileges (no or low privileges is worse), and whether the attack requires user interaction (exploits requiring no user interaction are worse).

CVSS scores also take into consideration whether confidentiality, integrity, and availability are impacted. For confidentiality, that’s whether sensitive data is exposed. For integrity, that’s whether data can be altered or corrupted. For availability, that’s whether the system’s functionality is affected. Does it render the service completely unusable? Or only partially?

There is a sliding scale for these three areas of impact, because for integrity, it could be that there is no risk of integrity being compromised. Or maybe only a specific part of an application is at risk of corruption. Or all of the data for a system is susceptible to being altered.

These three impact areas are derived from the CIA triad, a fundamental model used in assessing security frameworks.

Log4j Exploit

An example of a CVE with a high CVSS score is Log4j CVE.

This exploit was discovered in 2021, and the ID it was assigned through CVE’s reporting process is CVE-2021-44228. It is more commonly known by its other names Log4j and “Log4Shell”. The exploit was in an Apache Log4j 2 logging library, which is widely used in Java applications. There was a bug that allowed remote code execution in the Java Naming and Directory Interface (JNDI) lookup feature.

Log4j was given a base score of 10.0 in the National Institute of Standards and Technology’s (NIST) Vulnerability Database (National Institute of Standards and Technology, 2021).

I was a little surprised to see that it was given a score of 10.0, the maximum severity level, in part because I wasn’t familiar with other CVEs and so I had no context for how generous the scoring system was. This was my first foray into the topic.

But after thinking on it for a while, it made sense it scored such a high rating since this was a vulnerability that could be exploited remotely and was relatively easy to do since all you had to do was query code you wanted to execute via the logging library.

Before this was patched, companies could temporarily safeguard against this in a few ways. One, by disabling the message lookup feature. Two, removing the entire JNDI lookup class from files, effectively removing the lookup functionality.

However, it’s important to note that there are more nuances to this vulnerability. In the article I read about this vulnerability, it specifically mentions that “having a vulnerable version of Log4j is not enough for attackers to gain remote code execution” (Breen, 2021).

You can read more about it, but that’s the Log4j exploit in a nut shell.

Thoughts

Overall, I think it only makes sense that there would be an initiative like CVE, for people to come together and rally against vulnerabilities and exploits in the digital space. Information is power, so a place to compile information about all these various possible threats is a great way to protect people and devices from falling victim to them.

Bibliography

Breen, Kev. (2021, December 15). Everything you need to know about Log4Shell (CVE-2021-44228). Immersive Labs. https://www.immersivelabs.com/resources/blog/everything-you-need-to-know-about-log4shell-cve-2021-44228

Common Vulnerabilities and Exposures. (n.d.). About CVE. CVE. https://www.cve.org/

National Institute of Standards and Technology. (2021, December 10). CVE-2021-44228. National Vulnerability Database. https://nvd.nist.gov/vuln/detail/CVE-2021-44228

CVE (Common Vulnerabilities & Exploits)