Overview
On March 30, A new zero-day critical vulnerability was leaked in another open-source software library. The vulnerability affects Spring Framework which is running over Java Development Kit 9.0 (JDK9.0) and above. Spring Core on JDK9+ is vulnerable to remote code execution due to a bypass for CVE-2010–1622. While Spring4shell needs to be addressed as soon as possible, it is important to highlight that as it is a common library that is used by many different java software components, it can be a major breach point allowing attackers to build a lateral move pivoting to business-critical assets in the organization.
There is a lot of confusion between two different vulnerabilities. The first is CVE-2022–22963, a vulnerability in Spring Cloud Function, which is considered to be less widely used. The leaked zero-day vulnerability named “Spring4Shell” still doesn’t have a CVE ID, however many researchers were able to create a Proof of Concept (POC).
https://github.com/reznok/Spring4Shell-POC
Is there a risk?
As more than 80% of businesses can potentially be compromised whenever a new RCE (Remote Code Execution) technique is found. The new emerging zero-day Spring4Shell demonstrates why it is so important to harden and improve the security posture in your organization.
The Spring Framework is a Java platform that provides comprehensive infrastructure support for developing Java applications. Spring handles the infrastructure for developers so that they can focus on developing their applications. Spring Core, like Log4J before it, is a library used by many developers in Java applications. Spring Core is the core of the framework that powers feature such as inversion of control and dependency injection. Currently, the exploit requires moderate Java understanding.
The vulnerability, which is an RCE, allows attackers to execute code on the target systems.
Even though there is no patch by VMware (who is in charge of Spring Framework), the impact may be high and allows the attackers the ability to get initial access or move laterally in the organizations’ environment.
However, exploitation might not be possible for every application which uses Spring Core. Most POCs are using payloads that are relevant for Tomcat (Tomcat provides a “pure Java” HTTP web server environment in which Java code can run), however, for sure that additional payloads will appear.
What should we do?
1- dentify all products that are vulnerable to Spring4Shell
- Identify java processes
- Validate that JDK9.0 or above is in use (lower versions are not vulnerable). This can be done by running the “java -version” command
- spring-beans*.jar or CachedIntrospectionResults.class are loaded
- The application uses Spring parameter binding
- Spring parameter binding uses non-basic parameter types
2- Update the Spring4Shell patch CVE ID: CVE-2022–22965
3- If possible, add a rule into your WAF (Web Application Firewall) to filter requests containing “class.*”, “Class.*”, “*.class.*”, and “*.Class.*” string permutation. While WAF rules can reduce the risk, they are not bulletproof.
4- Praetorian, published temporary mitigation for the vulnerability.
Identifying Spring4Shell
Check the following:
- Identifying if java processes are running and listening to a remote port
- Validating that JDK9.0 or above is in use
- spring-beans*.jar is loaded
Like in Log4Shell, organizations have no visibility to what applications use Spring, which makes it very hard for them to know what to tackle first and how.
Note: This is just initial remediation for the Spring4shell to mitigate the RCE and your organization to be compromised, more details will emerge and a relevant patch will be provided by the official source.
References
- https://www.cyberkendra.com/2022/03/springshell-rce-0-day-vulnerability.html
- https://bugalert.org/content/notices/2022-03-30-spring.html
- https://www.praetorian.com/blog/spring-core-jdk9-rce/
- https://github.com/tweedge/springcore-0day-en
- https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement
