Summary
Spring4Shell (CVE-2022-22965) or the remote code execution vulnerability found in Spring Core Framework was observed and confirmed in March of 2022. Spring Framework is an open-source application framework, used for the development of Java-based applications, essentially aiming to help developers build applications more quickly. The vulnerability was initially discovered by an unnamed researcher who wrote about the potentially unpatched RCE vulnerability and published a proof-of-concept that was later confirmed as a zero-day.
The severity of Spring4Shell has been labeled as critical; and the vulnerable include versions of the spring framework that are less than or equal to 5.3.17 and Spring MVC and Spring WebFlux applications running JDK 9+ – as well as the application running on Apache Tomcat as the Servlet container. It has been observed to allow an actor to exploit and gain the ability to execute unauthenticated remote code on a vulnerable system. This is achieved by the actor dropping a web shell onto the affected host, and then executing arbitrary code with the Tomcat owner’s user rights. Although there are specific conditions that need to be met in order for the vulnerability to be exploited, the potential severity and impact that Spring4Shell could have on an environment is enough to mediate and confirm.
Synopsis
The Discovery of Spring4Shell or CVE-2022-22965 in March 2022 almost immediately created a stir throughout the industry, as cyber security teams rushed to find out its behavior and if they were vulnerable – with the shadow of Log4Shell’s impact lingering, due to it occurring so recently in December 2021. The vulnerability allows Remote Code Execution via a malicious/crafted HTTP request to a vulnerable server. Researchers at Praetorian confirmed that Spring4Shell is a patch bypass of CVE-2010-1622 (via Tenable: https://www.tenable.com/blog/spring4shell-faq-spring-framework-remote-code-execution- vulnerability), which was supposed to patch a code injection vulnerability in the Spring Core Framework, but was actually incomplete.
The vulnerability targets a weakness that allows Class Loader Manipulations attacks when @RequestMapping is being utilized with a request, allowing Plain Old Java Object (POJO) parameters to be passed. From here, actors can execute a malicious class loading payload and drop a web shell (for example) onto the affected host and execute malicious/arbitrary code on the server with the privileges of the user running Tomcat in this situation. Although the exploitation is straightforward, in order for the exploit to be most effective it will require the attacker to do additional research on the victim’s configurations.
It should be noted that the vulnerability has only been observed exploiting hosts with specific configurations as of this time; conditions such as DataBinder being enabled, the application running Tomcat as a WAR deployment, Spring MVC and Spring WebFlux applications running and Spring framework/JDK versions lining up. Although this makes it less “panic inducing” as Log4Shell was when it was released, it doesn’t take away from the potential impact if your environment meets the conditions and is vulnerable.
Further mitigation and updates can be found in Rapid7’s detailed blog found here: https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring- framework
