Author: jgamblin

Reference Rot (also called linked rot) is when hyperlinks, over time, cease to point to their originally targeted file, web page, or server due to that resource being relocated to a new address or permanently unavailable.

Tod Beardsley from the CVE board gave a talk at the 2023 CVE Global Summit called ‘Link Rot: The Problem and Archiving for Posterity‘ on the problem of reference rot, sadly I was not able to attend, but I was interested in how bad the problem was, so this past week I wrote some code to find out.

Reference Counts

First, I collected the CVE data from the NVD data feeds and parsed all the references.

Here are the high-level numbers:
CVEs: 199,019
Reference Links: 797,474
Average References Per CVE: 4

CVE-2014-0224, an OpenSSL vulnerability, has the most reference links with 303(!?) unique references.

Finding Reference Rot

I knew I could not hand-check the nearly 800,000, so the logical first step was to see how many of the 13,991 unique domains responded to DNS requests using PyNnlookup and Google’s Public DNS [8.8.8.8].

It took over thirty minutes to run the 13,991 DNS lookups, and when done 1,520 of the listed hosts did not respond.

How Bad Is Reference Rot?

Those 1,520 domains account for 109,411 broken links, or 13.71% of all links.

Over 35,000 broken links are in CVE years 2005, 2006, and 2007.

One domain, SecurityFocus.com, is responsible for 82,854 or over 75% of all broken links. The top 5 domains account for over 90% of all broken links.

What Can Be Done?

¯\_(ツ)_/¯

You may be able to point the dead links to the Wayback Machine at archive.org or a similar site, but this will need to be figured out before we lose tons of valuable vulnerability research.

Data

All Reference Domains
All Broken Domains
Broken Domains By CVE Year
All Broken Links With CVE Information
Jupyter Code

Notes

Looking at DNS records is probably the simplest form of checking links and is not 100% foolproof. To get a 100% complete picture of the broken links, you would need to pull the web pages and do some form of data verification that was beyond this project’s scope.

Here is a picture to make my unfurl link look better:

2022 was a record-breaking growth year for CVE data, and I figured it would be a great way to start the new year by going through the data and highlighting some of the most interesting data points. All the data and graphs used in this blog are available in this GitHub repo.

CVEs By The Numbers

We ended 2022 with 25,093 published CVEs. On average, there were 68.75 CVEs published per day. December was the month with the most CVEs published, with 2,426 or 9.7% of all CVEs for the year. 5,414 CVEs, or 21.6% of all CVEs, were published on Tuesdays. June 2nd had the most CVEs published in a single day, with 320.

CVEs By Month

CVEs By Day Of Week

Top 10 2022 Publishing Days

CVE Growth

Like every year since 2017, we saw a record-breaking number of CVEs published, with 25,093, a 24.51% increase over 2021. It also means that 13.06% of all CVEs published were published in the previous year.

CVE Identifiers

A somewhat confusing part of CVE IDs can be the year identifier. It is often assumed that the year represents when a CVE is published, but it represents when it was assigned or when the vulnerability was made public.

I say all that to point out that the “oldest” CVEs published this year belong to BlackICE PC Protection, 20 years after they were made public:

CVE-2003-5001
CVE-2003-5002
CVE-2003-5003

CVSS

The Common Vulnerability Scoring System (CVSS) provides a way to capture the principal characteristics of a vulnerability and produce a numerical score from 0.0 to 10.0, reflecting its severity. The average CVSS score this year was 7.19.

This year 48 CVEs scored a “perfect” 10.0.

CVE-2022-27049, a vulnerability in RaidDrive, had the lowest score of 2.0.

CPE

Common Platform Enumeration (CPE) is a structured naming scheme for information technology systems, software, and packages to help identify vulnerable software identified in a CVE.

This year there were 2,815 unique CPEs identified in CVEs. The most common was cpe:2.3:o:google:android:11.0:*:*:*:*:*:*:* that was applied to 299 CVEs

