The myth of the long-tail vulnerability

Modern-day vulnerability management tends to follow a straightforward procedure. From a high level, this can be summed up in the following steps:

1. Identify the vulnerabilities in your environment
2. Prioritize which vulnerabilities to address
3. Remediate the vulnerabilities

When high-profile vulnerabilities are disclosed, they tend to be prioritized due to concerns that your organization will be hammered with exploit attempts. The general impression is that this malicious activity is highest shortly after disclosure, then decreases as workarounds and patches are applied. The idea is that we eventually reach a critical mass, where enough systems are patched that the exploit is no longer worth attempting.

In this scenario, if we were to graph malicious activity and time, we end up with what is often referred to as a long-tail distribution. Most of the activity occurs early on, then drops off over time to form a long tail. This looks something like the following:

A long tail distribution of exploit attempts sounds reasonable in theory. The window of usefulness for an exploit is widest right after disclosure, then closes over time until bad actors move on to other, more recent vulnerabilities.

But is this how exploitation attempts really play out? Do attackers abandon exploits after a certain stage, moving on to newer and more fruitful vulnerabilities? And if not, how do attackers approach vulnerability exploitation?

Our approach

To answer these questions, we’ll look at Snort data from Cisco Secure Firewall. Many Snort rules protect against the exploitation of vulnerabilities, making this a good data set to examine as we attempt to answer these questions.

We’ll group Snort rules by the CVEs mentioned in the rule documentation, and then look at CVEs that see frequent exploit attempts. Since CVEs are disclosed on different dates, and we’re looking at alerts over time, the specific time frame will vary. In some cases, the disclosure date is earlier than the range our data set covers. While we won’t be able to examine the initial disclosure period for these, we’ll look at a few of these as well for signs of a long tail.

Finally, looking at a count of rule triggers can be misleading—a few organizations can see many alerts for one rule in a short time frame, making the numbers look larger than they are across all orgs. Instead, we’ll look at the percentage of organizations that saw an alert. We’ll then break this out on a month-to-month basis.

Log4J: The 800-pound gorilla

The Log4J vulnerability has dominated our vulnerability metrics since it was disclosed in December 2021. However, looking at the percentage of exploit attempts each month since, there was neither a spike in use right after disclosure, nor a long tail afterwards.

That first month, 27 percent of organizations saw alerts for Log4J. Since then, alerts have neither dropped off nor skyrocketed from one month to the next. The percent of organizations seeing alerts range from 25-34 percent through June 2023, averaging out at 28 percent per month.

Perhaps Log4J is an exception to the rule. It’s an extremely common software component and a very popular target. A better approach might be to look at a lesser-known vulnerability to see how the curve looks.

Spring4Shell: The Log4J that wasn’t

Spring4Shell was disclosed at the end of March 2022. This was a vulnerability in the Spring Java framework that managed to resurrect an older vulnerability in JDK9, which had initially been discovered and patched in 2010. At the time of Spring4Shell’s disclosure there was speculation that this could be the next Log4J, hence the similarity in naming. Such predictions failed to materialize.

We did see a decent amount of Spring4Shell activity immediately after the disclosure, where 23 percent of organizations saw alerts. After this honeymoon period, the percentage did decline. But instead of exhibiting the curve of a long tail, the percentages have remained between 14-19 percent a month.

Keen readers will notice the activity in the graph above that occurs prior to disclosure. These alerts are for rules covering the initial, more-than-a-decade-old Java vulnerability, CVE-2010-1622. This is interesting in two ways:

1. The fact that these rules were still triggering monthly on a 13-year-old vulnerability prior to Spring4Shell’s disclosure provides the first signs of a potential long tail.
2. It turns out that Spring4Shell was so similar to the previous vulnerability that the older Snort rules alerted on it.

Unfortunately, the time frame of our alert data isn’t long enough to say what the initial disclosure phase for CVE-2010-1622 looked like. So since we don’t have enough information here to draw a conclusion, what about other older vulnerabilities that we know were in heavy rotation?

