Skip to content

October attack data: The Expression Language injection attacks that skipped past SAST/DAST/WAFs

By Lisa Vaas, Senior Content Marketing Manager, Contrast Security

November 6, 2024

    
October attack data: The Expression Language injection attacks that skipped past SAST/DAST/WAFs

Today we’re taking a deep dive into Contrast Security’s Application Detection and Response (ADR) data for the month of October 2024, with a special focus on one of the world’s most dangerous attack vectors, Expression Language (EL) injection. You can find the numbers, broken down by attack types, below.

The Equifax breach

You might remember this one from its starring role in one of the biggest data breaches in history: the Equifax breach. The breach affected 159 million people’s data. Equifax agreed to pay up to $425 million to help consumers recover — a chunk of money above and beyond its remediation costs, estimated at $337 million to improve technology and data security and to pay legal and computer forensic fees, among other direct costs.

The breach dates to 2017. With a date like that, it sounds like old news. Unfortunately, it's not. Every day, attackers try to exploit the same type of web application vulnerabilities implicated in the Equifax breach. We know, because Contrast catches attackers who’ve already slipped their attacks past all traditional defenses, including web application firewalls (WAFs). 

When we talk about the type of vulnerability implicated in Equifax, we’re talking about Object-Graph Navigation Language (OGNL) EL injection, the focus of this month’s attack numbers report. We’ll get into how these simple attacks work and how you can stop them, but first, here’s a quick overview of Contrast Application Detection and Response (ADR), followed by the October numbers.

What is Contrast ADR?

If you think of your systems as a bank, traditional defenses are like guards defending the perimeter. Attackers are constantly trying to get past the guards by impersonating legitimate bank customers. Unfortunately, the guards don’t know what they’re protecting or what real customers actually look like. They overreact to anything that looks like it might be an attacker. 

To continue the analogy, Contrast, and the data below, is based on cameras inside the bank, inside the vault, constantly monitoring people and anything they carry into the bank. Contrast only sees the people that make it past the fences and guards. Contrast detects when people’s behavior is clearly a real attack, like pulling a gun, taking money from the vault, etc. ... This confirmed exploitability means that Contrast only flags and prevents real attempts to exploit real vulnerabilities.

October 2024 attacks detected by Contrast ADR

In the last 30 days, the average app/application programming interface (API) protected by Contrast ADR experienced over 3,100 attacks. All of these attacks bypassed existing web application perimeter protections. In that time period, the average app/API experienced over 3,100 attacks.

Of these attacks, the vast majority are what we call probes — harmless attack attempts that blindly target an app/API and never connect with their corresponding vulnerability. It’s absolutely critical to distinguish between probes and real attacks.

For example, imagine an EL attack that never gets anywhere near the code that actually evaluates expressions — that’s a probe. They’re interesting, because you want to know who’s attacking you, but they’re obviously not dangerous. Perimeter detection technologies like WAFs and API security products often flag probes as critical attacks, creating false alerts and preventing apps/APIs from working correctly.

The first chart shows these probes. The average app/API received 4,110 probes in October. That’s a significant number of attacks. You can see that path traversal is a clear attacker favorite, comprising 82% of probes. Command injection (364 per month) and SQL injection (178 per month) are next.

Read more about path traversal, one of the gnarliest attacks

Remember, most of these attacks never reach the corresponding vulnerability and can be safely ignored.

The second chart is even more interesting. These are the attacks that make it through the app/API and actually reach the corresponding vulnerability. Overall, these viable attacks are about 1% of the size of the amount of probes. For example, note that despite thousands of path traversal probes, only two per month are actually viable and reach a file access function.

As you can see, cross-site scripting (XSS) and bot attacks are the most prevalent. It’s important to consider the actual consequences of these attacks, and to focus on attacks like SQL injection, untrusted deserialization and EL injection — they’re really the most critical.

These “viable attacks” are extremely dangerous and would have exploited these apps/APIs if Contrast had not been in place. 

As you can see, the average app/API sees about 2.5 probes and 1.4 viable EL attacks per month. That seems pretty low, but let’s investigate why this is actually really serious.

Spotlight on EL injection: ‘Such an elegant attack’

Expression Language injection attacks are easy, nasty and pack a vicious wallop. The Apache Software Foundation implicated these vulnerabilities — specifically, these Apache Struts CVEs — in the Equifax breach.

To understand OGNL and why Contrast Security CTO and Founder Jeff Williams finds these attacks “elegant,” you need to understand EL. The language was intended as an easy way for developers to add code to their user interfaces. It's designed to grab data values and stick them into, say, an HTML page. There are few other uses, but this is the primary use case.

