CVE 2022-22965, dubbed SpringShell (rated 9.8 CVSS Score) was found in Java’s Spring Framework. Spring, developed by VMware, is one of the most popular Java application deployment frameworks. On March 31, 2022, SpringShell (first known as Spring4Shell) was originally reported to VMware by multiple sources, and details were leaked online ahead of a public release and the formal CVE publication. Exploitation of this vulnerability allows an unauthenticated attacker to remotely execute arbitrary code on a vulnerable web server.
A server is vulnerable if all of the following conditions are met:
- A Spring MVC or Spring Webflux dependency
- Java applications running JDK 9 or higher
- Apache Tomcat running as the Servlet Container
- Packaged as a traditional Web Application Resource (as opposed to the Spring Boot Executable Java Archive)
- Java Spring Framework running version 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions.
Quick remediations include updating the Spring Framework to 5.3.18 or 5.2.20, wherever applicable. No other workarounds are necessary. For unsupported Spring boot frameworks, upgrading Apache Tomcat to versions 10.0.20, 9.0.62, and 8.5.78 (wherever applicable), provides protection to a degree. However, this is only a temporary tactical fix, as the primary goal should be to upgrade the Spring Boot Framework as soon as possible. Should this avenue be chosen, developers should also consider setting DisallowedFields, thereby disabling data binding, for a defense-in-depth approach. If you are unable to update Spring or the Apache Tomcat instance, downgrading to Java 8 may be a workaround. Notably, these workarounds are not mutually exclusive and should be applied together.
How does this attack work?
Web applications need a way to receive user input and map them to objects for the application to operate on them. Spring’s RequestMapping function provides this mapping of request parameters to data types. The server may be vulnerable if the application attempts to map request parameters to Plain Old Java Objects. This poses a security issue because, once a malicious request parameter is supplied with an unexpected object, Spring would attempt to map it to an appropriate object type. If this happens, an attacker can use Request Handler to dump out the class information. From there, they can manipulate other attributes of a class through its properties. In this case, Code Execution was achieved by accessing classes that execute arbitrary commands supplied with user input.
While the full extent of its criticality and impact is still being researched, the SpringShell vulnerability is currently not as critical as Log4Shell. There are certain conditions that need to be met beforehand, and the attack replication requires knowledge in Java and of the application itself to develop a proof of concept or working exploit. Additionally, current research demonstrates that the application needs to be run as a WAR file and not the default deployment of a Spring Boot Executable JAR file; however, the team maintaining the Spring Framework caveat this statement by saying: “the nature of the vulnerability is more general, and there may be more ways to exploit it.”
Lunasec has a technical writeup on the specifics of the PoC’s that are currently circulating.
To learn more about our cybersecurity consulting practice, contact us.
