After the Spring cloud vulnerability reported yesterday, a new vulnerability called Spring4shell CVE-2022-22965 was reported on the very popular Java framework Spring Core on JDK9+.
The vulnerability is always a remote code execution (RCE) which would permit attackers to execute arbitrary code on the machine and compromise the entire host.
The affected versions are the following:
- 5.3.0 to 5.3.17
- 5.2.0 to 5.2.19
- Older, unsupported versions
In this article, you’ll understand and clarify the difference between the two vulnerabilities, CVE-2022-22963 and CVE-2022-22965 or Spring4Shell, see how to exploit it and mitigate the new vulnerability using Sysdig.
What is going on with Spring
You may have seen a lot of hype during the last 48 hours regarding Spring and Spring Framework. Make some clarifications on what is going on. It’s needed to be sure to understand and mitigate the right risks and vulnerabilities.
What happened with Spring cloud – CVE-2022-22963
As we reported yesterday, the new CVE-2022-22963is specifically hitting Spring Cloud, permitting the execution of arbitrary code on the host or container.
The vulnerability can also impact serverless functions, like AWS Lambda or Google Cloud Functions, since the framework allows developers to write cloud-agnostic functions using Spring features.
What is CVE-2022-22965 aka Spring4shell?
A new vulnerability was found in Spring Core on JDK9+ allowing a remote code execution, like what previously happened on log4j and Spring cloud. This vulnerability is referenced as Spring4shell.
The Spring Framework is a famous open-source framework used to easily build Java applications. One of the main components is Spring Core, which is among the fundamental parts of the framework. The vulnerability takes advantage of an issue in this part to execute arbitrary code on the host or container.
In this case, using certain configurations, it’s possible for an attacker to send a sequence of crafted HTTP requests to exploit the vulnerability.
The CVE-2022-22965 Spring4shell issue
Updated: The Spring4Shell is a critical vulnerability that exploits class injection leading to a complete RCE.
In particular, the vulnerability affects functions that use RequestMapping annotation and POJO (Plain Old Java Object) parameters. RequestMapping uses setter and getters for id to set and get values for specific parameters.
Thus, compiling the project and hosting it on Tomcat is possible with a specific curl command sequence that can modify Tomcat logging properties. Consequently, it is possible to upload a webshell in the Tomcat root directory.
Once uploaded, the webshell can allow attackers to run arbitrary commands on the impacted machine. For more information, look at the PoC here: https://github.com/craig/SpringCore0day.
In order to exploit the vulnerabilities, the following requirements must be met:
- JDK 9 or higher
- Apache Tomcat as the Servlet container
- Packaged as WAR
- spring-webmvc or spring-webflux dependency
The impact of CVE-2022-22965 Spring4shell
According to the CVSSv3 system, it scores as CRITICAL severity.
Looking at the potential impacts of this type of vulnerability, it has high impacts on confidentiality, integrity, and availability, as well as the ease of exploitation, which is critical for all the users adopting this solution.
However, there are some requirements that need to be met in order to successfully exploit the vulnerability as we have seen before.
Exploiting the vulnerability is possible to achieve the total compromise of the host or container executing arbitrary commands.
How to detect and mitigate CVE-2022-22965
If you’re impacted by CVE-2022-22965, you should update the application to the versions:
- 5.3.18+
- 5.2.20+
As we have seen for the previous CVE-2022-22963, we can detect this vulnerability at three different phases of the application lifecycle:
- Build process: With an image scanner.
- Deployment process: Thanks to an image scanner on the admission controller.
- Runtime detection phase using a runtime detection engine: Detect malicious behaviors in already deployed hosts or pods with Falco.
Let’s now dig deeper into each of them.
Using Sysdig scanning, it’s possible to detect the vulnerable package.
Implementing image scanning on the admission controller, it is possible to admit only the workload images that are compliant with the scanning policy to run in the cluster.
Creating and assigning a policy for this specific CVE-2022-22965, the admission controller will evaluate new deployment images, blocking deployment if this security issue is detected.
To detect at runtime with Falco, here is a reverse shell rule example. To avoid false positives, you can add exceptions in the condition to better adapt to your environment.
Conclusion
This week is another reminder of how easily we can be vulnerable at all times, like what happened with Log4j. In this case, Java is affected; more specifically:
- CVE-2022-22963: Spring Cloud Function
- CVE-2022-22965: Spring Framework
To be safe, use scanners to find out if you are affected and patch with the latest version to mitigate vulnerabilities. Similarly, use the necessary measures to check that everything is correct in the deployment and never stop monitoring your infrastructure or applications at runtime.