Instead of having to write a lot of code, developers can use a simple syntax, Williams explains: “You can say, ‘Give me the value of the ‘user’ object’s name — we'll grab the user object, pull the name out of it, and then we’ll stick it in the user interface HTML.” 

“Without EL, pulling in that data would take 4-5 lines of code. It was kind of a pain,” says the CTO. “It was ugly, time-consuming, and error-prone.” But EL provides an elegant and concise syntax for the specific task of just grabbing pieces of data and doing simple things with it.

What went wrong?

Unfortunately, the people behind EL engines made them too powerful, Williams says. They made it possible to call functions from within the expression. For example, you could call a function to turn the data into uppercase characters. But there weren’t any limits, so you can also call functions to start processes, create files, connect to databases, etc. ... all from within an expression.

“So, every once in a while, a developer would accidentally include some user-generated data into an expression to be evaluated," Williams elaborates. "This creates the opportunity for an attacker to send in a malicious expression that does dangerous things, such as steal data, install ransomware and attack other systems.”

For example, imagine you could run code on your bank’s website. What would you do with it? Install ransomware? Would you hijack other people's accounts? Would you corrupt their database? Would you use that as a launching point to get to internal bank resources? “All of those are options,” Williams says.

Elegant, dangerous and built into frameworks

Application and API frameworks provide developers with extensive support in creating products quickly. And many of these frameworks include or even rely on EL support. In Java, Struts and Spring are both widely used frameworks, and both have a long history of accidentally exposing EL injection vulnerabilities.

For example, the most critical vulnerabilities on the list of Apache Struts Common Vulnerabilities and Exposures (CVEs) are EL problems. And organizations are still downloading flawed versions of Struts, Spring and other frameworks that rely on expressions. As of December 2023, four in five Apache Struts2 downloads were reportedly for versions featuring the critical vulnerability CVE-2023-50164, rated 9.8 out of 10 in terms of CVSS severity.

With all those vulnerability-packing downloads, it’s small wonder that Contrast ADR saw 3,345 EL attack attempts in October. Every one of those attacks was an attempt to replicate the Equifax disaster. 

How Contrast ADR blocks OGNL vulnerabilities 

Contrast ADR blocks OGNL attacks in two ways: 

1. ADR prevents untrusted data from modifying expressions

Contrast ADR tracks untrusted data to ensure that application code doesn’t evaluate it as an expression. If ADR sees the evaluation of untrusted data, the technology recognizes it as an attack, given that untrusted data should never be evaluated as expressions. ADR flags this attack and delivers it to the security operations center (SOC as an incident. ADR can also automatically stop the evaluation of the malicious expression and prevent the exploit. This approach is highly accurate and only identifies confirmed attacks.

2. ADR creates a sandbox around dangerous functions

However, sources of untrusted data aren’t always straightforward. Sometimes, for example, data might come from a back-end system that, more or less, you trust. For example, the data might come from an API or a database that you picked up from somewhere else, or maybe from a text file: in short, from sources other than a web application user. Preventing all of this data from being used in expressions might break functionality. So, in these cases, Contrast ADR creates a sandbox around the expression evaluation engine to prevent it from doing anything dangerous, such as starting a native process, creating network connections or accessing files. ADR prevents these malicious behaviors and ensures that unsafe expressions aren’t evaluated.

We sliced open a JNDI attack: Check out the anatomy lesson
 to learn how ADR stops these attacks dead. 

ADR actively monitors and analyzes all application behavior in real time, surrounding these dangerous functions with trust boundaries and identifying vulnerabilities and attacks in production. Think of it like installing boundaries into powerful and dangerous functions: These boundaries prevent anomalous behavior. 

Conclusion

Contrast ADR puts in the right checks in all the right places to alert organizations to real vulnerabilities and real attacks, giving them full context and insights into the app/API, threats, architecture and connected systems — all measured directly from running code in production. 

To learn more about how ADR technology can protect your organization from the web app/API attacks attackers lob every day, request a demo of Contrast Security ADR. We’d love to show you its capabilities — in action.

See Contrast ADR for yourself

Read more: 
Lisa Vaas, Senior Content Marketing Manager, Contrast Security

Lisa Vaas, Senior Content Marketing Manager, Contrast Security

Lisa Vaas is a content machine, having spent years churning out reporting and analysis on information security and other flavors of technology. She’s now keeping the content engines revved to help keep secure code flowing at Contrast Security.

Previous

Preparing for PCI DSS v4.0.1, the latest version of PCI
Next

Cybersecurity Insights with Contrast CISO David Lindner | 11/8/24