ShellShock: A classic

It’s hard to believe, but the ShellShock vulnerability recently turned nine. By software development standards this qualifies it for senior citizen status, making it a perfect candidate to examine. While we don’t have the initial disclosure phase, activity remains high to this day.

Our data set begins approximately seven years after disclosure, but the percentage of organizations seeing alerts ranges from 12-23 percent. On average across this timeframe, about one in five organizations see ShellShock alerts in a month.

A pattern emerges

While we’ve showcased 3-4 examples here, a pattern does emerge when looking at other vulnerabilities, both old and new. For example, here is CVE-2022-26134, a vulnerability discovered in Atlassian Confluence in June 2022.

Here is ProxyShell, which was initially discovered in August 2021, followed by two more related vulnerabilities in September 2022.

And here is another older, commonly targeted vulnerability in PHPUnit, originally disclosed in June 2017.

Is the long tail wagging the dog?

What emerges from looking at vulnerability alerts over time is that, while there is sometimes an initial spike in usage, they don’t appear to decline to a negligible level. Instead, vulnerabilities stick around for years after their initial disclosure.

So why do old vulnerabilities remain in use? One reason is that many of these exploitation attempts are automated attacks. Bad actors routinely leverage scripts and applications that allow them to quickly run exploit code against a large swaths of IP addresses in the hopes of finding vulnerable machines.

This is further evidenced by looking at the concentration of alerts by organization. In many cases we see sudden spikes in the total number of alerts seen each month. If we break these months down by organization, we regularly see that alerts at one or two organizations are responsible for the spikes.

For example, take a look at the total number of Snort alerts for an arbitrary vulnerability. In this example, December was in line with the months that preceded it. Then in January, the total number of alerts began to grow, peaking in February, before declining back to average levels.

The cause of the sudden spike, highlighted in light blue, is one organization that was hammered by alerts for this vulnerability. The organization saw little-to-no alerts in December before a wave hit that lasted from January through March. It then completely disappeared by April.

This is a common phenomenon seen in overall counts (and why we don’t draw trends from this data alone). This could be the result of automated scans by bad actors. These attackers may have found one such vulnerable system at this organization, then proceeded to hammer it with exploit attempts in the months that followed.

So is the long tail a myth when it comes to vulnerabilities? It certainly appears so—at least when it comes to the types of attacks that target the perimeter of an organization. The public facing applications that reside here present a large attack surface. Public proof-of-concept exploits are often readily available and are relatively easy to fold into attacker’s existing automated exploitation frameworks. There’s little risk for an attacker involved in automated exploit attempts, leaving little incentive to remove exploits once they’ve been added to an attack toolkit.

What is left to explore is whether long-tail vulnerabilities exist in other attack surfaces. The fact is that there are different classes of vulnerabilities that can be leveraged in different ways. We’ll explore more of these facets in the future.

It only takes one

Finding that one vulnerable, public-facing system at an organization is a needle-in-a-haystack operation for attackers, requiring regular scanning to find it. But all it takes is one new system without the latest patches applied to give the attackers an opportunity to gain a foothold.

The silver lining here is that a firewall with an intrusion prevention system, like Cisco Secure Firewall, is designed specifically to prevent successful attacks.  Beyond IPS prevention of these attacks, the recently introduced Cisco Secure Firewall 4200 appliance and 7.4 OS bring enterprise-class performance and a host of new features including SD-WAN, ZTNA, and the ability to detect apps and threats in encrypted traffic without decryption.

Also, if you’re looking for a solution to assist you with vulnerability management, Cisco Vulnerability Management has you covered. Cisco Vulnerability Management equips you with the contextual insight and threat intelligence needed to intercept the next exploit and respond with precision.

We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!

Cisco Secure Social Channels

Instagram
Facebook
Twitter
LinkedIn

Share: