Spring4Shell [CVE-2022-22965]: What it is and how to detect it
What is Spring4Shell (CVE-2022-22965)?
Spring4Shell (CVE-2022-22965) is a critical vulnerability (CVSSv3 9.8) targeting Java’s most popular framework, Spring, and was disclosed on 31 March 2022 by VMWare. The vulnerability affects Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, as well as all older versions. For an application to be fully vulnerable to the currently (13/04/2020) known vectors, the additional pre-requisites will be required:
- JDK v9 or above
- Apache Tomcat versions below 10.0.20, 9.0.62, and 8.5.78
- The application must be packaged as a WAR (in contrast to a Spring Boot executable jar).
- Utilising either the spring-webmvc or spring-webflux dependencies.
What does the Spring4Shell vulnerability enable attackers to do?
The Spring4Shell vulnerability allows attackers to execute arbitrary code on the application server where a number of pre-requisites are met.
Now that we've had some time to assess the impact, and despite the initial furore online, we're happy with our initial gut feeling that this was not going to be as impactful as Log4j due to the number of pre-requisites. We like to be evidence-based, and since the disclosure of this vulnerability, we have used various detection techniques against our clients' assets (>25,000). As of today (13/04/2022), we have yet to find a vulnerable application. Though with the caveat that the community accepted detection method similar to @_teedge's work has thrown some false positives. These individual occurrences have been marked down as WAF intervention or specific application quirks (non-Java apps throwing an HTTP 400).
As with any vulnerability, things could change the moment a bypass or alternative route of exploitation is disclosed. As such, we continue to monitor the impact of this vulnerability as it develops and will provide further updates when required.
How to detect Spring4Shell
From an external perspective, identifying the vulnerability can be very tricky due to the several pre-requisites. However, @_tweedge on Twitter has put together a simple payload that can induce a HTTP 400 error as shown below:
From an internal perspective, there are two methods.
The first is to identify if the target application/system meets the following:
- JDK v9+
- Tomcat Apache versions below 10.0.20, 9.0.62, and 8.5.78
- The application is packaged as a WAR
- Using Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older
- Utilising either the spring-webmvc or spring-webflux dependencies
The second option is to refer to rules which the community is collating for open source SAST software, such as SemGrep rules (source):
How you can fix the Spring4Shell vulnerability
The most effective solution to fix the Spring4Shell vulnerability is to upgrade to Spring Framework 5.3.18 and 5.2.20.
If you are unable to upgrade the Spring Framework, there are a handful of workarounds that you can deploy. These are either:
- Downgrade JDK to version 8
- Upgrade Tomcat to 10.0.20, 9.0.62 or 8.5.78
- Implement blocklists within the application to prevent the calling vulnerable functionality. More information and examples can be found within the Spring Framework blog post here.
How you can defend against exploitation
There are two steps you can take to defend against exploitation.
Firstly, include WAF rules for indicators that attacks are attempting to exploit the application. The current known attack vectors revolve around the modification of Tomcat's logging capabilities. This can be matched through the following string:
Alternatively, vendors are releasing detection rules for their offerings:
Next, monitor the application's root for the inclusion of any web backdoors.
How you can identify exploitation
There has been a number of tooling releases since the initial post, these include Nmap detection scripts, plugins for open source scanners such as Nuclei, additionally all of the major vulnerability management vendors should have detections in place including Intruder.
We have gathered tips from three sources: one trusted; one semi-trusted and one untested.
UNTESTED Source – a west-wind has built some Splunk rules for detection:
Detect requests that attempt to change logging within Tomcat:
Detect a weaponised payload based off the basic proof of concepts available:
Semi-Trusted Source - Splunk rules by Alex
Trusted Source: Community YARA rules for detection by Florian Roth
Vulnerable Application to Sandbox attacks against
- Python3 + requests library
Spring4Shell scanner: how Intruder is helping
We are doing all we can to help Intruder customers and are closely monitoring the situation as it develops.
In addition, we're running exploratory checks for our Vanguard customers and sending them security advisories if any issues are detected. Internal checks are already available, we recommend scheduling a security scan to review the security of your systems.
Intruder offers a 14-day free trial, where you can run unlimited scans to check your system for multiple vulnerabilities, including Spring4Shell weaknesses.
- Lunasec's writeup of the vulnerability and impact analysis: https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
- Spring's Announcement: https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement
- Mitre CVE Page: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22965
- Example vulnerable application within a docker container, along with a working exploit to execute: https://github.com/reznok/Spring4Shell-POC
- CERT Coordination Center Spring4Shell Info - https://www.kb.cert.org/vuls/id/970766
- Nationaal Cyber Security Centrum (NCSC-NL) Spring4Shell Guidance - https://github.com/NCSC-NL/spring4shell
- 30/03/2022 1030 hrs - Security team aware of early reports of a Spring Core RCE 0-day disclosure via GitHub via a Chinese researcher. Security team began monitoring the developments.
- 30/03/2022 2310 hrs - Security team note the first proof of concepts were available. The team note that there are several payloads getting mixed up between the Core RCE and Cloud Function vulnerabilities.
- 31/03/2022 0853 hrs - Security team note that a number of pre-requisites are required which may lower the impact of the vulnerability.
- 31/03/2022 0935 hrs - Security team research an exploit chain and monitoring developments online.
- 01/03/2022 1000 hrs - Security team begin enumerating Vanguard web servers on TCP ports 80,443,8080,8443 in preparation for widefield testing.
- 01/03/2022 1630 hrs - Security team created a threat assessment document internally, outlining the vulnerability, impact, IOC's, mitigations and guidance.
- 01/03/2022 1700 hrs to 04/04/2022 0900 hrs - A number of known payloads were attempted over the weekend vs Vanguard clients. No customers were identified as vulnerable, but due to the nature of the exploit and lack of insight into the source code of applications, these external checks will never be fully comprehensive.
- 04/04/2022 1100 onwards - Additional manual scans with improved detection capability started against Vanguard client systems. Investigatory work is ongoing into client's systems and environments to ascertain the impact.
- 05/04/2022 1700 hrs - Vanguard team completed using various detection techniques against Vanguard clients. No vulnerable targets identified.
- 07/04/2022 1200 hrs - Automated mass scanning of all Pro and Vanguard customers was initiated.
- 08/04/2022 0900 hrs - Security team noted that online discussions of the vulnerability had started to weaken by using tooling such as CVETrends.com.
- 13/04/2022 1400 hrs - Updates collated for the blog post now that we've had some time to assess the impact to our clients.
- Raw CVE Coverage
- Risk Rating Coverage
- Remote Check Types
- Check Publication Lead Time
- Local/Authenticated vs Remote Check Prioritisation
- Software Vendor & Package Coverage
- Headline Vulnerabilities of 2021 Coverage
- Analysis Decisions
Red teamers, security researchers, detection engineers, threat actors have to actively research type of vulnerability, location in vulnerable software and build an associated exploit.
Tenable release checks for 47.43% of the CVEs they cover in this window, and Greenbone release 32.96%.
Red teamers, security researchers, detection engineers and threat actors now have access to some of the information they were previously having to hunt themselves, speeding up potential exploit creation.
Tenable release checks for 17.12% of the CVEs they cover in this window, and Greenbone release 17.69%.
The likelihood that exploitation in the wild is going to be happening is steadily increasing.
Tenable release checks for 10.9% of the CVEs they cover in this window, and Greenbone release 20.69%.
We’re starting to lose some of the benefit of rapid, automated vulnerability detection.
Tenable release checks for 9.58% of the CVEs they cover in this window, and Greenbone release 12.43%.
Any detection released a month after the details are publicly available is decreasing in value for me.
Tenable release checks for 14.97% of the CVEs they cover over a month after the CVE details have been published, and Greenbone release 16.23%.
With this information in mind, I wanted to check what is the delay for both Tenable and Greenbone to release a detection for their scanners. The following section will focus on vulnerabilities which:
- Have CVSSv2 rating of 10
- Are exploitable over the network
- Require no user interaction
These are the ones where an attacker can point their exploit code at your vulnerable system and gain unauthorised access.
We’ve seen previously that Tenable have remote checks for 643 critical vulnerabilities, and OpenVAS have remote checks for 450 critical vulnerabilities. Tenable release remote checks for critical vulnerabilities within 1 month of the details being made public 58.4% of the time, but Greenbone release their checks within 1 month 76.8% of the time. So, even though OpenVAS has fewer checks for those critical vulnerabilities, you are more likely to get them within 1 month of the details being made public. Let’s break that down further.
In Figure 10 we can see the absolute number of remote checks released on a given day after a CVE for a critical vulnerability has been published. What you can immediately see is that both Tenable and OpenVAS release the majority of their checks on or before the CVE details are made public; Tenable have released checks for 247 CVEs, and OpenVAS have released checks for 144 CVEs. Then since 2010 Tenable have remote released checks for 147 critical CVEs and OpenVAS 79 critical CVEs on the same day as the vulnerability details were published. The number of vulnerabilities then drops off across the first week and drops further after 1 week, as we would hope for in an efficient time-to-release scenario.
While raw numbers are good, Tenable have a larger number of checks available so it could be unfair to go on raw numbers alone. It’s potentially more important to understand the likelihood that OpenVAS or Tenable will release a check of a vulnerability on any given day after a CVE for a critical vulnerability is released. In Figure 11 we can see that Tenable release 61% their checks on or before the date that a CVE is published, and OpenVAS release a shade under 50% of their checks on or before the day that a CVE is published.
So, since 2010 Tenable has more frequently released their checks before or on the same day as the CVE details have been published for critical vulnerabilities. While Tenable is leading at this point, Greenbone’s community feed still gets a considerable percentage of their checks out on or before day 0.
I thought I’d go another step further and try and see if I could identify any trend in each organisations release delay, are they getting better year-on-year or are their releases getting later? In Figure 12 I’ve taken the mean delay for critical vulnerabilities per year and plotted them. The mean as a metric is particularly influenced by outliers in a data set, so I expected some wackiness and limited the mean to only checks released 180 days prior to a CVE being published and 31 days after a CVE being published. These seem to me like reasonable limits, as anything greater than 6 months prior to CVE details being released is potentially a quirk of the check details and anything after a 1-month delay is less important for us.
What can we take away from Figure 12?
- We can see that between 2011 and 2014 Greenbone’s release delay was better than that of Tenable, by between 5 and 10 days.
- In 2015 things reverse and for 3 years Tenable is considerably ahead of Greenbone by a matter of weeks.
- But, then in 2019 things get much closer and Greenbone seem to be releasing on average about a day earlier than Tenable.
- For both the trendline over an 11-year period is very close, with Tenable marginally beating Greenbone.
- We have yet to have any data for 2021 for OpenVAS checks for critical show-stopper CVEs.
With the larger number of checks, and still being able to release a greater percentage of their remote checks for critical vulnerabilities Tenable could win this category. However, the delay time from 2019 and 2020 going to OpenVAS, and the trend lines being so close, I am going to declare this one a tie. It’s a tie.
The takeaway from this is that both vendors are getting their checks out the majority of the time either before the CVE details are published or on the day the details are published. This is overwhelmingly positive for both scanning solutions. Over time both also appear to be releasing remote checks for critical vulnerabilities more quickly.