Spring4Shell: What you need to know

Understand your Spring4Shell risk

A remote code execution vulnerability identified as CVE-2022-22965 was confirmed in the Spring Framework, the most popular Java framework used to build server-side apps. Not to be confused with CVE-2022-22963 (a different RCE affecting Spring Cloud Functions that surfaced at roughly the same time), this new RCE is being discussed under the name “Spring4Shell.” While the Spring4Shell vulnerability is serious and absolutely needs patching, the current exploits circulating rely on criteria that are not the defaults for most modern Spring applications. Log4Shell, by comparison, also affected the Java ecosystem but was more widely exploitable.

Patches and additional information from Spring are provided here. As always, it is a good idea to patch these vulnerabilities, but a key first step is determining the level of risk for your organization. 

The first question that organizations should ask is: Do I run my Java Spring Boot web applications as a standalone app? (i.e. using a command like java -jar myspring-boot-app-1.0.1.jar). If the answer is yes, the currently circulating exploits are not applicable. These exploits rely on the ability to manipulate the class loader used when running in a Tomcat servlet container which is different from the more limited class loader used in a standalone app. That said, organizations should still make a plan to patch as per standard best practices – the underlying issue is still present and could be exploited in as yet undiscovered ways. 

The Invicti security team is working on custom security checks to ensure our customers’ web applications mitigate the potential risk of the circulating Spring4Shell vulnerability and take appropriate action if necessary. We have also confirmed that our products do not use the Spring framework and are not directly affected. We will continue to post here as we learn more about Spring4Shell, and as the Spring4Shell security checks in Invicti and Acunetix are released.

UPDATE: A Check For Spring4Shell Is Now Available In Acunetix Premium
If you are using Acunetix on-premises, update your Acunetix installation to the latest version (build 14.7.220401065 or later) and scan all your web assets. If you are using Acunetix online, simply scan all your web assets at your earliest convenience.

UPDATE: A Check For Spring4Shell Is Now Available In Invicti Standard
Invicti Standard version 6.4.3.35616 now includes a check for Spring4Shell and can be used to scan all your web assets. 

UPDATE: A Check For Spring4Shell Is Now Available In On-Demand Versions of Invicti Enterprise and Acunetix 360
On-Demand versions of Invicti Enterprise and Acunetix 360 now include a check for Spring4Shell and can be used to scan all your web assets. 

UPDATE: A Check For Spring4Shell Is Now Available In On-Demand Versions of Invicti Enterprise and Acunetix 360
If you are an Invicti Enterprise or Acunetix 360 On-Premises customer, please update your installation to the latest version (build 2.2.4 or later) and scan all your web assets.

How the new security check works

The Spring framework has a data-binding feature that automatically sets the values for fields in a Plain Old Java Object (POJO), that is used as an input to a Spring controller’s handler method. Data binding automatically maps fields like name or address in a Person object to the corresponding fields in a form. All classes in Java have a special class field inherited from Java’s standard java.lang.Object class. This can obtain access to the classLoader, a generic class responsible for loading the actual class files used by the Java Virtual Machine (JVM).

If fields unrelated to the class’s business-level fields are accessible, such as the class field, there is an opportunity for manipulation which can have unintended side effects. This data-binding issue is an old one, with older exploits accessing class.classLoader to perform malicious attacks and modify state outside the POJO. Java 9 introduced class.module.classLoader as an inherited field, allowing attacks to evade previous specific blocklists that only targeted class.classLoader.

The currently circulating RCE exploit abuses these additional classLoader properties to direct the Tomcat servlet container’s WebAppClassLoader (not the LaunchedURLClassLoader used when using an embedded servlet) to redirect logs to a file within the webroot. These logs are then carefully used to create a Java Server Page (.jsp) file that functions as a webshell, executing any command passed to it as a child process. If they are in a good mood, the attacker will only launch a calculator – but likely it will be something far more nefarious.

The newly introduced Spring4Shell security checks in Invicti and Acunetix products use a non-intrusive technique that cannot modify the remote file system in any way. It works by submitting HTTP POST requests with form data that attempts to get server-side data-binding code to alter a classLoader field. The new check s series of values that tries to overwrite class.module.classLoader.URLs and cause a parse error (and only a parse error) in the app using the vulnerable module. The request uses invalid values for the property that do not result in any network requests associated with class loading from the target, which minimizes the risks of changing the server-side state.

Invicti’s security team members are also looking at Spring Cloud Function and more extensive checks.