Ditch your setlist: Zero-day partiers are already rocking your system

Zero-day exploits are on the rise, and the way you’re trying to handle them isn’t working. 

If you’re only finding them when they’re announced, you’re late to the party: The attackers are already using them to try to pick apart your systems. 

We have a different — and better — approach. We believe in finding vulnerabilities before they’re discovered and reported, let alone before exploit code is released. To do that,  you’ve got to set up your apps with the protection they need so that unknown zero days can’t be exploited. 

But before we explore that approach, let’s first look at why the current crop of tools are shredding your systems instead of stopping  the quickening onslaught of zero days. 

Why old-school tools won’t help

The three main tools in Application Security (AppSec) are Static Application Security Testing (SAST), scanning, Software Composition Analysis (SCA) and Web Application Firewalls (WAFs). However, none of these work well against the zero-day vulnerabilities we just described. Here’s why:

1. SAST scanners are generally run only on the code you write. They do not run against your open-source code. 
2. SCA tools work off databases of known vulnerabilities (e.g., the CVE database). That means that you receive no protection before the vulnerability is disclosed. 
3. WAFs work on exploit signatures. Those signatures didn’t work at all against recent exploits of zero days. Furthermore, when vendors issue new signature updates, within hours, the hacker community writes new exploits that sneak around those protections. 

These outmoded security tools can’t keep up with the shrinking time between major zero-day events, which used to be measured in years but which has now shriveled to what feels like every few weeks. 

One example: The Struts vulnerability that impacted Equifax was discovered way back in 2017. However, the time between Log4j and Spring4Shell was only a couple of months — and those are far from the only incidents we’ve seen. For example, in June 2022, Atlassian discovered a remote-code execution (RCE) vulnerability (CVE-2022-26134) affecting all on-premises versions of Confluence Server and Confluence Data Center. The day after it was discovered on June 2, public exploit code was released. And just last month, Contrast researcher Joseph Beeton discovered CVE-2022-4116, a highly dangerous zero-day flaw in the popular Quarkus Java framework. 

Why has the hunt sped up?

There are a few reasons for the rapid acceleration of zero days, one being that hackers have come to understand that there are incredibly large pay-offs from finding open-source zero-day vulnerabilities. Log4j is a perfect example: That single vulnerability left millions of applications vulnerable to a wide range of exploits. I think we’ll be assessing the damage from Log4j for a long time and likely will never know the full extent of the impact. 

What we do know: Our platform data shows that one year after the Log4j vulnerability was found in December 2021, in spite of organizations spending weeks to hunt down and fix their Log4j libraries, only 50% have upgraded to a fully fixed version of Log4j. Many are still exposed to the potential for breach. 

Some of the ecosystems, like Java, are quite old at this point. I should know: I started working on the Java team at Sun Microsystems 26 years ago! Log4j is a library with more than 20 years of version history, and it’s entirely maintained by volunteers. When you look at it, you realize that many fundamental assumptions in these libraries were made many years ago — often when developers knew less about building secure code than developers do today — and changes have been made to them since. 

You can see why that matters: It means that older libraries, with more vulnerabilities, have the widest deployments. Hackers are now clearly looking at older, highly deployed parts of open-source ecosystems where a chink in the armor can have massive repercussions.

How long before the bad guys come knocking? 

You well may ask, How quickly are the bad guys exploiting those vulnerabilities? Do you have days before they start using them to pry open your systems? … Weeks? Months? 

The bad news: It’s far worse than that. When Log4j happened in December 2021, our customers were protected. Our runtime protection for applications stopped Log4j attacks in their tracks immediately, without a need to update or patch. We didn’t have to know about the Log4j zero day because we protect against full classes of generic exploits or things like log injection and deserialization vulnerabilities — the vulnerabilities associated with Log4j. 

With Log4j, we were able to rewind our telemetry on customers’ applications and see that hackers were already trying to exploit that vulnerability more than two weeks before it was announced to the public. 

Bear in mind that open-source communities, such as the one behind the Log4j library, are full of lots of different characters. From the time that zero days are first exposed by a researcher or ethical hacker until the time that they're patched, there can be a lot of exposure. If you wait for the zero-day announcement, you're already way behind. 

There’s a better way to stop zero days

Depending on traditional SCA tools as your sole line of defense against open-source zero-day attacks is extremely dangerous. As an industry, we need to ramp up just as fast as — faster would be better still — the adversaries who are creating these zero days. That means investing in new, modern AppSec tools such as Runtime Application Protection (aka Runtime Application Self-Protection, or RASP) and Interactive Application Security Testing (IAST). 

When it comes to zero days, runtime protection is your rockstar. Runtime Application Protection has been around for many years but has really shown its value with this ramp-up in zero days. Built into an application or application runtime environment, the technology can actually control application execution, detect  vulnerabilities and thereby stop attacks in real time, regardless of where the app resides on the server.

Runtime protection automatically establishes trust boundaries inside the application. In this way, with very little performance overhead, it ensures that many of the important classes of vulnerabilities cannot be exploited. It validates data requests directly inside the app and improves overall AppSec by monitoring inputs and blocking those that could allow attacks, while also protecting the runtime environment from unwanted changes and tampering. 

Essentially, RASP modifies your app structure instantly and transparently to ensure that your app is using safe coding patterns. It gives unprecedented visibility and protection, blocking attacks quickly and effectively until the underlying vulnerabilities can be addressed.

With each of these major zero-day attacks, runtime protection tools were able to stop exploits cold, with no signature updates required. Not only were these runtime tools protecting against zero days; they were also protecting well before the vulnerabilities were disclosed. With the CVE-2022-26134 Atlassian vulnerability (just like with CVE-2021-26084 [PDF] before it), Contrast Protect automatically spotted and blocked malicious attacks, right out of the box. 

IAST tools are another major player when it comes to preventing zero days: They  actually showed log injection vulnerabilities in the affected apps months or years prior to the disclosure of Log4j. That information empowered developers, who used the data to prevent the problem with some simple, defensive coding techniques. IAST can do that because it evaluates the whole application at once, instead of separating custom code from open source, as do SAST and SCA. 

These tools let Contrast customers sleep at night. They feel more secure because they are more secure. They’re  getting better security outcomes because their risk has been slashed. It’s an advantage they sorely need, given that zero days are on steroids at this point. 

You can’t wait around for disclosure to start setting up your defenses. You need to stop these zero days in their tracks. To do that, you need tools that look at the whole app and that stop bad actors before they start. 

Click here to book a demo for the Contrast platform.