Businesses have been at work since last week investigating whether their applications or third-party software products are vulnerable to Spring4Shell, a critical remote code execution (RCE) vulnerability impacting Spring Framework, one of the most popular development frameworks for Java applications. While exploitation attempts have already been observed in the wild, the rate at which developers are updating their Spring instances appears to be slow going.
According to Sonatype, the company that maintains Maven Central, the biggest repository of Java components and libraries, 80% of Spring downloads since March 31 when the flaw was confirmed have continued to be for vulnerable versions of the framework. Maven Central integrates with many development tools, so the data suggests that developers are not in a rush to upgrade their Spring instances.
However, that doesn’t mean that apps running unpatched versions of Spring are necessarily vulnerable. For the known exploits to work, applications need to meet several conditions that are typical in default configurations. Mitigation strategies can also be applied without upgrading the framework itself.
Spring4Shell exploit prerequisites
In addition to the original proof-of-concept exploit that was leaked publicly before a patch was available, several variations are circulating. Security researchers from Akamai observed attacks with variants using both GET and POST requests, the GET one being more efficient because it allows attackers to exploit the vulnerability with only one request to the server.
Additionally, one variant of the exploit uses a code obfuscation technique that’s meant to evade input filtering or detection rules applied by web application firewalls (WAFs).
The CERT team at German telecommunications giant Deutsche Telekom reported exploitation attempts hitting its honeypot servers since March 31. Microsoft’s threat intelligence team also reported seeing a low volume of exploitation attempts hitting the company’s cloud services. Meanwhile the U.S. Cybersecurity and Infrastructure Agency (CISA) added Spring4Shell, also tracked as CVE-2022-22965, to its Known Exploited Vulnerabilities Catalog on Monday.
The Spring4Shell vulnerability only impacts applications running on Java Development Kit (JDK9), which introduced a new API called class.getModule. This API gives attackers an alternative path to ClassLoader, a dangerous attribute whose parameters should not be externally controlled. Spring had code blocking access to this attribute since 2010 when a similar vulnerability was patched, but the blacklist did not include the getModule API added in JDK9. Fortunately, JDK8, which does not allow this vulnerability to be exploited, remains the more popular runtime for Java applications in use.
Two other prerequisites for exploitation are that the vulnerable application needs to run under the Apache Tomcat web server and be deployed as a WAR (Web application ARchive) package. Fortunately, many Spring applications are created with Spring Boot, a related tool that allows the creation of standalone applications and which use the executable JAR (Java ARchive) format by default. These applications are not vulnerable.
An application also needs to use Spring Framework’s data binding mechanism that allows developers to bind HTTP request parameters to a Java object to be vulnerable. Not all applications use this feature. However, one of the basic tutorials published on the Spring website for handling form submissions is vulnerable. Developers who followed this reference code might have introduced the vulnerability.
Detecting applications vulnerable to Spring4Shell
Several security researchers and companies have released free tools that can help detect vulnerable applications either locally or remotely. Researchers from cybersecurity firm JFrog released a Python scanner that can find possible instances of data binding in WAR and JAR files. Researcher Jan Schaumann released a similar file system scanner in the form of a Linux shell script, and researcher Hilko Bengen released a scanner written in Go.
Microsoft points out that a live application can be tested remotely by running the following request against it using the curl command line tool:
curl host:port/path?class.module.classLoader.URLs%5B0%5D=0
Researcher Florian Roth published YARA rules that can be used by defenders to check a system for a potentially successful compromise via Spring4Shell. The rules will detect malicious JSP backdoor files dropped by the known exploits.
The CERT Coordination Center at Carnegie Mellon University maintains a list of vendors that have confirmed having vulnerable products as well as other who are still investigating. A French researcher known as SwitHak also compiled a list of vendor responses and advisories to Spring4Shell with the help of the infosec community.
Mitigation for Spring4Shell
The best way to mitigate this vulnerability is to update Spring Framework to versions 5.3.18 or 5.2.20 and Spring Boot to versions 2.6.6 or 2.5.12. However, if updating the framework is not immediately possible there are alternative workarounds.
For example, developers could add a @ControllerAdvice that blocks assignments to some of the ClassLoader internal fields to their applications. However, the Spring developers warned that this is not completely failsafe in some situations and provided more guidelines in their advisory.
Another temporary mitigation is to upgrade Tomcat to version 10.0.20, 9.0.62 or 8.5.78, which were released in response to Spring4Shell. The currently circulated exploits rely on the Tomcat-specific feature AccessLogValve to overwrite arbitrary files and deploy backdoors on servers, so the Tomcat developers released these new versions to close this attack vector. However, while this might cripple the current exploit, it shouldn’t be viewed as a long-term solution, as attackers could discover alternative attack vectors.
Despite the name similarity to Log4Shell — a critical vulnerability discovered in December in the log4j Java logging library used in millions of applications — Spring4Shell does not seem to have the same widespread impact, primarily because of steeper exploitation requirements that less applications meet. That said, it is a serious vulnerability that will probably linger in enterprise applications for a long time. According to Sonatype’s data, almost 40% of log4j2 downloads from Maven Central continue to be for vulnerable versions of the library three months after Log4Shell was announced.
Copyright © 2022 IDG Communications, Inc.
