The Race Between Security Professionals and Adversaries

We examined vulnerabilities between first disclosure and release on the National Vulnerability Database (NVD) to understand timelines of the security community and threat actors.

We’ve previously reported on the importance of a comprehensive strategy for risk assessment of emerging vulnerabilities and presented some important case studies. We’ve also investigated the time between NIST’s National Vulnerability Database (NVD) release of a vulnerability and development of an exploit, determining that this typically takes a week. In this blog we present a more data-driven overview of the ecosystem of emerging vulnerabilities.

We started by investigating the well-known fact that there is often a gap between the first announcement of a vulnerability and release of the vulnerability on the NVD. This investigation used Recorded Future’s platform which applies natural language processing and machine learning to the open, deep, and dark web. Recorded Future gathers content from over 750,000 sources and organizes it for analysis. For this investigation, we particularly relied on CVE, product, and company entity detection.

We observed 12,517 CVEs that were first published on NVD in 2016-2017. Of these, 75% (9,505) had open, deep, or dark web coverage available prior to the NVD release. We observed a median gap of seven days advance notice for these CVEs. Median is certainly not to be confused with the mean. Longer gaps are quite common with 25% of CVEs having at least 50-day gaps and 10% having gaps of over 170 days.

We also examined the trend in gaps for CVEs initially announced in 2016 and found an increase in gaps over time with a median gap of five days for CVEs announced in the first six months compared to eight days for CVEs announced in the second six months. And these are the CVEs that have subsequently been added to NVD. There are still over 500 CVEs that were first announced in 2016 that are still awaiting NVD release.

General Lifecycle of a CVE

The typical life of a CVE starts when a researcher or vendor discovers a vulnerability and requests allocation of a CVE number. They will prepare initial analysis and announce the vulnerability on some channel, most formally on a company website, or perhaps in a security blog. Work will simultaneously be going on with NIST to prepare an initial analysis for release on NVD. Waiting for release on NVD is clearly insufficient for timely awareness. In fact, we observed 114,709 documents about these 9,505 CVEs from 1,575 distinct sources during the pre-NVD release time period. Additionally we observed tweets from 15,669 authors.

Obviously other content sources are required to stay up-to-date with the latest vulnerabilities. We were surprised to discover first reporting of CVEs on over 300 sources. Largely these first to announce sources are from the affected companies themselves such as Oracle Technology Network and Android Security Bulletin Advisories. Others are various vulnerability projects or aggregators operating over a broad cross section of vendors such Rapid7’s Metasploit Exploit Database and Security-Database. Staying current is certainly not straightforward. Reading only English isn’t sufficient either as we saw about 200 CVEs first reported to the Chinese National Vulnerability Database maintained by the China Information Security Evaluation Center.

Looking more closely at this gap between announcement and NVD release, we observed different behavior for different organizations as well. Some companies manage this process quite tightly with a low median announcement gaps such as Adobe (one day) or Microsoft (two days). Other companies have longer median gaps of 30 or more days.

Above: Boxplots of 2016-2017 gaps between initial vulnerability announcement and NVD release. Includes CVEs with positive gaps and companies/projects with more than 100 vulnerabilities. The center line in each boxplot represents the median of the data values in the box and the box itself is bounded by the first and third quartiles of the data. The whiskers extend to data points within the main distribution of data and the individual points are considered “outliers.”

The length of these gaps is not unambiguously good or bad. When organizations have small gaps between announcement and NVD release, are they quickly addressing and responding to new vulnerabilities, or are they not announcing known vulnerabilities until the last moment, leaving customers unaware of exploitable infrastructure? Are companies with longer gaps giving customers as much information as possible to protect themselves, or investing insufficient resources in managing vulnerabilities in their products?

Overall we see an eventual median CVSS score of 6.8 for CVEs with a week or less of preannounced time compared to a median CVSS score of 5 for CVEs with more than a week announcement gap. This difference is highly statistically significant as clearly more community and NVD analyst attention is paid to more serious vulnerabilities.

The Marathon of Patching Vulnerabilities

So that’s the good guys and their race — identify vulnerabilities and develop, publicize, and deploy patches as quickly as possible. It’s a race because they are opponents.