CVE-2022-22160, a vulnerability in Juniper Networks Junos OS, is the CVE with the most CPEs with 364 unique, vulnerable configurations.

CNA

CVE Numbering Authorities (CNAs) are software vendors, open source projects, coordination centers, bug bounty service providers, hosted services, and research groups authorized by the CVE Program to assign CVE IDs to vulnerabilities and publish CVE Records within their specific scopes of coverage.

Today there are 261 CNAs. In 2022, 200 unique assigners published a minimum of 1 CVE. To make this confusing, 109 CNAs did not publish a CVE this year, and 83 CNAs not listed as an assigner published at least one CVE.

Top CNAs

The Top 5 CNAs last year were:

Github
WPScan
Microsoft
VulDB
Huntr.dev

Four of the top five CNAs this year, excluding Microsoft, were purpose-built to report CVEs for various projects.

CWE

CWE is a community-developed list of software and hardware weakness types. It is a common language, a measuring stick for security tools, and a baseline for weakness identification, mitigation, and prevention efforts.

There are 1332 CWEs, and this year, 236 were assigned to CVEs. CWE-79 was the most assigned CWE and was assigned 3230 times or to 12.88% of all CVEs. NVD didn’t assign a CWE 2835 times or to 11.30% of all CVEs.

Notes

• All data and graphs for this blog post were created using the jupyter notebooks in the GitHub Repo.
• Rejected CVEs have been removed from the dataset because some CNAs publish and reject any unused reserved CVE IDs causing an artificially inflated record count.
• CVE.ICU is a jupyterbook site that I run that has real-time CVE information throughout the year.

The National Vulnerability Database plays a vital role in the CVE publication process that many people may overlook or not know they are responsible for. After MITRE publishes a CVE, the NVD enriches it with data points that make it actionable by security companies and professionals.

Some of these data points include:
CWE
CVSS 3.1 Base Score
CPE

I was recently asked how long, on average, it takes NVD to complete its initial analysis. I looked around for a bit and couldn’t find the information, so I built this jupyter notebook to find out using the NVD Change History API and the very helpful {Initial Analysis} filter the API provides.

After running the notebook for all CVEs published between January 1st, 2022, and November 15th, 2022, the average analysis time takes 5 days 22:14:22 (the Standard Deviation is 3 days 15:42:25). I will leave it to the math geeks to decide which number is more valuable, but either number is excellent considering the growth of CVEs.

The quickest analyzed CVE this year is CVE-2022-43488 at 27 minutes, and the slowest is CVE-2021-35036 at over 213 days.

Since everyone loves a good visualization, here is a quick graph (and code) of the analysis timing.

Note: The notebook is not the fastest, and with the API rate limiting, it took just over 7 hours to run the 22,619 requests. If you are interested in looking at the data, it is all here in a CSV.

For a recent project, I needed all the NVD CVE and EPSS data in Elasticsearch and couldn’t find an easy way to do it, so I built CVElk. CVElk quickly builds a local Elastic Stack using docker compose with the help of a simple shell and python script.

Philipp Krenn from Elastic also contributed an updated dashboard to the project to help with the data visualization.

Want to Help?

The project’s code is hosted on GitHub, and I am always happy to try to implement any improvements and would love to see this become useful to a wide group of people.

Security Summer Camp, as it is colloquially known, is three security conferences that occur during the same week in Las Vegas.

The three conferences that make up Security Summer Camp are:

• BSides Las Vegas
• Blackhat USA
• DEF CON

While preparing for these conferences, I dug through their schedules and picked out the talks I was interested in catching.

BSides Las Vegas

BSides Las Vegas is back with a fantastic schedule and one of the best community events of the year.
Here are a few fantastic talks I will try to catch.

