A closer look at CVE-2022-22965
The Spring Framework is a platform that provides a comprehensive architecture for Model-View-Controller-based (MVC) applications designed to decrease manual configuration and improve memory management. Implementing some design patterns uniformly makes the code more reusable and easy to maintain. This is the driving factor behind using the Spring framework to develop Enterprise-level spring boot and spring cloud applications.
The recent vulnerability CVE-2022-22965 points out that Data Binding might expose a Spring MVC or Spring WebFlux application running on Java Development Kit 9+ (JDK) vulnerable to Remote Code Execution (RCE). The exploit requires the program to execute as a Web Application Resource (WAR) deployment on Tomcat.
The program is not vulnerable to the exploit if it is deployed using the default Spring Boot executable jar. However, the vulnerability can be exploited through various approaches by a TA who is familiar with it.
The patch for CVE-2010-1622 can be bypassed because Java Development Kit (JDK) versions 9 and above have two sandbox restriction methods, which enable exploitation.
If the below conditions are satisfied, a remote attacker can access an AccessLogValve object. This is done via the parameters of the framework’s binding feature using malicious field values to trigger pipeline mechanisms and write to files in arbitrary locations.
Prerequisites for exploitation of the vulnerability require the victim system to be running:
- JDK 9 or higher
- Apache Tomcat as the Servlet container
- Packaged as WAR
- spring-webmvc or spring-webflux dependency
- Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions
When specific objects or classes are accessible under certain conditions, a vulnerability is created. Request parameters are frequently bound to a Plain Old Java Object (POJO) that is not annotated with RequestBody. This aids in the extraction of parameters from HTTP requests.
The RequestBody annotation is used to indicate whether a method parameter should be bound to the body of the HTTP request.
An attacker can trigger the flaw by using the Spring framework’s getCachedIntrospectionResults function, incorrectly exposing the class object while binding the parameters shown in the original proof of concept script. Refer Figure 1.
By including the class variable in the requests, malicious actors can gain direct access to an object. As a result, by just following the property chains, they can access a surplus of additional valuable objects on the system.
The attacker can make changes to AccessValveLog by creating a .jsp file in the service’s root directory.
The properties mentioned below can be modified by an attacker, as shown in Figures 2 & 3:
Directory: The location of the access log relative to Tomcat’s root directory. This can be altered to point to a location accessible via HTTP requests – such as the directory of the web application.
Prefix: The name of the access log file’s prefix.
Suffix: The suffix of the name of the access log file. The log file’s name is a combination of the prefix and the suffix.
Pattern: A string that describes the structure of a log record. This can be adjusted so that each entry has a JSP web shell.
FileDateFormat: Setting this causes the new access log settings to take effect.
The .jsp file now contains a payload with a password-protected web shell in the format shown in Figure 4, allowing the attacker to execute further commands.
Cyble Research Lab’s Global Sensor Intelligence network indicated malicious activity linked to the SpringShell vulnerability (CVE-2022-22965). The heat map below depicts the geographic distribution of the scanner IP addresses that we have observed thus far. Our analysis indicates that the United States is being heavily targeted, followed by the Netherlands and Germany by TAs leveraging this vulnerability.
SpringShell is used to inject a JSP web shell into the web root of the web server via a specially designed request, allowing threat actors to remotely execute commands on the server.
It was observed that threat actors leverage their remote access to download and execute Mirai to the “/tmp” folder, as shown in Figure 6.
The Threat Actors behind SpringShell download numerous Mirai samples for different CPU architectures and run them using the wget.sh script, as shown in Figure 6.
Until this month, various Mirai botnets were among the few persistent exploiters of the Log4Shell (CVE-2021-44228) vulnerability, utilizing the bug in the widely used Log4j software to recruit affected devices into its DDoS botnet. It is probable that botnet operators are currently experimenting with other vulnerabilities that could have a significant impact, such as SpringShell, to gain access to new device pools.
These assaults could potentially expose the victim to ransomware attacks and data breaches. Thus, Mirai resource hijacking for denial of service or crypto-mining appears relatively innocuous in comparison.
- Upgrade to the latest Spring framework version.
- Upgrade Apache Tomcat to the latest released versions 10.0.20, 9.0.62, and 8.5.78, which rectify the attack vector on Tomcat’s side.
- Upgrade to spring framework 5.3.18 and 5.2.20, which contain the fixes, have been released.
- Downgrade to Java 8 as a viable workaround if upgrading the Spring Framework or Apache Tomcat is not viable.
- Keep operating systems and application software up to date.
- Use a strong password policy.
- Cyber security awareness training programs are a must for employees of the organization.
Indicators of Compromise (IOCs)
|184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124||IP addresses|