Spring4Shell [CVE-2022-22965]: All you need to know

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:

1. JDK v9+
2. Tomcat Apache versions below 10.0.20, 9.0.62, and 8.5.78
3. The application is packaged as a WAR
4. Using Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older
5. 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):

• https://semgrep.dev/s/rotem-cider:initbinder-indicator
• https://semgrep.dev/s/rotem-cider:spring-controller-exists
• https://semgrep.dev/s/returntocorp:initbinder-indicator

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:

class.module.classloader.resources.context.parent.pipeline.first.pattern=

Alternatively, vendors are releasing detection rules for their offerings:

• Akamai
• AWS
• Citrix
• Cloudflare
• F5
• Fastly
• Fortigate
• Imperva‍

Next, monitor the application's root for the inclusion of any web backdoors.

How you can identify exploitation

Tooling

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.

‍

Detection Rules

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:

index=web_apps (sourcetype=nginx OR sourcetype=webapp_firewall) status=200
| rex field=url "(?<webShell>\/.*\.(jsp|class)\?.*=.*)"
| rex field=uri "(?<webShell>\/.*\.(jsp|class)\?.*=.*)"
| where isnotnull(webShell)
| eval Domain = mvappend(dest, domain), fullURL = mvappend(url, uri)
| table _time src_ip Domain status method webShell fullURL sourcetype

Semi-Trusted Source - Splunk rules by Alex

Trusted Source: Community YARA rules for detection by Florian Roth

Vulnerable Application to Sandbox attacks against

Pre-reqs:

• Docker
• Python3 + requests library
• Curl

git clone https://github.com/reznok/Spring4Shell-POC
cd Spring4Shell-POC/
docker build . -t spring4shell && docker run -p 8080:8080 spring4shell
python3 exploit.py --url 'http://localhost:8080'
curl 'localhost:8080/shell.jsp?cmd=id'

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.

References

• 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

Timeline

• 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.

‍