• Scaling the Security Researcher to Eliminate OSS Vulnerabilities Once and For All
• SBOM challenges and how to fix them!
• Clean Forensics: Analyzing network traffic of vacuum bots
• Zero Days should not be a fire drill

Blackhat USA

Blackhat USA is the “commercial conference” of the three but still has a great lineup of talks.
Here are the talks I will be catching (and presenting at)

• Bug Hunters Dump User Data. Can They Keep it? Well, They’re Keeping it Anyway.
• Real ‘Cyber War’: Espionage, DDoS, Leaks, and Wipers in the Russian Invasion of Ukraine
• Lessons from Ukraine: What Cisco Talos Threat Researchers Learned from Defending Critical Infrastructure in Ukraine.
• A Discussion on Risk-Based Vulnerability Management (I am moderating this panel)

DEF CON

DEF CON is probably the most well-known hacker conference in the world, and rightfully so with the quality of talks this year.

• You’re Muted Rooted
• Dragon Tails: Supply-side Security and International Vulnerability Disclosure Law
• Tracking Military Ghost Helicopters over our Nation’s Capital
• Trailer Shouting: Talking PLC4TRUCKS Remotely with an SDR
• UFOs, Alien Life, and the Least Untruthful Things I Can Say.

Along with these talks, they have these interest-specific villages where I will spend a lot of time. Here are the villages where I know I will be spending time.

• Car Hacking Village
• Blue Team Village
• App Sec Village
• Crypto & Privacy Village

Wrapping Up

Did I miss anything you are interested in seeing, or will you be in Las Vegas and want to chat? Let me know on Twitter at @JGamblin.

Covid restrictions are starting to be relaxed, so I am beginning to feel like Willie and am getting on the road again, and in the next six weeks, I am attending and presenting at these four amazing events.

BSidesKy

I am amazingly excited to attend bsides.ky in the Cayman Islands at the end of May, where I will be leading a workshop on using Jupyter Notebooks for Security Professionals.

BSidesSF

BSidesSF is one of my favorite BSides events, from my first time in 2014 when it was held at the DNA Lounge in SOMA to recently when it moved to City View at Metreon to be closer to RSA. I am looking forward to catching up with everyone at the event.

RSA

The RSA conference has always been the start of the security conference year, and the fact it is happening in early June is going to be interesting to see how it changes the conference. I will attend and give multiple talks on CVE data and Risk Based Vulnerability Management.

CiscoLive!

I am lucky to be able to attend Cisco Live for the first to talk to our customers and attendees about Risk Based Vulnerability Management.

If you are attending any of these events, I would like to grab some time and hear what in security is interesting to you. Please ping me on Twitter or drop me an email if you will be around.

I have spent a lot of time this year working with CVE data and most of that time in Jupyter notebooks. Over the holiday season, I decided to build a website from these notebooks using Github Actions, Github Pages and NBConvert.

CVE.ICU ended up being the end product, and here is the source code. It is still an early work in progress, but please let me know if you see anything I should add.

In a Study in Scarlet, Sherlock Holmes said, “It is a capital mistake to theorize before one has data,” which is one of my favorite Sherlock quotes. For the last month or so, my team has been dealing with missing CPE data points in the Mitre CPE data, and it finally forced me to set down and put together a new tool to analyze the data.

What Are CPEs?

CPE is an acronym for Common Platform Enumeration. It is a standardized method of describing and identifying classes of applications and operating systems in a common format as described in this NIST document.

How Are They Used?

The most common use case for CPE data is fairly straightforward; you want to find all CVEs affecting either a software package or an operating system you run. The NVD actually provides an API to allow you to do these lookups programmatically.

What Are The CPE Data Quality Issues?

When a company attaches a CPE to CVE, it has four optional data points in the JSON Scheme:

• VersionStartIncluding
• VersionStartExcluding
• VersionEndIncluding
• VersionEndExcluding

These data points allow you to narrow down the version of the software that is vulnerable to the CVE.

