Spring4Shell: can we talk about a second Log4Shell?
Crédit: Daniel Christensen
On 29 March 2022, cybersecurity experts published details of a new remote code execution (RCE) vulnerability affecting the Spring Core Framework (since officially confirmed as CVE-2022-22965).
Spring Core is an open-source framework built into the Apache Tomcat server that provides tools and utilities for Java-based enterprise applications. It is ubiquitous in the enterprise because of its ability to reduce the amount of effort required to produce a functional Java web application.
The impact of an RCE on this Framework could therefore be similar to the Log4Shell vulnerability. On the same day, proof-of-concept (PoC) snippets started to appear quickly on Twitter, but were all removed after a few minutes.
In a blog post published on 31 March, Spring's Rossen Stoyanchev confirmed that the zero-day vulnerability in the Spring Framework had been disclosed prior to the release of the CVE by researchers at AntGroup FG. The team had intended to release emergency patches for the bug on Thursday 31 March, however details of the bug were disclosed online on Wednesday.
How the Spring4Shell vulnerability works
Spring4Shell is a bug in the Spring Core Framework. The bug in question allows an unauthenticated attacker to execute arbitrary code on a vulnerable system.
Several PoCs of the Spring4Shell vulnerability are already available. Most of them are inspired by this GitHub repository.
The exploit relies on a specially crafted HTTP request that abuses the way Spring's RequestMapping interface interprets and parses web request parameters. This interface matches incoming web requests with the appropriate methods in order to process them.
The vulnerability in Spring4Shell lies in the mechanism for filtering user-supplied data from the RequestMapping interface. Attacks exploiting Spring4Shell provide a payload using Module.getClassLoader(). This allows an attacker to load an arbitrary malicious class for the server to parse. Vulnerable versions of Spring did not filter this attack path, leading to the exploit.
Although the Spring Core code contains some logic to prevent access to the child properties of the class variable, this logic is not foolproof.
The fact that the class is accessible and can be "set" from the query parameters allows us to browse the properties of the class with our query parameter. It also gives the ability to locate a field that can be written to and executed by the program. For example, in Apache Tomcat, an attacker could access an AccessLogValve object from the class variable in this way:
A common way to exploit this access is to redirect the access log to write a web shell to the application's root folder by manipulating various properties of the AccessLogValve object, including pattern, suffix, directory and prefix.
Subsequent requests could be issued by replacing the "test" value with the payload, which will result in the following Tomcat logging properties being set:
class.module.classLoader.resources.context.parent.pipeline.first.pattern=%25%7Bprefix%7Di%20java.io.InputStream%20in%20%3D%20%25%7Bc%7Di.getRuntime().exec(request.getParameter(%22cmd%22)).getInputStream()%3B%20int%20a%20%3D%20-1%3B%20byte%5B%5D%20b%20%3D%20new%20byte%5B2048%5D%3B%20while((a%3Din.read(b))!%3D-1)%7B%20out.println(new%20String(b))%3B%20%7D%20%25%7Bsuffix%7Di class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT class.module.classLoader.resources.context.parent.pipeline.first.prefix=shell class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=
A file will be created under "webwapps/ROOT/shell.jsp" and will contain the payload contained in the first request issued above.
This file will be used to format the server logs, an arbitrary command can then be issued using the cmd request parameter:
It is important to note that the tests presented here only work on an Apache Tomcat server, as the above logging properties do not exist on a different server.
Spring4Shell vs Log4Shell
Although many similarities are drawn between Log4j and the Spring issues, an attacker would have to put in extra effort to exploit the vulnerability, as the weakness depends heavily on the configuration of the Java application.
According to Digital Shadows co-founder James Chappell: "In the case of Log4j - it was the ubiquity of the logging library that made security teams scramble to defend vulnerable systems and services before the weakness could be widely exploited.
"Enough web servers and hosts would have to have the specific set of configurations that would make them widely exploitable. Right now, it doesn't seem to be as widely available as Log4j which was almost universally exploitable on all systems. That said, the Spring Core library is often used in the most common web servers, which suggests the possibility of a significant impact, but not on the same scale as Log4j."
While many initially downplayed the issue and questioned its significance, others were quick to compare it to the widespread Log4Shell vulnerability that caused worldwide concern in December and January, dubbing the latest vulnerability "Spring4Shell" or "SpringShell".
David Lindner, CISO at Contrast Security, said that "the Contrast Labs team has proven the existence of an exploit due to the way a Spring application handles binding, and we believe this could have a larger impact than Log4j," Lindner said.
He added that the Spring Core artefact is widely used in 74% of Java applications and that his team has seen a 20x increase in attacks targeting the Java ClassLoader since Wednesday 30 March, corresponding to the inevitable wave of attacks by hackers trying to exploit this new vulnerability:
Its proximity to Log4Shell also provides insight into its future development. For example, data shows that more than 40% of Log4j downloads are still vulnerable versions more than four months after CVE-2021-44228 was discovered.
Netenrich's John Bambenek said that what has made Log4j such a problem is that it is often installed on "headless" appliances and other devices that are not maintained by the end customer.
"We don't know if this will be true for Spring, but any NCE problem should go straight to the top of the pile for security teams to deal with," he explained
Are all applications vulnerable?
For an application to be vulnerable to Spring4Shell, it must meet several conditions, as stated in the Spring advisory:
- use JDK 9 or higher;
- use Apache Tomcat as a servlet container (A servlet is aJava class that allows to dynamically create data within an HTTP server);
- be packaged as a traditional WAR (as opposed to a Spring Boot executable jar);
- use the spring-webmvc or spring-webflux dependency;
- use versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19 or earlier of the Spring framework.
Is a patch available for Spring4Shell?
Spring has now released Spring Framework 5.3.18 and 5.2.20, which fix the vulnerability. Spring Boot 2.6.6 and 2.5.12 which depend on Spring Framework 5.3.18 have also been released. Temporary remediation steps have also been released by Praetorian researchers prior to the release of the updates. Spring has also published suggested workarounds on its blog.
A CVE report for the vulnerability has also been published and has been assigned the designation CVE-2022-22965, and has been assessed as "high severity".
As the Spring4Shell vulnerability is a high-impact, easy-to-exploit vulnerability in environments using a vulnerable version of Spring, it is essential that Java applications using this Framework are updated as soon as possible in production to protect against it.
Author: Timon Rose