Due to its highly dependent nature on many factors, the hype did not live up to its predecessor. Subsequently, the term Spring4Shell has been renamed to SpringShell. However, this does not mean that the threat is not real. To all the industries relying on the Spring framework with the vulnerable deployment, an attack is likely to cause unprecedented damage and should be taken seriously. In light of being vigilant and proactive, we at Logpoint are analyzing the threat and looking at ways to keep our customers protected.
Since its first discovery, SpringShell has evolved into a family of vulnerabilities as more people are looking into it. A similar RCE in the Spring Cloud Function was discovered not long after, with a very uncreative naming; “not Spring4Shell” or “not SpringShell”.
This is a separate vulnerability from the SpringShell but the name is being used interchangeably due to its target and discovery coinciding with its predecessor. It is important to distinguish, however, as it’s a very different TTP and has a varying form of attack vectors and different modules altogether. Now given the CVE CVE-2022-22963, this attack makes use of the Spring Cloud function.
Am I Affected?
Despite the potential for a complete takeover of the server, the attack requires a very particular set of requirements, which means, that not everyone is in danger. For the exploit to be successful, the target system must have met all of the following conditions:
- Java Development Kit version 9 or later;
- Apache Tomcat as a servlet container;
- WAR (Web Application Resource) file format instead of default JAR;
- Dependencies on spring-webmvc or spring-webflux;
- Spring framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, or older.
However, there may be more yet unknown options of exploitation, and the very same vulnerability can be exploited in some other way.
Both of the CVEs have various POCs publicly available on the internet, however, a report by Palo Alto Networks shows that over 80% of attacks are found using the same TTP. Keeping this in mind, Logpoint’s Security Research and Global Services teams have published the report going into a detailed overview of the vulnerability, and how to detect and defend against attacks using Logpoint’s SIEM and SOAR capabilities.
Immediate Mitigation measures
Patches are available through Spring.io:
- Spring Framework versions 5.3.18 and 5.2.20
- Spring Boot versions 2.5.12 and 2.6.6
- Tomcat versions 10.0.20, 9.0.62, and 8.5.78
The main advice for anyone who uses the Spring framework is to upgrade to secure versions 5.3.18 or 5.2.20.
The Apache Software Foundation has also released patched versions of Apache Tomcat 10.0.20, 9.0.62, and 8.5.78, in which the attack vector is closed on the Tomcat side.
The Spring developers have also released patched versions of the Spring Boot 2.5.12 and 2.6.6 extensions that depend on the patched version of Spring Framework 5.3.18.
If for some reason you cannot update the above-mentioned software, then you should use one of the workarounds published on the official Spring website.
For a detailed analysis of the vulnerability and detection and prevention using Logpoint, please find the attached report. The Security Research and Global Services teams will keep updating our customers with new rules, detection methodologies, and playbooks to ensure that your SIEM+SOAR solution is up to date and keeps your infrastructure safe.