No Log4j, But Spring4Shell Exploitation Attempts IncreaseSecurity Firms Track Attempts; Mirai Becomes 1st Known Successful Exploitation Case
This story has been updated to include reference to Trend Micro's report of a successful exploitation of Spring4Shell.
A week after the Spring4Shell vulnerability was first found, security companies - including Microsoft, Check Point and Akamai - have detected attempts to exploit the vulnerability, and Trend Micro has confirmed the first successful attempt - the Mirai botnet leveraging CVE-2022-22965 for its malicious operations.
Spring4Shell requires very specific conditions to be exploited, with several security experts deeming its impact to be lower than the more easily-exploited Log4j vulnerability. Nonetheless, the steady rise in exploitation attempts has pushed the U.S. Cybersecurity and Infrastructure Security Agency to warn organizations to patch this remote code execution vulnerability at the earliest opportunity.
This week, CISA added the Spring4Shell or Spring Framework JDK 9+ RCE vulnerability to its "Known Exploited Vulnerabilities Catalog." CISA has assigned a deadline of April 25, 2022, for all federal civilian agencies to identify and remediate the vulnerability on their information systems.
The Spring Framework RCE vulnerability, which is tracked as CVE-2022-22965, affects the Spring MVC and Spring WebFlux applications running on JDK 9+. "The specific exploit requires the application to run on Tomcat as a WAR deployment. If the application is deployed as a Spring Boot executable jar, i.e. the default, it is not vulnerable to the exploit. However, the nature of the vulnerability is more general, and there may be other ways to exploit it that have not been reported yet," a Spring blog post says.
Experts initially feared exploitation of this vulnerability in similar volumes to Log4j/Log4Shell. Log4j was deployed in Java-based logging frameworks used in a multitude of custom applications, while Spring4Shell compromised the Java Development Kit widely used by developers for modern-day application development purposes. The differentiator between the two is that Log4j affected Java 6/7/8 while Spring4Shell affects only JDK 9+ and has a very specific set of conditions.
VMware, which owns Spring, says the following conditions need to be met in a system for successful exploitation of the Spring Framework vulnerability:
- Use a Java Developer Kit of version 9 or higher;
- Use Apache Tomcat as the servlet container;
- Have its applications packaged as WAR;
- Have "spring-webmvc" or "spring-webflux" dependency.
Mirai Botnet Using Spring4Shell
In the first known large-scale operation successfully targeting the Spring4Shell vulnerability, Trend Micro has confirmed finding the Mirai botnet leveraging the CVE-2022-22965 for its malicious operations. "The exploitation allows threat actors to download the Mirai sample to the '/tmp' folder and execute them after permission change using
'chmod'," Trend Micro's researchers say.
In Unix and Unixlike operating systems, chmod is the command and system call used to change the access permissions of file system objects sometimes known as modes.
Like other security companies, Trend Micro started observing Mirai botnet samples attempting exploitation at the beginning of April. The primary targets of this campaign are vulnerable servers, specifically in the Singapore region, the researchers say.
The Trend Micro researchers also found several other variants of Mirai that are suited for different CPU architectures on the malware file server.
All the variants are fetched using the
'wget.sh script', and those that are unsuccessfully run due to their incompatibility with the victim's architecture are deleted from the disk after the initial execution stage, the researchers say.
Trend Micro has shared a list of indicators of compromise so security teams can keep an eye on this particular campaign.
Early Exploitation Attempts
Security companies have been reporting a rise in exploitation attempts.Microsoft Sees 'Low Volume'
In a security blog published earlier this week, Microsoft confirmed that it had detected a "low volume of exploit attempts" targeting the critical Spring4Shell vulnerability across its cloud services.
Microsoft says the attempts closely align with the "basic web shell PoC" that it addresses in the blog and adds that its threat hunting team is monitoring the threat landscape associated with the Spring vulnerabilities and has not seen a significant increase in quantity of attacks or new campaigns.
But analysis by researchers at cybersecurity firm Check Point shows a different scenario.
Check Point Sees Steady Rise
In the first weekend since the Spring4Shell vulnerability was discovered and a working proof of concept started making the rounds on several forums, Check Point Research says it spotted nearly 37,000 attempts to allocate the Spring4Shell vulnerability. The company says this means that during the first four days since its discovery, exploitation attempts were made on 16% of the affected organizations worldwide.
Check Point's researchers say that the most targeted region for the exploitation attempts was Europe at 20%, followed by Australia and New Zealand at 17%, Africa at 16% and Asia at 15%. Of all the regions, North America has experienced the least Spring4Shell exploitation attempts - 11% - they say, adding that the global average is 16%.
Software vendors, at 28%, are the most affected industry, the Check Point researchers say.
Akamai Sees Exploitation Attempts on Day One
Will Dormann, a vulnerability analyst at the CERT Coordination Center, confirmed a working exploit on Twitter the same day that VMware announced the Spring4Shell vulnerability.
In a security blog, Akamai researchers say that some of the first exploit attempts they noticed were attackers trying to deploy a webshell that attackers could later access to execute arbitrary commands on the server, potentially infecting it with other malware, or to spread within the targeted network.
Log4Shell vs. Spring4Shell
Brian Fox, CTO of software firm Sonatype, tells Information Security Media Group there are some "notable differences" between Log4shell and Spring4Shell, but a report from application testing firm Veracode paints a different picture for enterprises.
According to Veracode, 95% of its enterprise customers or organizations with over 100 applications use Java. The company's recent analysis of Log4Shell revealed that 58% of their enterprise customers using Java use a vulnerable version of Log4Shell while 89% use a vulnerable version of Spring4Shell.
"One reason that the number is higher for Spring Beans is because older, nonvulnerable versions of Spring Beans, such as Version 2.x, are rarely used anymore, while older, nonvulnerable versions of Log4j, such as Version 1.2, were still commonly used at the time of that CVE disclosure," Veracode says.
Apart from these reports, Bad Packets, a cyberthreat intelligence team, has also raised flags about mass scanning activities from multiple IPs and TOR exit nodes, especially from Russia, Ukraine, the U.S. and India.
Tools to Detect and Remediate Spring4Shell
Microsoft customers can now search for CVE-2022-22965 to find vulnerable devices through the Weaknesses page in threat and vulnerability management of Microsoft Defender for Endpoint. And Microsoft Sentinel customers can use a set of three specific queries listed here to detect any threat activity related to the Spring4Shell vulnerability.
Check Point and Akamai have also taken precautionary actions and are now protecting their customers from possible exploitation attempts through their respective products.
Since the vulnerability mostly affects application developments, application security provider WhiteSource has launched a free developer tool that is now available on GitHub. The tool provides developers with the exact path to direct and indirect dependencies, along with the fixed version, for speedy remediation, WhiteSource says.
"Organizations and security teams must approach Spring4Shell with the same attention and urgency they did with the recent Log4j vulnerability," says Rami Sass, CEO of WhiteSource. "This vulnerability highlights the importance of a proactive approach to software security and the need for more automated application security to be baked into the development life cycle. Ensure you are handling your technical debt, and update."