Skip to content

August attack data: A look beyond the numbers

By Lisa Vaas, Senior Content Marketing Manager, Contrast Security

September 17, 2024

Log4j application attacks path traversal ADR XSS method tampering unsafe deserialization EL injection Log4Shell insecure deserialization

    
August attack data: A look beyond the numbers

The Contrast Security Runtime Security Platform — the engine that underpins Contrast’s Application Detection and Response (ADR) technology — blocked approximately 47K cybersecurity attacks during the month of August 2024. 

It’s a big number. But the thing is, size doesn’t matter. 

Rather, it’s the attack sophistication that matters. While any web application firewall (WAF) or content delivery network (CDN) worth its salt should, technically, stop XSS, we are noticing more and more scenarios where these tools are not configured correctly. The modern versions of these technologies should be able to handle the incessant pitter-patter of XSS, as, of course, can Contrast ADR.

What really matters is blocking the subtle attacks: the ones that don’t get as much attention and aren’t as prevalent, but which can cause a lot more damage, given that current tools are ill-equipped at spotting and stopping them. 

WAFs can’t reliably detect these attacks; they’re best complemented by Runtime Application Self Protection (RASP) for deeper protection. 

In this article, we’ll look at the most frequent attacks ADR blocked in August, including both the low-hanging fruit as well as the slippery fish that infiltrate targets via holes in traditional security stacks. We’ll delve into how ADR responds to one such attack — Log4j — and tease out three of the most impressive takeaways from the numbers. 

First up, the big-number attacks:

The Top 4 blocked attacks

These are the Top 4 types of cyberattacks Contrast detected during August 2024: 

No. 1: XSS — 21,444 attacks blocked 

In XSS attacks, threat actors hijack vulnerable applications by inserting malicious scripts into a user’s interactions with the app. An XSS attack targets the scripts running behind a webpage that are being executed on the client-side (in the user’s web browser). Because the unsuspecting browser has no way of knowing that a script shouldn’t be trusted, it will go ahead and execute the XSS script, which can access cookies, session tokens and other sensitive information retained by the browser and used with that site. In short, XSS allows the attacker to commandeer HTML pages, deceive users and steal sensitive data as it assumes control, redirects links and rewrites content on that site.

Contrast Security’s work has shown that 80% of applications have at least one XSS security vulnerability: a stunning finding for a problem that’s been on the OWASP Top 10 list for over a decade.

Recent example of an XSS attack

Between November and December 2023, a threat group tracked as ResumeLooters used XSS scripts to inject phishing forms into at least four legitimate job search websites. Between exploiting XSS vulnerabilities and launching SQL injection attacks against at least 65 websites, the group stole databases containing close to 2.2 million rows, more than 500,000 of which represented user data from employment websites.

Read the white paper: The Case for ADR

No. 2: Method tampering — 5,323 attacks blocked

The second most-blocked attack in August was method tampering (aka verb tampering or HTTP method tampering). Method tampering is an attack against authentication or authorization systems that have implicit "allow all" settings in their security configuration. This type of attack takes advantage of vulnerabilities in HTTP verb authentication (also known as HTTP method authentication) and access control mechanisms.

HTTP provides a list of methods that can be used to perform specific actions. In the list of HTTP methods, GET and POST are most commonly used by developers to access information provided by a web server. But HTTP also provides several other methods and many of these can pose a critical security risk for a web application, as they allow an attacker to modify the files stored on the web server, delete a web page on the server and upload a web shell to the server, which can lead to the theft of user credentials.

No. 3: Path traversal — 5,057 attacks blocked

Path traversal, also known as directory traversal, comes in at No. 3 on the attacks-blocked list for August. These attacks entail exploitation of an affected application to gain unauthorized access to server file system folders that are higher in the directory hierarchy than the web root folder. A successful path traversal attack can fool a web application into reading and consequently exposing the contents of files outside of the document root directory of the application or the web server, including credentials for back-end systems, application code and data, and sensitive operating system files.

If successful, a path traversal attack can lead to the following risks:

  • Unauthorized data access: Attackers can gain access to sensitive files, such as configuration files, system files, or source code, which may contain credentials for back-end systems, application code and data, and sensitive operating system files.
  • Data exfiltration: Attackers may be able to steal sensitive information, leading to data breaches and potential financial or reputational damage.
  • Remote code execution: In some cases, path traversal vulnerabilities can be combined with other security weaknesses to allow attackers to execute arbitrary code on the server, potentially leading to complete system compromise.

Recent example of a path-traversal attack

June 2024 saw active exploitation of a high-severity, trivially exploited path-traversal flaw in the SolarWinds Serv-U Managed File Transfer Server. At the time, Contrast Security Senior Director of Product Security Naomi Buckwalter noted the potential for the vulnerability to function as a gateway for further attacks. 

No. 4: JNDI injection (Log4Shell) — 4,611 attacks blocked 

Coming in at No. 4 is Java Naming and Directory Interface (JNDI) injection. JNDI is a simple Java API that allows clients to discover and look up data and objects via a name: “Simple,” as in, it takes just one string parameter. If that parameter comes from an untrusted source, an attacker can gain remote-code execution (RCE).

Recent example of a JNDI injection attack

