It hasn’t been the easiest year for Java developers, especially the Spring community. In late March 2022, a cybersecurity research firm leaked another significant vulnerability in the framework, which could affect a large portion of enterprise Java applications. The exploit, coined Spring4Shell, produces a Remote Call Execution (RCE) vulnerability if left unchecked. The exploit arrives on the heels of the Log4j exploit, which was discovered in late 2021.
Below, we’ll investigate the Spring4Shell zero-day vulnerability. We’ll examine this exploit from a high level to consider what businesses should know to mitigate it and how they should plan for the future.
Understanding the Spring4Shell Vulnerability
The Spring4Shell vulnerability is present within certain implementations of the Spring Framework. For those unfamiliar, the Spring Framework is an open-source community-built software platform. It’s a standard deployment and deployment framework for Java developers.
The Spring4Shell vulnerability uses data binding to initiate Remote Code Execution (RCE), a cyber threat where an attacker finds a way to execute dangerous code inside an application. Although RCE is less common than other web application vulnerabilities, like Cross-Site Scripting (XSS), Cross-site request forgery (CSRF), and SQL injection (SQLi), it is on the rise and should still be taken seriously due to the near limitless abilities it can grant an attacker.
How Does it Work?
The Spring Framework RCE vulnerability is formally known as CVE-2022-22965. As Contrast Security explains, updates to a new class object in Java 9 make it possible to expose the getModule() method.
“The issue relates to data binding used to populate an object from request parameters,” describes the Spring.io blog. The vulnerability involves access to properties of Tomcat’s ClassLoader. Tomcat is a commonly used open-source Java HTTP web server.
Through this frailty, hackers can theoretically create a malicious backdoor to invoke system commands in just a few simple steps. What’s shocking is that this vulnerability has been exploitable for five years, since Java 9 was released in 2017.
Who Is Affected?
“The vulnerability impacts Spring MVC and Spring WebFlux applications running on JDK 9+,” describes the Spring announcement. They also provide a list of the specific criteria:
- You use a Spring app (up to and including version 5.3.17)
- Your app runs on Java 9+
- You use form binding with name=value pairs
- You don’t have other safeguards in place, such as a denylist
- The application is run on Tomcat as a WAR deployment
As mentioned, this specific exploit requires running the application on Tomcat. Since Tomcat is rather popular throughout enterprise Java applications, many businesses could be affected. However, other class loaders could be vulnerable, too, meaning it is good to consider mitigating this vulnerability as soon as possible.
While it is a general vulnerability, hackers may find ways to exploit it using different server configurations outside of Tomcat. For this reason, some feel Log4Shell has the potential to be much worse than Log4j.
“The Contrast Security Labs team has confirmed a critical zero-day vulnerability named Spring4Shell, affecting the spring-core artifact, which is a popular framework used widely in 74% of Java applications,” said David Lindner, CISO at Contrast Security. “The Contrast Labs team has proven the exploit due to how a Spring application handles binding, and we believe it could have a larger impact than Log4j. Our team is continuing to explore this vulnerability. We recommend Java developers to specifically set the allowed fields property or properly set the disallowed fields for the known malicious attack patterns within the DataBinder class.”
Mitigations
So, what can be done to mitigate the effects of Spring4Shell? Well, first, it is recommended to upgrade the Spring Framework. Patches 5.3.18 and 5.2.20 contain fixes to this vulnerability. Even if your current setup doesn’t precisely match the aforementioned vulnerable states, doing so is a good practice. So, 5.3.x users should upgrade to 5.3.18+, and 5.2.x users should upgrade to 5.2.20+.
Also, Spring frameworks are recommended to upgrade Spring Boot 2.6.6 and 2.5.12. And, Apache Tomcat has also released a new version that closes the attack vector on Tomcat. If you can’t upgrade for whatever reason, another option is to set allowed fields to specify only the bindings you wish your application to use. Experts also recommend setting Disallowed Fields as well for a defense-in-depth approach.
Final Thoughts
30% of Apache Log4j vulnerabilities remain unpatched, reports Newstack. And, Spring4Shell may have a similar trajectory of incomplete production fixes. Thankfully, organizations can simply update to new patches to prevent most of these threats.
In general, organizations are at risk of rising cyber threats. To respond, CISOs should consider reviewing established standard cybersecurity guidelines and frameworks and following general best practices, such as the rule of least privilege, defense-in-depth, and zero trust.
It’s also good to keep in mind that, although development frameworks are becoming increasingly abstracted with low-code, the foundation of most platforms is built on open-source components. In fact, 78% of companies run open-source software.
Open-source may be free, but it comes with the expectation to support and maintain it. This includes updating the project with the latest security expectations to avoid misuse.
Want more cybersecurity insights? Visit the Cybersecurity channel:
