Between March 29th and March 30th, 2022, the Spring Framework had three different issues publicly reported. Each of them, at various points, has been referred to as Spring4Shell or SpringShell. Two of the issues have patches.
The first issue in Spring Cloud Function, CVE-2022-22963, is a Remote Access Vulnerability impacting Spring Cloud Function versions 3.1.6, 3.2.2, and older. This vulnerability has a patch.
*The first issue is not related to the Spring Core SpringShell/Spring4Shell named vulnerability.
The second issue in the Spring Framework allowed programmers to use deserialized objects, and this flaw meant code from untrusted sources could be included in the software package made. The patch released is meant to warn users of the danger of using deserialized content.
*The second issue is separate from the Spring Core RCE vulnerability known as Spring Core.
The third issue is the actual, named SpringShell and Spring4Shell, which is in the Spring Core and allows Remote Code Execution (RCE). This flaw requires both the Java Developer Kit (JDK) 9 and the Spring-Beans packages to be in use.
Researchers publicizing this flaw have said it will be similar to the Log4j flaw from late 2021 / Early 2022. The vulnerability allows threat actors to run arbitrary code via the Java Class object.
*There is no patch for the third issue, at the time of this post. See our recommendations section below for next steps.
Coretek is making customers aware of the three different flaws and explaining them at a high level to prevent confusion while providing recommendations to remediate the problems.
Coretek advises customers to patch the issue by upgrading to the 3.1.7 or 3.2.3 packages as soon as possible. It is also recommended to initiate a threat hunting activity on the systems with your Incident Response Team to confirm that no data was accessed without authorization.
Coretek advises customers to update the Spring Framework to the current version hosted on the Spring Framework GitHub Repository. While this does not stop the deserialization ability in the framework, it does provide a “bad practice” warning. It is also advised that customers view their existing code packages made with the framework for any instances of “SerializationUtils.deserialize” or “SerializationUtils#deserialize".
Coretek advises that customers follow similar processes used to detect the previous Log4j vulnerability. It is also advised to have the Web Access Firewall (WAF) implement filtering rules for stings like "class.*", "Class.*", "*.class.*", and "*.Class.*". However, during the filtering rollout, testing should be performed to ensure that business functions are not blocked.
If you are a Coretek customer, have any questions about Coretek remediation actions or your support agreements with Coretek, or are a visitor who would like more information, please use the button below to get in touch.