New Vulnerability in Spring Framework Detected
A new vulnerability, dubbed SpringShell in Spring Framework, was recently discovered.
SpringShell was given a CVE ID of CVE-2022-22965, and results in Remote Code Execution (RCE) upon successful exploitation, compromising the web server and putting it under the attacker’s control. It affects Spring Framework versions 5.3.17/5.2.19 and lower (it was patched in versions 5.3.18/5.2.20).
AppScan users can detect this vulnerability both via AppScan’s SCA offering, and with the latest version of AppScan’s DAST engine.
Exploitation Prerequisites
While the issue itself is with Spring Framework, successfully exploiting it requires several additional prerequisites:
- Application deployed as an Apache Tomcat servlet, packaged as a WAR executable
- Running on JDK 9 or later
- Dependency on spring-webmvc or spring-webflux
Root Cause Analysis
Spring Framework is an application framework that is widely used for development of web applications. Among its many features is data binding, that greatly simplifies a developer’s workflow when dealing with request handlers. Whereas with regular request handlers a developer must parse information from request parameters, Spring’s data binding feature automatically binds request parameter values to corresponding arguments in the request handler’s code, based on their names. This greatly simplifies the code and makes it more readable.
However, this data binding feature happens to have a bug. The implementation code unintentionally exposes a sensitive property named class (that points to the class of the object being bound), that can be abused to bind the request parameter values to fields of arbitrary objects in memory. It’s a kind of a high-level write-what-where primitive in Java. And while that does not enable code execution immediately, using this vulnerability to modify some carefully selected fields results in arbitrary code execution.
Exploitation via Tomcat Logging
The exploit abuses Apache Tomcat’s logging facilities, namely, an instance of the AccessLogValve class. There are multiple fields in that class that define Tomcat’s logging behavior, and the following fields are of interest:
- prefix – the prefix that is added to log file filenames
- suffix – the suffix that is added to log file filenames
- pattern – the pattern used to format our access log lines
- directory – the directory in which we create log files
- fileDateFormat – date format to place in log file name
By changing those fields using the write-what-where primitive, it is possible to achieve arbitrary code execution on the server:
- Update the directory field to cause Tomcat to create the log files in a web application directory accessible via the web (such as Tomcat’s default webroot folder)
- Update the prefix and suffix fields to effectively set the log’s filename to something with a .jsp extension
- Set the fileDateFormat field to empty, so that prefix and suffix define the actual filename
- Set the pattern field to contain malicious JSP code that performs code execution
Once the above steps are complete, the attacker must wait for Tomcat to log something (or trigger a logging event by accessing a page on the website), and the malicious JSP file will be created and ready for access.
Mitigation
Although the above exploitation technique depends on multiple prerequisites, it is possible that new methods will be found, that will work in broader cases. Therefore, the proper fix to the problem is to update the Spring Framework used to a patched version (either 5.3.18 or 5.2.20, depending on whether Spring Framework 5.3.or 5.2 is used).
