NOTE: This post will be updated as the situation develops.
Overview
On Thursday, March 31st a patch for a widely used Java framework called the Spring Framework was given the designation CVE-2022-22965 with a CVSS Score of 9.8. That’s bad news for a lot of companies that make use of this framework for delivery of their web applications, services and APIs. This is a remote code execution (RCE) vulnerability and the ease of exploitation is partly why it has earned a 9.8 out of 10 on the CVSS Score.
Way back in 2010 there was an RCE for the Spring Framework v2.5 which fixed the vulnerability discovered then about unsafe class.classLoader.URLs. This new RCE is related to that vulnerability. The fix 12 years ago was to forbid jumping from a class to classLoader and the fix this time is to forbid jumping from a class to module. Once again it seems that being a major version behind is a saving grace because getModule() is only present in JDK9+.
Spring has acknowledged the vulnerability and released v5.3.18 and v5.2.20 to patch the issue as well as version v2.6.6 for spring-boot.
SecurityScorecard recommends an immediate upgrade for all users.
SecurityScorecard broadly surveys the Internet, across 2000+ ports every day, using proprietary technology. Once Spring4Shell was disclosed, SecurityScorecard’s Threat Research and Intelligence team added passive detection to our scanning system, using the widely-trusted Nmap Scripting Engine, to test for the vulnerability following community guidance on detecting the vulnerability. As of April 1st, 2022, SecurityScorecard is in the process of adding a new issue type to the Application Security factor titled “Web application potentially vulnerable to Spring4Shell” that will be available for all SecurityScorecard customers and will continue to populate every day with new findings from our global Internet observations.
Remediation Details
Some aspects of this vulnerability to consider:
Only affects Java versions 9 and higher (JDK9+)
Exploitable for Internet-facing endpoints only
Patch to the latest stable and secure version if you can
Apply the configuration mitigation / tweak if you cannot patch (disable DataBinder)
Revert to JDK8 if you cannot patch or tweak
The best way to mitigate the vulnerability is to update spring-core to v5.3.18 or v5.2.20 to patch the issue as well as version v2.6.6 for spring-boot.
However, not all companies can deploy a change to production within hours or even days, given their need to test in non-production environments and long-running change control timeframes or limited release windows (no major changes to production environments on a Friday is a common practice for example). In this case, our recommendations include options for dealing with such situations.
If your application has previously run on JDK8,for example, you may be able to employ less exhaustive regression testing by simply pointing your JAVA_HOME environment variable to JDK8 binaries and libraries and restarting your services.
Praetorian have published a denylist approach that can also be applied if DataBinder cannot be disabled:
In Spring Framework, DataBinder has functionality to disallow certain patterns. As a temporary mitigation for this vulnerability, Praetorian recommends creating a ControllerAdvice component (which is a Spring component shared across Controllers) and adding dangerous patterns to the denylist. An example snippet is shown below:
import org.springframework.core.Ordered;
import org.springframework.core.annotation.Order;
import org.springframework.web.bind.WebDataBinder;
import org.springframework.web.bind.annotation.ControllerAdvice;
import org.springframework.web.bind.annotation.InitBinder;
@ControllerAdvice
@Order(10000)
public class BinderControllerAdvice {
@InitBinder
public void setAllowedFields(WebDataBinder dataBinder) {
String[] denylist = new String[]{“class.*”, “Class.*”, “*.class.*”, “*.Class.*”};
dataBinder.setDisallowedFields(denylist);
}
}
Exploitation Details
One of the current forms of attack for this vulnerability relies on the DataBinder functionality, that enables loading of arbitrary classes, which is leveraged by threat actors to execute arbitrary code on the vulnerable system, application or API.
The vulnerability lives in an artifact known as spring-beans and proof of concept (PoC) exploit code has already been published to GitHub repositories. Active scanning for this vulnerability has been observed coming from the usual suspects like Russian and Chinese IP space. Specifically crafted web client requests are all that is required to exploit this vulnerability, but finding an effective payload to deliver will be the next step an attacker makes after discovering which IP addresses are running a vulnerable version.
Detections Details
SecurityScorecard is passively scanning for this vulnerability to identify which scorecards and organizations are affected, and will have quantitative data on the scope of impact for this vulnerability in the coming week.
We expect to see a very high rate of exposure across anyone using Spring Framework for those that have not yet patched. We have developed two Nmap Scripting Engine (NSE) scripts that passively test for both CVE-2022-22965 and CVE-2022-22963.
At publish, we see early indications since the beginning of global scanning that tens of thousands of web servers are vulnerable. We will update this post ASAP with more detailed findings.
Note from Sonatype’s blog post on the subject: A separate Spring vulnerability CVE-2022-22963 (CRITICAL) disclosed a few days ago impacts Spring Cloud Function. This is a Spring Expression language SpEL vulnerability and is NOT related to “Spring4Shell” that impacts Spring.
Your vulnerability scanning solution should also have reacted quickly to this new CVE which means you can also detect with tools like Tenable, Qualys and Rapid7 (among others). If you do not have an authenticated vulnerability scanner solution in place, this is a good reason to push the request to your finance team to approve a budget allocation. Scanning for vulnerabilities and fixing them is a lot less expensive than being compromised, breached and caught up in the quagmire of an incident.
Conclusion
If this feels all-too-familiar and is reminding you of the Equifax hack that was due to an exploitation of the Apache Struts2 framework, then your instinct is spot on. This is the same kind of vulnerability.
You have the ability to see this issue (to be reported as informational in our ratings platform) by claiming your free SecurityScorecard. Just visit our site and begin seeing what the bad guys see for this and thousands of other risks, vulnerabilities and misconfigurations. Security Ratings Services like SecurityScorecard provide continuous monitoring of 1st party, 3rd party and now, with Automatic Vendor Detection, 4th party risk.