Updates:
April 5, 2022, 12 p.m. ET
The “Spring4Shell” RCE (CVE-2022-22965) has been added to CISA’s list of known exploited vulnerabilities. Due to the conditions required to exploit the vulnerability, security researchers are beginning to form a consensus that, while serious, Spring4Shell is not as critical or dangerous as the Log4Shell vulnerability.
The conditions for exploitation require custom configurations, and it is not known how common these configurations are in the wild. Conditions for affected organizations include:
- Use of JDK 9 or higher
- Use of Tomcat as the Servlet container
- Packaging as a traditional WAR
- Use of Spring-Webmvc or Spring-Webflux dependencies
- Use of affected versions of Spring
- Use of versions 5.3.0 through 5.3.17, 5.2.0 through 5.2.19, or older
Fixes are available from both Spring (5.3.18 and 5.2.20) and Tomcat (10.0.20, 9.0.62, and 8.5.78), so updating can neutralize the risk of the vulnerability.
Initial reports on Spring4shell tended to exaggerate the severity of the vulnerability, with some likening the impact to Log4J or noting that the vulnerability could “break the internet.” With more detail and fixes available publicly, it is now clear that early reports were somewhat alarmist. While the vulnerability is serious and requires immediate remediation, it does not constitute as severe or widespread a threat as the Log4Shell vulnerability.
March 30, 2022, 4 p.m. ET
Retail & Hospitality ISAC threat researchers confirmed the validity of Spring Framework RCE vulnerability. See details.
Context
On March 29, 2022, reports began circulating among security research blogs of an alleged remote code execution vulnerability in Spring, the popular web framework for Java. As of this writing, no proof-of-concept (POC) has been made public, and no CVE number has been assigned. Bug Alert has designated the vulnerability as “high” currently with the caveat that a POC would escalate the rating to “critical.” The Security blog Cyber Kendra has preliminarily named the vulnerability “SpringShell.” The vulnerability allegedly affects JDK versions 9 and higher.
As of this writing, Spring has not confirmed or denied the existence of the vulnerability and no patch is available. Spring developers said in Github commits that their recent activity was depreciating serializationUtils, not a patch, and that users should not deserialize objects from untrusted sources.
Details
According to Cyber Kendra, “a remote attacker can obtain the AccessLogValve object and malicious field values through the parameter binding function of the framework on the basis of meeting certain conditions, thereby triggering the pipeline mechanism and writing arbitrary fields in the file path.”
To determine if they are affected by this vulnerability, users can follow the following process:
Check java version:
- java –version
- If your JDK version is under 8 you might not be vulnerable, however, nothing is confirmed yet
If deployed as WAR packages:
- Change file extension from [.]war to [.]zip and decompress archive
- Search for existence of [.]jar files in ‘spring-beans-{VERSION}[.]jar’ format within decompressed archive (e.g. spring-beans-5[.]3[.]16[.]jar)
- If spring-beans-{VERSION}[.]jar file doesn’t exist, search for existence of CachedIntrospectionResults[.]class files within decompressed archive. If it exists, it is an indication the system uses Spring Framework development
If running directly/independently as a JAR package:
- Change file extension from [.]jar to [.]zip and decompress archive
- Search for existence of [.]jar files in ‘spring-beans-{VERSION}[.]jar’ format within decompressed archive (e.g. spring-beans-5[.]3[.]16[.]jar)
If spring-beans-{VERSION}[.]jar file doesn’t exist, search for existence of CachedIntrospectionResults[.]class files within decompressed archive. If it exists, it is an indication the system uses Spring Framework development
After the steps above, if the following conditions are met it may be indicative of being vulnerable:
- Jdk version ≥ 9
- Spring Framework (or derivative framework) is used
Impact Implications
Both Bug Alert and Cyber Kendra noted that if confirmed, the vulnerability would be as significant as the Log4Shell and Heartbleed vulnerabilities. Spring is one of the most popular web frameworks for Java, meaning that a critical vulnerability would have widespread impact on users globally, including those in the retail, hospitality, and transportation sectors. If the vulnerability is confirmed, immediate patching as soon as possible will be critical.
Mitigations
With no patch or official statement yet, it is recommended to use the following temporary mitigations for protection:
WAF:
- Implement filtering rules for strings such as: “class[.]*”Class[.]*”[.]class[.]*”[.]Class[.]*” accordingly.
- Test/monitor the application to avoid additional impact.
Temporary Repair:
- Search the @InitBinder annotation globally in the application to see if the dataBinder[.]setDisallowedFields method is called in the method body. If the introduction of this code snippet is found:
- add {“class[.]*”,”Class[.]* to the original blacklist “,”*[.]class[.]*”, “*[.]Class[.]*”}. (Note: If this code snippet is used a lot, it needs to be appended everywhere)
- Create the following global class under the project package of the application system and ensure that this class is loaded by Spring (it is recommended to add it to the package where the Controller is located). After the class is added, the project needs to be recompiled and packaged, and tested for functional verification. and republish the project.
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 GlobalControllerAdvice{
@InitBinder
public void setAlllowedFields(webdataBinder dataBinder){
String[]abd=new string[]{"class[.]","Class[.]","[.]class[.]","[.]Class[.]"};
dataBinder[.]setDisallowedFields(abd);
}
}