Adversaries aren’t waiting for NVD release and preliminary CVSS scores to plan their attacks. The race typically starts with the first security publication of a vulnerability. This propels activity in the adversary community and from that point, the race is between those developing and deploying the patches or the exploits. We often see reposts of researcher reports directly into deep and dark web sources. They may even be translated, for example, into Russian on Russian criminal forums. POC code is discussed, posted, sold.

The adversaries are also racing with an unfair advantage. They only need to get one exploit through an organization’s defenses to cause damage. Vulnerability management teams need to defend against all possible exploits.

We investigated the adversary intelligence efforts using Recorded Future’s collection from deep and dark areas of the web including paste sites, criminal forums, and onion sites — places you never want to see your email address.

Perhaps surprisingly, adversaries aren’t shy about explicitly using the CVE identifier as they are doing their work. The efficiency value of a common vulnerability nomenclature is as useful for adversaries as it is for security researchers.

During this pre-NVD release period, we observed reports on 659 CVEs on the deep and dark web — 53 different sources. (5% of all preannounced CVES. 30% of those were found in foreign-language content.) We observed 91 unique actors involved with some authors working with as many as 10 CVEs. They are clearly monitoring the diverse set of sources required to keep up with the most recent vulnerabilities. Not surprising, adversaries focus on more dangerous vulnerabilities (median CVSS score of 6.5 versus a baseline of 6.0).

In fact, the top 20 vulnerabilities on the deep and dark web have a median CVSS of 7.2. We expected the CVSS scores to be even higher for vulnerabilities in adversary intelligence sources and suspect that more serious CVEs get patched faster and are not always as valuable for exploit. Ranking companies by pre-NVD release adversary reports has Google at the top followed by Apple, Microsoft, and Oracle. In fact, there were more Google CVEs than the next three combined.

CVE Example: Dirty Cow

Let’s examine a specific example. Linux vulnerability CVE-2016-5195, commonly referred to as Dirty Cow, was announced on October 19, 2016 and was immediately covered by numerous information security sources. Within two days, an initial report was translated to Russian and posted on a Russian criminal forum. Six days later, POC code was placed on Pastebin. This potential exploit code was available a full two weeks before the November 10 initial release for this CVE on NVD.

Recorded Future maintains a risk score for vulnerabilities that blends risk-related content from our collection together with a CVSS score when available. We routinely see 600-700 unreleased CVEs on our risk list. On any given day we see 30-40 of these reported on via the deep and dark web. At the time of this analysis we examined the top unreleased CVEs observed.

Top Unpublished CVEs on Deep/Dark Web (6/1/2017)	Description	Source
CVE-2017-1000367	"... a serious vulnerability in sudo command that grants root access to anyone with a shell account. It works on SELinux enabled systems such as CentOS/RHEL and others ..."	Link
CVE-2013-7285	"XStream could deserialize arbitrary user-supplied XML content, representing objects of any type. A remote attacker able to pass XML to XStream could use this flaw to perform a variety of attacks, including remote code execution in the context of the server running the XStream application."	Link
CVE-2017-9022	"strongSwan could be made to crash or hang if it received specially crafted network traffic."	Link
CVE-2017-3211	"... Yopify, a notification plugin for a variety of e-commerce platforms, leaks the first name, last initial, city, and recent purchase data of customers, all without user authorization ..."	Link
CVE-2017-2637	"A design flaw issue was found in the Red Hat OpenStack Platform director use of TripleO to enable libvirtd-based live migration ... Anyone able to make a TCP connection to any compute host IP addresses ... that have been exposed beyond the management interface, could use this to ... gain control of virtual machine instances or possibly take over the host."	Link

Which of these will turn into the next vulnerability that affects you or your company?

Our analysis of emerging vulnerabilities illustrates the importance of a comprehensive approach to gathering information about new vulnerabilities. There is no way that an individual can independently monitor the entire collection of relevant sources. Also clear is that the adversary community is looking at the same original sources as security professionals and picking and choosing the best vulnerabilities to work on. Many of their efforts can be observed and used to help prioritize action for VRM teams.