The correct usage of these fields is present in CVE-2020-6572. Looking at the data provided, we know anything that is Chrome 81.0.4044.92 or older is vulnerable and should be patched.

The incorrect usage of this field is present in CVE-2015-8960. Looking at the data provided, we have to assume that all versions of Chrome (IE, Firefox, Safari, and Opera) are still vulnerable.

How Many CVEs Have This Problem?

As of today, 71,811 CVEs have at least one CPE that does not include version information. Not all of these are wrong, as if your CPE is mapped to a unique version, you can find an upgrade path to remove the vulnerability.

Real World Example:

To test the data, I decided to see how many CVEs with open CPE for the 3 major browsers (Chrome, Firefox, Edge) existed.

What Can Be Done?

In a perfect world, Mitre and NVD would make these fields mandatory and remove the ability to assign a non-versioned CPE (ex: cpe:2.3:a:microsoft:edge:-:*:*:*:*:*:*:*) to a CVE.

Where is the Code?

The code is in this jupyter notebook and can be run on Colab:

I was recently asked if I had ever thought about trying to predict CVE growth. I had not, or really didn’t even know where to start, but after some research, I found the Prophet project that is a forecasting algorithm open-sourced by Facebook and uses the GAM family of algorithms.

Using prophet with the NVD data in a Jupyter notebook was a lot easier than I expected, and for the first iteration, I am thrilled with the outcome.

Graphs

Data

Looking at the individual data points is extremely interesting. Here are the top 10 predicted days for the rest of the year, and it will be interesting to see how close the prediction is.

Code

I have put the Jupyter notebook in this Github Repo and will continue to make updates and tweaks to explore time series prediction.

The first quarter of 2021 has been a busy quarter for the Project Zero (P0) team as they announced 16 “in the wild” zeros days. That is one new announcement a week on average. This is great for driving news cycles or if you’re in marketing and need some FUD to help sales. This isn’t so great if you are on a security team and have to deal with the buzz these announcements cause every week; redirecting time and resources that could otherwise be used by your team to remove the existing risk on your network. 

Here is a quick breakdown of the 16 CVEs that P0 has released this year: 

Of the 16 announcements by P0, only 6 of them have publicly available proof of concept code and only the Exchange CVEs have been weaponized as far as I can tell.  That means a lot of companies have spent a lot of resources rushing emergency patches out to their systems to defend against zero-days that make huge news headlines like these:  

The problem is while I am sure that this is a legitimate iOS security vulnerability and P0 probably did observe one group of actors using it against another group of actors; but what risk does it pose to the average system and person on the internet?

It’s important that security teams know that they need to put out the proverbial “fire” when the  “exploited in the wild” alarm is sounding. Unfortunately, a lot of these disclosures are like a fire alarm that sounds anytime there is a fire anywhere in your city versus in your actual building. If this happens too often, teams will lose faith in the “in the wild” moniker and may skip critical vulnerabilities; or alternatively, teams may exert time fixing low-risk vulnerabilities that make the headlines instead of the widely exploited vulnerabilities that are actively being used by cybercriminals.  

SideBar: 

Vulnerabilities likely to introduce the most likely risk to your environment are vulnerabilities that have high volume (Windows vulnerabilities)  and vulnerabilities with a high velocity of exploitations (Notpetya ransomware and Mirai botnet) and should be treated differently than vulnerabilities that are low volume targeted attacks that make up the vast majority of these P0 CVEs. 

To be blunt, if an exploit is being used to target a group of people by a nation-state, it should be reported, but it is not the same as a widespread automated exploit with public code and many groups exploiting it, and it shouldn’t be treated as such. Even if we added a modifier like “privately exploited in the wild” and “publically exploited in the wild” it would be easier for security teams to understand the true risk and when they need to quickly patch their systems. 

Until we figure this out I am going to go reboot my iPhone because I have to protect myself from another zero-day.