SpringShell: The Latest Java Vulnerability

The last set of vulnerabilities that had everyone talking was the reveal of the Log4j2 flaw that impacted a Java framework for collecting logs in Apache webservers. As is now the case the vulnerability draw comparison to the Spectre and Meltdown flaws  seen a few years prior.

Comparisons between the two cases are unfair in the sense that one impacted Apache webservers utilizing the logging framework while the other impacted a vast array of CPUs. Now those looking to compare apples to apples can do so with the discovery of the SpringShell vulnerability.

The vulnerability described by Spring Cloud is stated as,

“The vulnerability impacts Spring MVC and Spring WebFlux applications running on JDK 9+. The specific exploit requires the application to run on Tomcat as a WAR deployment. If the application is deployed as a Spring Boot executable jar, i.e. the default, it is not vulnerable to the exploit. However, the nature of the vulnerability is more general, and there may be other ways to exploit it.”

For the average reader, this makes little in the way of sense. Luckily Microsoft has also provided a breakdown of the vulnerability, now given the designation CVE-2022-22965, less reliant on readers having a comprehensive knowledge of Java and Spring Framework. Microsoft researchers detail the vulnerability as,

“The vulnerability in Spring Core—referred to in the security community as SpringShell or Spring4Shell—can be exploited when an attacker sends a specially crafted query to a web server running the Spring Core framework.”

The Spring Framework is the most widely used Java framework with the vulnerability residing in the Java Development Kit (JDK) from version 9.0 and upwards if the system is also using Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and several other earlier versions.

Microsoft notes that a remote attacker can obtain an AccessLogValve object through the framework's parameter binding feature and use malicious field values to trigger the pipeline mechanism and write to a file in an arbitrary path. To do this several conditions need to be met. One such condition according to researchers is,

“In Java Development Kit (JDK) version 9.0 or later, a remote attacker can obtain an AccessLogValve object through the framework's parameter binding feature and use malicious field values to trigger the pipeline mechanism and write to a file in an arbitrary path, if certain conditions are met,”

Other conditions noted by researchers involve exploiting the Apache Tomcat serves as the Servlet container, that the app is packaged as a traditional Java web archive (WAR) and deployed in a standalone Tomcat instance.

That being said Spring Boot makes use of an embedded servlet, if this is the case then the package is not vulnerable to attack.

Microsoft notes that the only working exploit at the time of discovery, a proof of concept with code available on GitHub, can only be used remotely on a Tomcat server via its logging module using specific commands.

This potentially results in the attacker being able to change default access logs to whatever file they want by issuing requests to it over the web. An attacker can then change the contents of a web server or application.

Real World Exploitation

A week after the reveal of the flaw, security firm Check Point released data pertaining to real-world attempts to exploit the flaw. It is important to note that the flaw has been patched and users are urgently advised to update software if not done already.

In the week that has passed Check Point has detected approximately 37,000 attempts to exploit the flaw on networks watched over by the firm. This meant that 16% of organizations worldwide experienced some kind of attempt to exploit the flaw.

20% of the 16% were organizations based in Europe with Australia and New Zealand coming in a close second with 17%. In terms of economic sectors, SOftware vendors were the most targeted amounting to 28% of the attempts.

As mentioned above a patch has been made available. The patch released by VMWare fixes the following vulnerable apps:

• Spring Framework 5.3.18 and Spring Framework 5.2.20
• Spring Boot 2.5.12
• Spring Boot 2.6.6 (soon to be released)

For those making use of Tanzu applications the following apps have been determined to be impacted by the vulnerability:

• VMware Tanzu Application Service for VMs – versions 2.10 to 2.13
• VMware Tanzu Operations Manager – versions 2.8 to 2.9
• VMware Tanzu Kubernetes Grid Integrated Edition (TKGI) – versions 1.11 to 1.13

The first Tanzu applications listed above have been patched. However, the permanent fix for VMware Tanzu Kubernetes Grid Integrated Edition is still in the works. For those running the previously mentioned unpatched app, VMWare has published a workaround for administrators looking to temporarily secure infrastructure until a patch is released.

▼ Show Discussion