Last update: Monday 4 April 16:00 BST - Guidance for Sonatype customers, tweaks
Fri 1 Apr 11.00 BST - Guidance for Sonatype customers, clarified conditions of known exploits, evidence of mass scanning
Thu 31 Mar 16.56 BST - patches released, CURL and Search syntax added, CVSS and CVE added, updated artifact ID, known vulnerable methods, what to expect, mitigations
Sonatype Customers: We have published Find and Fix Spring4shell in our documentation
Early Wednesday morning (GMT), allegations began to appear on the internet about a new remote code execution flaw that affects Spring Framework. This vulnerability, dubbed by some as "Springshell or Spring4Shell" in the community, is a new, previously unknown security vulnerability. It has been added to Sonatype data as SONATYPE-2022-1764 and given the designation CVE-2022-22965 with a CVSS Score of 9.8.
Spring have acknowledged the vulnerability and released 5.3.18 and 5.2.20 to patch the issue as well as version 2.6.6 for spring-boot. We recommend an immediate upgrade for all users.
NOTE: A separate Spring vulnerability CVE-2022-22963 (CRITICAL) disclosed a few days ago impacts Spring Cloud Function. This is a Spring Expression language SpEL vulnerability and is NOT related to "Spring4shell" that impacts Spring. Some Twitter posts continue to incorrectly mix the two vulnerabilities.
My video conversation with Sonatype security researcher Ax Sharma.
The vulnerability affects the spring-beans artifact, which is a typical transitive dependency of an extremely popular framework used widely in Java applications, and requires JDK9 or newer to be running. It is a bypass for an older CVE, CVE-2010-1622 that due to a feature in JDK9 or newer seems to have been reinstated. This was confirmed by Praetorian. Since the time of writing, Spring have also confirmed the currently known forms of attack require JDK9 or above, Tomcat, application to be packaged as a war and the vulnerable class to be present.
This type of vulnerability relies on the software deserializing code, which is at the root of the problem.
Older versions of Spring allow for Java Reflection, which is the reason why many remote code execution (RCE) flaws have historically been observed. This means an attacker can poison a payload aimed at a Spring application and gain control of the system. The current known forms of attack rely on a constructor of the DataBinder functionality that enables loading of arbitrary classes, which can be leveraged by malicious entities.
This vulnerability affects applications that use Spring Framework and impacts most known versions to date. Spring is one of the most popular frameworks in Java, comparable in scale to Struts.
As with historical RCE attacks, the vulnerability has begun seeing scanning activity. We highly encourage all customers to mitigate and to upgrade to the known good versions as soon as possible. Drawing from a recent example, the Log4shell vulnerability drew in opportunistic attackers who began quickly exploiting the weakness as soon as a Proof-of-Concept (PoC) surfaced.
It's also important to note attack vectors will evolve over time and as attention grows new vulnerabilities may be discovered.
Wednesday, March 30, 2022, concerns surfaced in a series of distributed blogs and Twitter screenshots, alleging "Springshell" was shown below:
The claims were anecdotally confirmed Wednesday at 15:00 GMT when a PoC exploit surfaced on an original GitHub repository, shared with a Sonatype researcher by a source.
The PoC leverages a previously unknown method to achieve remote code execution (RCE). Present in the GitHub repo were also PDF with detailed exploit instructions:
As stated above, it stems from a previously exploited issue (CVE-2010-1622) in Spring that was patched in the past, but became vulnerable again when used with JDK9.
It's important to note, there are many POC exploits out there that are related to the SpEL vulnerability. This is a distinct issue and separate from them.
A similar vulnerability was used in the famous Equifax hack with devastating results, and Log4shell is in recent memory with equally devastating results.
Sonatype has fast-tracked the vulnerability and, if you have scanned your software with Sonatype Lifecycle, you'll receive automatic security alerts as a part of standard continuous monitoring. We have also produced intelligence on the SpEL vulnerability - if you have continuous monitoring turned on you are protected.
We have published a Find and Fix Spring4Shell article in our documentation to help deep dive into some of the options below.
You can also run a manual search on Sonatype Lifecycle to check if you're affected. You can use the following REST API call to IQ server to find the affected Spring-core versions:
You can use the below URL if you are authenticated into your Sonatype Lifecycle Server. You may need to URL Encode the request for it to work on Windows
http://localhost:8070/api/v2/search/component?stageId=release&componentIdentifier={"format":"maven","coordinates":{"groupId":"org.springframework","artifactId":"spring-beans","version":"*","extension":"*","classifier":"*"}}
Alternatively, Advanced Search is available inside the IQ server. A search term you can use is:
componentCoordinateArtifactId:spring-beans
Advanced Search screen
We have published a Find and Fix Spring4Shell article in our documentation. Please refer to it if you are a Sonatype Customer.
Spring have released patched versions 5.3.18 and 5.2.20 as well as remediated versions of Spring Boot. They are available on Maven Central. We recommend an immediate upgrade
Currently known forms of attack also seem to leverage running Spring applications on Tomcat. It is safe to assume that as understanding of the vulnerability evolves, so do forms of attack with increasing scope.
Other potential mitigations offered by Praetoriann include disallowing certain patterns.
Sonatype products are not affected by the Spring4shell vulnerability.