Researchers have discovered a critical vulnerability CVE-2022-22965 in Spring, an open-source framework for the Java platform. Unfortunately, the details related to the vulnerability were leaked to the public before the official announcement, and the relevant patches were released. The vulnerability drew the attention of information security specialists right away, as it potentially poses a serious threat to many web applications. Exploitation attempts impacted 16% of the organizations worldwide during the first four days after the vulnerability outbreak.
The infosec community has given CVE-2022-22965 the name SpringShell vulnerability because the Spring Framework is widely used for web system development. The severity of the vulnerability is critical with CVSS score of 9.8. Read on to find out what SpringShell vulnerability is all about, what components are necessary to exploit it, how it is currently getting exploited, and what majors you can take for better cloud security.
What Is SpringShell, and Why Is This Vulnerability So Dangerous?
The Spring framework is popular among Java developers for building web applications, which means many applications could be potentially vulnerable. The security vulnerability is not exploitable for all web applications; however, the prerequisites for exploitation may not be uncommon. For example, some of the basic tutorials published by Spring could be susceptible to this vulnerability. Many web application developers use these tutorials as templates, which could result in vulnerable applications being released into the wild.
The vulnerability was initially reported to VMware on 29th March 2022. A 0-day proof-of-concept was published the next day, sending researchers scrambling to verify its authenticity. Microsoft quickly removed the PoC from GitHub, but it is unlikely for cybercriminals not to have noticed such a potent exploit. On 31st March 2022, the vulnerability was officially confirmed.
The vulnerability belongs to the RCE class, allowing an attacker to remotely execute a specially crafted query or malicious code to a web server running the Spring Core framework. There are no mitigation techniques against this type of vulnerability in the JDK itself, and the vulnerability is not that noticeable to be exploited in a stable manner.
Traits For Exploiting a SpringShell Vulnerability
The only SpringShell exploitation method known at the time of publication requires a specific confluence of characteristics or circumstances. The following components should be utilized on the attacked side for the exploit to be successful:
●Running JDK 9.0 version or later
●Apache Tomcat as a servlet container
●Dependencies on spring-webmvc or spring-webflux
●Packaged as a traditional Java web archive, WAR (Web Application Resource)
●Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and former versions
However, it’s possible to discover more exploitation options and different ways to exploit the same vulnerability.
How is SpringShell Getting Exploited Currently?
There are several ways to exploit the modification of ClassLoader to obtain remote code execution. Nevertheless, the originally published PoC exploited this security vulnerability using a Tomcat-specific technique, i.e., abusing the AccessLogValve to get arbitrary file overwrite. The exploit works in the following stages:
●Overriding Tomcat-specific ClassLoader attributes to change the access log file path to somewhere under the webroot directory and change the written data, i.e., the log pattern, to a constant pattern containing the web shellcode. As a result, the web shell JSP is dropped under the webroot directory.
●Sending a query request to the dropped web shell to run an arbitrary shell command
How to Protect Yourself from SpringShell?
The VMware Spring framework creators have already released patches to fix vulnerable applications, so the main advice for all companies using Spring Framework versions 5.3 and 5.2 is to upgrade to the versions 5.3.18 or 5.2.20 immediately. In addition, the Apache Software Foundation has also released patches for Apache Tomcat 10.0.20, 9.0.62, and 8.5.78. The attack vector is closed on the Tomcat side in these patched versions. Moreover, the Spring developers have also released patched versions of the Spring Boot 2.5.12 and 2.6.6 extensions, which rely on patched versions of Spring Framework 5.3.18. If you can’t update the above software for some reason, you can try one of the workarounds listed on the official Spring website.
Conclusion
This vulnerability cannot be labeled as bad as a Log4Shell. All attack scenarios in SpringShell are more complex and have more mitigating factors than Log4Shell did due to the nature of how ClassLoader Manipulation attacks work in Java. With Log4Shell, exploitation was comparatively minor, and an exploit that worked on most apps could be written in seconds. However, with SpringShell, exploitation requires deep Java knowledge and training to get a functioning POC.
