The Spring4Shell vulnerability, now publicized as CVE-2022-22965, set off any number of alarmist cries that Spring4Shell was more serious than the Log4Shell vulnerability that was discovered late last year.
When details were first made available on Wednesday, prior to a formal CVE being named and yesterday’s patch by Spring, there was confusion between CVE-2022-22963 and CVE-2022-2947, which affected Spring Cloud, as opposed to Spring4Shell, which hits the core Spring Framework.
Spring Cloud is a microservices framework for larger distributed systems that helps develop applications for use in shared and remote environments accessed from multiple locations: the cloud. Spring Framework functions as the core underlying technology for Spring solutions within the Java programming language and Java runtime environments — the “internal plumbing.”
John Hammond, senior security researcher at Huntress, said while Spring4Shell ranks critical in severity and does offer a threat actor remote code execution — the ability to run arbitrary commands and control the target at will — the exploitation criteria suggests this weakness is present only in non-standard and non-default configurations. Hammond recommended that system administrators and security pros use the Spring blog article as a guide and reference for determining if their organization is impacted.
“It’s still absolutely a severe vulnerability that should be addressed within organizations that make use of the Spring Framework,” Hammond said. “As of Thursday, the Spring team has now released an official patch, as well as mitigations and workarounds, while Apache Tomcat has also released fixes for their affected software. While the vulnerability is only present under certain non-default configurations, this does not come across as 'the next Log4Shell' — but should still be handled appropriately."
Yair Manor, co-founder and CTO at CardinalOps, explained that Spring4Shell exists in the Spring Core library on JDK9+ and there’s no mitigation at the moment besides Praetorian’s suggestion of creating a ControllerAdvice component that can handle exceptions. Manor said it’s still a temporary solution at best and requires source code changes in the vulnerable applications. However, Spring4Shell does not work on JDK8 and thus a downgrade was suggested by some security experts, but this could have functionality implications and leave a system vulnerable to different vulnerabilities.
“There’s no way to know if any of these vulnerabilities have been exploited yet and alerting on any attempt to exploit them will create noise which eventually leads to alert fatigue, the SOC’s worst enemy,” Manor said. “Because the exploit means an attacker will try to run commands remotely using Java, one thing a SOC could monitor is suspicious processes spawned by Java. To avoid false positives, it’s recommended to investigate the logs at least 90 days backwards and whitelist known child-process executed by Java.exe.”
Yaniv Balmas, vice president of research at Salt Security, said Spring’s recent blog contains almost no new technical data about the issue. However, Balmas said it does announce the awaited Spring versions that include the fix, which all Spring users should update.
“The fact that a patch exists should automatically lower the panic threshold, however it’s wise to not disregard this vulnerability,” Balmas said. “It’s still very much a critical vulnerability that can potentially impact a very large portion of Java applications on the internet. As for now the only ‘in-the-wild’ payload is for Java application running over Tomcat server, however it’s very likely that we'll be seeing new flavors of this vulnerability in the near future. These could impact other web servers and platforms and widen the reach and potential impact of this vulnerability. It will not be wise to underestimate the potential impact of Spring4Shell as the potential victim number is still huge, and exploitation is fairly easy and can be used by practically anyone once made public.”
