Spring is a Java framework for dependency injection and Model-View-Controller (MVC) web development. Spring is a very popular framework; over 6,000 other libraries use the "spring-beans" library (according to Maven Central). Spring4Shell, a new exploit in Spring, was just disclosed.
Who found the Spring vulnerability?
The vulnerability was found by a yet-unknown member of the infosec underground and leaked by the team that maintains the well-known malware repository vx-underground according to Cyber Kendra. At the time of writing, it is unclear whether the vulnerability has been used by malicious actors. Mitiga has not observed the vulnerability or reports of the vulnerability being used in the wild.
There is some confusion given that another Spring vulnerability, CVE-2022-22963, affecting Spring Cloud Connector, was also recently announced. These vulnerabilities appear to be unrelated.
What is Spring4Shell?
The vulnerability, referred to thus far in open-source reporting as Spring4Shell or SpringShell, affects software using the "spring-beans" libraries on Java 9 and Tomcat 9 and above. The vulnerability allows an attacker to write a malicious payload to disk, which can then be executed by a subsequent crafted request.
Am I affected by Spring4Shell?
Given the number of preconditions, most web applications based on Java are likely not exploitable. That said, given Java’s prevalence, Mitiga recommends organizations exercise caution and take steps to manually validate all Java applications within the environment. The following steps should enable you to validate whether a given application is affected:
- Validate whether the application is running on Java 9 or above. You can do this by running "java -version" on the command line.
- Validate whether Tomcat is installed and is version 9 or above.
- Decompress each application’s WAR file by changing the extension to ZIP and using a decompression tool built into your operating system. You may be affected if the decompression artifacts contain a JAR file starting with "spring-bean" or a file called "CachedIntrospectionResults.class.”
- If all of the above are present, validate whether the application uses Spring Parameter Binding with non-basic types (such as “Plain Old Java Objects” or POJOs).
- Some reporting indicates that the vulnerability is only exploitable when “application.properties” configuration file enables the setting server.tomcat.accesslog.enabled . Mitiga has not validated whether the vulnerability is exploitable without this condition.
If you cannot validate the above, continue to watch industry reporting for guidance. After a vulnerability is discovered, security researchers are often able to find additional avenues for exploitation beyond what was originally known. Mitiga will continue to monitor the situation on behalf of its customers and will update this guidance accordingly.
Is the Spring vulnerability being exploited in the wild?
No official reports of exploitation are available, but public proof-of-concept code exists. The existence of proof-of-concept code typically enables low-skill adversaries to conduct mass scanning and exploitation campaigns. Organizations that rely on externally facing Java applications that may be affected by the vulnerability should monitor logs closely to check for indicators of compromise. Mitiga has begun reaching out to customers to determine whether they might be affected.
Can I patch Spring?
As of this writing, there is no official patch for the exploit. Cybersecurity news source "CyberKendra" released guidance for users who wish to manually patch this Spring vulnerability themselves.
Mitiga has not evaluated the efficacy of the patch nor validated whether additional exploitable conditions exist beyond what is shared in public reporting. Security researchers have released YARA rules that detect exploitation strings used in the proof-of-concept code.
As news continues to spread of the Spring vulnerability, additional YARA rules or other indicators might become publicly shared. Mitiga will continue to provide updates as additional intelligence becomes available.
Is this as bad as Log4Shell?
This vulnerability does not appear to be as bad as the Log4J vulnerability announced a few months ago. Namely, there are a variety of preconditions for exploitation that are nonstandard configurations. That said, organizations should always exercise caution when a zero-day vulnerability is announced that may affect them.
While it is difficult to say, it is likely not as exploitable as the Log4J vulnerability announced a few months ago. Not only is Log4J more widely used, but Log4j is also easier to exploit because any data that was ultimately written to a log file could be used as an exploitable attack surface. While not yet fully confirmed, it appears that the attack surface for Spring4Shell is considerably smaller and only exploitable when user-supplied data is deserialized into a Java object.
