As the digital world continues to rebuild after the Log4j hurricane, the threat landscape is once again disturbed by the rumbling of an approaching zero-day storm.
After barely recovering from a zero-day dubbed as the worst hack ever encountered, concerns are understandably heightened, and as a result, there are many misconceptions about the severity of Spring4Shell.
This post addresses the common misunderstandings of Spring4Shell and offers a high-speed overview of the zero-day for those that don't have time for an in-depth technical analysis.
What is Spring4Shell?
Spring4Shell is a vulnerability in VMWare’s Spring Core Java framework - an open-source platform for developing Java applications.
Spring is a highly-popular framework with 60% of Java developers depending on it for the production of their applications. Because of the framework’s dominance in the Java ecosystem, many applications could potentially be impacted by the Spring4Shell zero-day.
In comparison, the Log4J framework is used by almost all Java-based web apps and cloud services, so though Spring4Shell is categorized as a critical vulnerability, it's still significantly less dangerous than Log4Shell.
The Spring4Shell vulnerability is being tracked as CVE-2022-22965.
What is the Impact of Spring4Shell?
To understand the potential impacts of Spring4Shell it helps to first understand how the Spring Core Java framework works.
Spring Core (often abbreviated as Spring) simplifies parameter extraction requests on an Apache Tomcat server or Java server In other words, Spring makes writing and testing code easier by allowing developers to map user requests to Java objects.
The Spring4Shell vulnerability allows attackers to exploit this pathway, making all connected applications vulnerable to Remote Code Execution (RCE).
Remote Code Injection (RCE) is a form of cyberattack where hackers remotely inject malicious code into a compromised machine.
An RCE can be established by simply sending a malicious query to a web server running on a vulnerable version of Spring.
Once established, the RCE attack vector opens multiple avenues for further cyberattacks including:
- Access to all internal website data
- Access to all backend website resources
- Access to all networked databases
- Access to resources hosting privileged credentials
Because Spring4Shell has the potential of facilitating RCE attacks, it was assigned a CVSS score of 9.8, which gives it a Critical security rating.
According to a report by CheckPoint, 16% of organizations worldwide impacted by Spring4Shell experienced exploitation attempts within the first 4 days of the zero-day’s discovery
Is Spring4Shell as Dangerous as Log4Shell?
The primary differentiator between Log4Shell and Spring4Shell is that most Log4j users were unaware that they were impacted by the vulnerability. Log4j is often bundled up deep inside an application because it's a component deployed within other tools and libraries used in the Java development process.
Spring4Shell, on the other hand, is not so easily hidden. The Spring is a development framework so users can easily identify if they’re impacted by the vulnerability/
The other reason why Spring4Shell isn’t as dangerous as Log4Shell is that multiple conditions need to be met in order for Spring4Shell to be exploitable.
You are in danger of a Spring4Shell cyberattack if you’re using:
- Spring Web MVC or Spring Webflux projects AND
- Spring Framework version 5.3.x prior to 5.3.18, and all versions prior to 5.2.20 AND
- Java 9 Runtime Environment or above, regardless of the language version the application is compiled for AND
- Deployed on Tomcat App Server as a WAR AND
- Spring Web MVC with parameter binding (enabled by default) AND
- Don’t have an allowlist of HTTP fields registered to be allowed or explicitly disallow fields that could cause malicious intent.
With Log4shell, you could force any java code to download and run. With Spring4Shell, you need to work with the java classes that already exist on the server. Currently, the only known exploit requires Tomcat to be running Spring, as the Tomcat logging java classes can be used to launch an attack. This could change if ongoing investigations confirm that Spring4Shell can also be exploited in other sever environments.
How to Respond if you’re Impacted by Spring4Shell
The best response is to upgrade to the latest patched Spring Framework versions - 5.3.18 and 5.2.20.
If upgrading is not a possibility, you can follow Spring’s suggest workaround process.
Even if you don’t meet all of the conditions for exploitation, upgrading to the latest versions of Spring is highly recommended.
It’s important to note that though the current known exploit occurs on Tomcat servers that doesn’t mean the zero-day is limited to this environment. Spring4Shell is still a new vulnerability so there may be other methods of exploitation that haven't been discovered yet.
Updating to the latest versions of Spring will give you the highest chances of protection if additional exploit methods are eventually discovered (fingers crossed).
Click here to request your free instant security score.