In November 2021, the Log4j JNDI vulnerability, which researchers dubbed Log4Shell, was discovered and rapidly exploited. The critical zero-day vulnerability — CVE-2021-44228 — allowed an attacker to use the logging framework Log4j and the lookup feature JNDI within an application to generate special requests to an attacker-controlled server, from which the threat attackers downloaded malicious code into systems, gained access to perform RCE and breached targets without authorization. 

Three years after the Log4j vulnerability was discovered in late 2021, Log4j is still among the top exploited vulnerabilities, according to Contrast’s research and findings from other research labs.

One year after Log4Shell, firms were still struggling to hunt down Log4j

Those are the top attacks by number. Now, let’s take a look at the more subtle attacks.

The attacks that old-school tools can’t catch

The attacks that can be missed by tooling such as WAFs include any type of injection attack, such as: 

None can reliably be intercepted by WAFs. This is where Contrast ADR comes in. It not only handles the obvious stuff (like XSS); it also covers all of the additional blindspots that those sophisticated attacks slip through, giving comprehensive visibility into the application layer that a WAF can only dream of. ADR’s underlying technology, Contrast Runtime Security, is real-time, always-on security for applications and application programming interfaces (APIs) that prevents insecure programming during development and then detects and responds to exploits in production. 

Why WAFs struggle to stop these slippery fish

Answering SecOps’ ‘So what?’ 

All this talk of attack types tends to make security analysts’ eyes glaze over. We know you just want answers to these questions: 

  • What vulnerability exists in the code? 
  • Is someone actively trying to exploit it? 
  • Do I have the data that prove that? 
  • If I have the data, what do I do about it? Keep reading this article, or drop everything and go do something about it? 

ADR has the answers. Contrast Assess — our Interactive Application Security Testing (IAST) solution — continuously detects and prioritizes vulnerabilities. ADR reports which applications are being attacked in production. ADR enables SecOps to tie those pieces together, down to the exact line of code. It detects whether a vulnerability is actively being exploited. If it is, you need to respond, and ADR gives you the playbook so that you know how. 

Regardless of the event type, when ADR detects a vulnerability, threat, incident or attack, it alerts the SOC with full context regarding exactly what happened. This full context gives a security analyst everything they need in order to determine whether the alert matters and, if so, how to drive triage response. 

Now, let’s examine how ADR reports and responds to security events. 

ADR in action: Blocking JNDI injection

Below is an example of one type of ADR event: In this case, a detected JNDI injection: specifically, Log4Shell. As you can see in these screenshots, ADR has detected a JNDI injection and has requested a block on the event:

A view of the details screen in that same alert:

How does ADR respond to web attacks? 


ADR response to a Log4Shell attack

ADR’s response to a JNDI injection attack (such as Log4Shell) exemplifies how the technology responds when it detects exploitation attempts. In the case of Log4Shell, ADR triggers the following, comprehensive response — a response that aligns with the NIST Cybersecurity Framework:

Identification

  • ADR uses runtime Contrast Software Composition Analysis (SCA) to continuously map and inventory the application layer to identify vulnerable Log4j instances.
  • ADR monitors the attack attempt in real time, giving visibility into the app’s behavior and data flow throughout. 

Protection

  • When set to Protect mode, ADR automatically stops the initial JNDI lookup to the malicious server.
  • ADR reduces attack surface by boosting JVM security settings to limit JNDI capabilities.

Detection

  • ADR identifies the JNDI lookup attempt to the infected Lightweight Directory Access Protocol (LDAP) server and alerts security analysts.
  • The attack’s attempts to execute malicious EL payloads are detected.
  • ADR monitors for unauthorized Java class loading and execution.
  • Identifies suspicious process executions that indicate command injection.

Response

  • Triggers use of predefined playbooks for Log4Shell incidents.
  • Enhanced triaging context includes detailed attack chain analysis and affected application components.
  • ADR integrates with security information and event management (SIEM)/extended detection and response (XDR) systems, serving up enriched alerts that contain application-layer context for more effective incident analysis.

Recovery

  • Detailed forensic data about the attack attempt supports incident investigation.
  • Helps to identify the full extent of potential compromise across the application portfolio.
  • Improves detection and protection capabilities with post-incident analysis.
  • Data supports root cause analysis to help prevent similar future incidents.

Throughout this response, the ADR system maintains continuous monitoring, provides real-time updates to security dashboards, and supports compliance reporting by documenting all detection and response actions.

The takeaways

Besides the number of blocked attacks for August, we promised some takeaways. Of course, there are many insights you can distill from a number as big as 47K blocked attacks. The three biggest takeaways: 

  1. We’re still bad at code quality. If the vulnerabilities weren’t there to begin with, we wouldn’t see all these exploit attempts. 
  2. Log4j is still gnawing at our systems. It’s been three years. What’s going on?
  3. We’re still seeing JNDI injection attacks: the Log4j vulnerability dubbed Log4Shell that clobbered us three years ago. We still haven’t figured it out as an industry.  

“From our analysis, we could still see JNDI traffic coming in. That means it's still exploitable, people,” warns Contrast Security Director of Product Security Naomi Buckwalter. 

To see how Contrast ADR can improve your ability to detect and respond to real-time AppSec attacks like Log4Shell, you can request an ADR demo today. 

Get a Demo

Read more:
Log4j application attacks path traversal ADR XSS method tampering unsafe deserialization EL injection Log4Shell insecure deserialization
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

Cybersecurity Insights with Contrast CISO David Lindner | 09/13/24
Next

Cybersecurity Insights with Contrast CISO David Lindner | 09/20/24