After the Spring cloud vulnerability reported yesterday, a new vulnerability called Spring4shell CVE-2022-22965 was reported this time 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 are also affected
In this article, you’ll understand and clarify the difference between the two vulnerabilities, CVE-2022-22963 and CVE-2022-22965 or Spring4Shell, and 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 48h 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-22963 hitting specifically Spring Cloud, permitting to 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 as previously happened for 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 one of the fundamental parts of the framework. The vulnerability take 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 crafted HTTP request to exploit the vulnerability which was introduced after the patch for an old CVE.
It’s important to highlight that Spring4shell and CVE-2022-22963 are two different vulnerabilities affecting two different components.
The CVE-2022-22965 Spring4shell issue
The issue with Spring4shell has been actually introduced after a patch was released to address a previous remote code execution removing a deserialization function as shown below:
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 to inject a specific curl command 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 and the ease of exploitation as we have previously seen makes this really 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.
Using Sysdig scanning it’s possible to detect the vulnerable package.
Conclusion
This week is another reminder of how easily we can be vulnerable at any time as happened with Log4j. In this case affecting Java again, 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.
We will keep the blog updated in case of significant changes.
The post Critical Vulnerability in Spring Core: CVE-2022-22965 a.k.a. Spring4Shell appeared first on Sysdig.
Article Link: Critical Vulnerability in Spring Core: CVE-2022-22965 a.k.a. Spring4Shell – Sysdig