This blog was co-authored by Eric Rodriguez, Sarah Perkins, and Vishrut Iyengar – NTT AppSec Security Staff.
Spring is upon us, but nothing is growing more rapidly than the vulnerability known colloquially as “Spring4Shell.” This blog post provides a quick recap and some insights into our exploit development and testing process for this Zero-Day Remote Code Execution (RCE) vulnerability. The Spring4Shell vulnerability targets a ubiquitous language and framework, essentially taking aim at a large tech footprint. If this sounds like your development environment, read on.
As detailed in our previous Spring4Shell updates, the RCE vulnerability (CVE 2022-22965) affects Spring MVC and Spring WebFlux applications running on JDC 9+ and can allow attackers to execute malicious code on a remote server via data binding. Spring4Shell shares some similarity to the infamous “Log4Shell” (also known as “Log4j”) vulnerability that surfaced in December 2021. However, Spring4Shell specifically targets applications that are configured to run on Tomcat as a WAR deployment and therefore, the vulnerability is not as widespread as Log4Shell— which was almost universally exploitable.
According to the TIOBE Index, the Java programming language is currently ranked third in popularity but was consistently ranked first throughout the last two decades. As a Java framework, Spring is by far the most popular application architecture because it is open-source, scalable, and offers diverse methods (POJO, AOP, and DI) for developers to flexibly build enterprise applications.
In general, many security products on the market today are utilizing basic, publicly available Spring4Shell proof-of-concept exploits as-is (or slightly altered). Typically, these quick and easy PoCs oversimplify the attack surface and bear little demonstrable link to the vulnerability profile of real-world applications. Customers usually experience a significant number of false-positives and accrue risk with false-negative results with these services.
NTT Application Security solutions take a smarter approach to testing for Spring4Shell, utilizing a variety of tactics across the force continuum to aggressively scan for the vulnerability without interrupting mission-critical processes during the test.
With respect to both pre-production and production environments, there is a unique set of challenges for dynamically testing an RCE against an application. Since Spring4Shell is a Remote Code Execution vulnerability, one might assume we will be injecting remote code and exploiting an executable endpoint on the end users’ server — which would be a very aggressive attack that might cause performance issues with the application.
For functional web applications in pre-production or staging environments, the NTT Application Security team creatively engineered the new Vantage Prevent Spring4Shell (S4S) module to scan for the RCE without damaging the application being tested. This was achieved by designing the S4S module to initialize an attack against the application’s classLoader module by modifying the Tomcat logging variables with the payload of a benign text file. If the remote code attack is successful, meaning the new variables were propagated (i.e., the new text file exists), Vantage Prevent notes the true positive results in the vulnerability report.
So yes, the Vantage Prevent S4S module does write a test.txt file to the running server, but it is to note that this is not an executable endpoint. Although the module could “clean up” after itself by deleting the benign text file after testing, our team chose not to architect the attack in this manner. As a result, this approach avoids any further modifications to the running server than necessary. Customers can directly and specifically test their pre-production applications with our new S4S module through the Vantage Prevent CLI with the command dast-attacker-cli -attack-modules S4S your_file.har.
For live web applications already in production, endpoints are commonly subject to non-related validations of the request where a validation failure is indistinguishable from a vulnerable response.
To solve this dilemma, our Detection Research team went above and beyond the basic PoC exploit and deployed a unique, contextualized dynamic testing solution in Sentinel Dynamic. Our proprietary scan engine composes contextualized requests across the attack surface of a web application in production, effectively triggering fewer non-related validation errors. This contextualized method ensures high efficacy rates with robust test coverage. Users can easily test for Spring4Shell in their application portfolio by logging into Sentinel and selecting from either the ‘Named Zero-Day Vulnerabilities’ or ‘Vulnerability CVE ID’ listed in the drop-down menu.
Accelerating Application Security to the Speed of Modern Development
NTT Application Security is constantly working to help organizations quickly minimize the impact of any potential damage that new vulnerabilities, such as Spring4Shell, can bring forward. By providing a layered approach towards application security, NTT Application Security partners with organizations to support their application security needs, which helps bolster their overall security posture.