Juan Pablo Tosso
Overview
On March 29, 2022 the world became aware of a new zero-day vulnerability in the Spring Core Java framework, dubbed ‘Spring4Shell’, which allows unauthenticated remote code execution on vulnerable applications using ClassLoader access. Since then, a CVE has been created to this vulnerability (CVE-2022–22965).
Although the names are familiar, Spring4shell is NOT as bad a vulnerability as Log4shell. This is because exploiting Spring4shell requires certain pre-requisites to be in place first, as opposed to Log4Shell which made everyone simply using the Log4J library (a widely-used library) exploitable.
What is Spring Framework?
Spring is a popular Java application framework used by most enterprise Java applications that allows software developers to quickly and easily develop applications with enterprise-level features. Spring Core is a primary and required package of the Spring Framework. Applications based on Spring can be deployed on servers, such as Apache Tomcat, as stand-alone packages with all the required dependencies.
What is Spring4Shell?
This Spring4Shell vulnerability relies on the form to model de-serialization feature that uses data binders to create spring models.
This vulnerability is hard to exploit because it requires an attacker to find compatible “java gadgets” which contain characteristics that would allow the attacker to evaluate code, write files, or more. The most common current attack vector uses the widely exploited 2014 gadget that consumes the Tomcat logging properties class loader.
Data binding allows the developers to dynamically bind the user input to the domain model of an application. For example, the following URL-encoded request body can be bound to the Login class:
Request body
username=user&password=passwordLogin Model
Gadgets
A gadget is a class or function that has already existing executable code present in the vulnerable process. This existing executable code can be reused for malicious purposes. (From https://frohoff.github.io/appseccali-marshalling-pickles/)
To exploit a gadget, an attacker needs access to some deserialization vulnerability.
Gadget Chain
A gadget chain is a sequence of gadgets that can be used to exploit some vulnerable code. For Spring4Shell our first gadget is the data binder. After confirming this gadget we need to use a second gadget, like Tomcat Logger properties, create malicious actions like code execution.
Some examples of gadgets
Internal model SQL Injection gadget
If some model is using its name as a static variable and not a constant, you could be able to update the model name and create a persistent SQL injection by changing com.some.sample.model.name = “model” to another model with similar functions but vulnerable to SQL Injection. The author may have left the model class vulnerable considering it is internal and cannot be exploited. The attacker has now used the SQL Injection vulnerability as part of his Gadget chain for exploitation. . Each time a user invokes the model, the vulnerable code will be evaluated and the user input flowing in will be executed as a SQL Injection payload.
To exploit such gadgets, you must have access to the source code or some stack trace that provides valuable information. Otherwise, an attacker would have to brute-force it, making it much more challenging to exploit.
Tomcat logging properties gadget
This gadget had been widely used back in 2014. It allows an attacker to use the Tomcat logging properties to invoke java methods and eventually run arbitrary code.
- class.module.classLoader.resources.context.parent.pipeline.first.pattern: Will contain the content to be written
- class.module.classLoader.resources.context.parent.pipeline.first.suffix: Will contain the file suffix (.jsp)
- class.module.classLoader.resources.context.parent.pipeline.first.directory: Will contain the directory to store the file
- class.module.classLoader.resources.context.parent.pipeline.first.prefix: Will contain the file name
- class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat: Must be empty
Once we confirm we can update the previous static variables, we can proceed to write an exploit payload that would look like this
Vulnerability criteria
- JDK 9+
- Spring version (<= 5.3.17)
- No usage of an allowlist or a denylist for certain fields like “class” or “module”
- Form binding with name=value pairs – not using JSON/XML conversion
- Apache Tomcat as the Servlet container
- Packaged as a WAR
- spring-webmvc or spring-webflux dependency
Vulnerable code example
The following code is vulnerable to Spring4Shell because it de-serializes a form and matches the vulnerability criteria:
Over the next many days researchers might find additional gadget chains and payload that will overwrite the previous attack conditions.
Mitigation
There are now official patches to mitigate this vulnerability. Applying these Spring Framework patches is the best and recommended way to protect yourself from this vulnerability.
Patch vulnerable Spring versions
Vmware, the owners of the Spring Framework, have released patches for this vulnerability. You should patch as soon as possible.
- Spring Framework 5.3.x → 5.3.18
- Spring Framework 5.2.x → 5.2.20
Patch Tomcat
Although the vulnerability is in the Spring Framework, the Apache Tomcat server does contribute to the attack vector by providing necessary pre-conditions for a successful attack. To provide alternative patching options, Apache Tomcat team has released patched versions which close the attack vector from Tomcat’s side.
If you are unable to patch your Spring Framework (the recommended approach) but can patch your Tomcat, patch it to one of the following versions:
- Apache Tomcat 10.0.x → 10.0.20
- Apache Tomcat 9.0.x → 9.0.62
- Apache Tomcat 8.5.x → 8.5.78
Avoid gadgets in code and dependencies
Good practices in CI/CD could mitigate the risk of providing useful gadgets to an attacker, rendering this exploit less dangerous.
It is a good idea to Implement code check technologies to reduce the risk of providing gadgets to attackers.
- Use dependency check tools which can find libraries with actively exploited gadgets
- Use SAST technology to detect gadgets which are introduced in your code
Disable specific patterns
If you can not patch your Spring Framework or your Apache Tomcat, this vulnerability can be mitigated by disabling specific ‘patterns’ from being passed to the Spring Core DataBinder functionality. Refer to Praetorian’s blog post for more details on this method
Traceable AI provides the ability to detect threat actors attempting to exploit this vulnerability and can be configured to block those bad actors in real time.
Conclusion
Although the Spring4shell vulnerability is not as bad a vulnerability as the recent Log4Shell and Log4J related vulnerabilities, it still should be taken seriously. Applications relying on the Spring Framework should patch to the latest versions.
Currently known exploits rely on the Spring4Shell vulnerability to be paired with the Apache Tomcat server and with the application running from a WAR deployment. Although this is a somewhat specific configuration, the nature of the vulnerability is more general and there will likely be other ways found to exploit it.
Traceable AI
Traceable AI solutions for API security are an excellent choice for dynamic analysis of your API-driven application’s vulnerabilities. It delivers a mature infrastructure focused on the security observability of your ecosystem. You can check out how Traceable AI works and reach out to team members to learn more about how to better secure your digital assets.
This post was written by Juan Pablo Tosso. Juan Pablo has worked in the cybersecurity field for 10 years, leading penetration testing teams and DevSecOps operations. He is the founder and co-leader of the OWASP Coraza Web Application Firewall, an enterprise-ready open source WAF solution that aims to help companies of all sizes to enhance web and API security. He is currently focusing his cybersecurity skills to make API security better and friendlier at Traceable AI.
