Spring4Shell Zero-Day Vulnerability: While You’re Waiting for Your WAF

Spring4Shell CVE-2022-22965

A newly disclosed remote code execution vulnerability in Spring Core, a widely used Java framework, has been identified. Exploitation of CVE-2022-22965 has been confirmed as a means of enabling unauthenticated remote code execution on applications.

Similar to the recent zero-day vulnerability identified with Log4j CVE-2021-44228, and other events including Heartbleed and Shellshock from the prior decade, the effects on the cybersecurity industry has been felt as new open-source vulnerabilities continue to be identified. These events require organizations to scramble in order to determine the potential impact of the vulnerability within their company and subsequently identify the quickest path for remediation.

While the full extent of Spring4Shell isn’t fully understood as of yet, it doesn’t appear to have the same level of widespread impact as the recent Log4j event. But for those organizations that are impacted, it represents an attack surface that’s challenging to defend against until software patches or firewall rules are made available.

 

Automated Scans to Exploit Spring4Shell

As Kasada researchers observed with Log4j, adversaries quickly leverage the scale gained from automated vulnerability scanner tools to test thousands of URLs to identify which systems haven’t been patched and make for an easy target. Spring4Shell is no exception. Once the zero-day was public on Wednesday March 30th, Kasada quickly detected automated exploit attempts against several of our customers. 

 

The figure above shows the volume of automated Spring4Shell exploitation attempts across Kasada customers immediately following its discovery.

 

Detecting Malicious Scanners

Kasada has deep expertise in detecting the presence of automation. Kasada’s invisible, client-side interrogation methods for automation detection actively blocks malicious vulnerability scanners aimed towards exploiting zero day vulnerabilities like Spring4Shell – in real-time without requiring specific knowledge of the vulnerability itself.

Being able to reduce the risk during the “scan-to-exploit” phase of a zero-day vulnerability event is critical as there are limited options available until software and firewall patches are made available that are specific to the application.

 

Summary

Applying application-agnostic defenses that are able to detect and stop automated threats, in real-time, serves as an important defense layer when used in concert with Web Application Firewall (WAF) rule updates and application software upgrades. 

As recently learned during Log4j, and now Spring4Shell, a layer of online defense against malicious scanning tools helps businesses better prepare for the initial scan-to-exploit phase of a zero-day event before the vulnerability can be contained through patching. Thus reducing the overall risk exposure to such events.

*** This is a Security Bloggers Network syndicated blog from Kasada authored by Neil Cohen. Read the original post at: https://www.kasada.io/spring4shell-zero-day-vulnerability-waf/