The recently discovered Spring4Shell vulnerability, which impacts an estimated 16% of organizations worldwide, has been leveraged to spread Mirai botnet malware in recent attacks.
Security researchers with Trend Micro report that a recent attack campaign focusing on organizations in Singapore is using Spring4Shell in this way, racing to hit as many vulnerable devices as possible before patches are applied to them.
Spring4Shell hackers racing to target Linux devices
Spring4Shell is a remote code execution (RCE) vulnerability discovered in the Spring Core Java framework. Spring Core is highly popular due to its flexible modular and lightweight nature; as many as 78% of organizations worldwide are estimated to be making use of it in some way in their technology environment. However, only a relatively small subset of those organizations are vulnerable to Spring4Shell due to it requiring a particular set of conditions to be in place to be exploitable. Still, it impacts a considerable amount of systems and should be a patching priority for any organization.
Mirai botnet malware has been a persistent and dangerous threat since at least 2016. The malware targets devices running Linux and ropes them into botnets that can be very large. The creators of the original botnet were busted in 2018, but the Mirai botnet malware’s source code has since been published and there are many smaller variants that remain in the wild. Mirai is particularly pernicious as it focuses on attacking smaller and more poorly defended targets, particularly consumer Internet of Things (IoT) devices that may have little to nothing in the way of security and can be harnessed to further spread the malware.
The perpetrators of the current campaign remain unknown, but seemed to have a particular focus on organizations in Singapore before expanding their horizons. The Trend Micro researchers say that the attacks began almost as soon as the Spring4Shell vulnerability became public knowledge at the end of March. The systems that were exploited in Singapore were generally either running one of the older and vulnerable versions of Spring Framework or Apache Tomcat.
After successfully exploiting Spring4Shell on a target device, the attackers download a Mirai sample to the server’s “tmp” folder and make use of the “chmod” command to change its permissions and make it executable. Once a system is compromised the attackers essentially have full access to it, though it is unclear at this point if the attackers are doing anything more than collecting botnet components. Mirai botnets are primarily used for distributed denial of service (DDoS) attacks, but some recent pandemic-era derivatives have been observed using chunks of the Mirai botnet malware code to steal files via IoT devices. Botnets are also sometimes used to mass distribute phishing emails or in “brute force” password guessing campaigns.
Microsoft and Checkpoint have been tracking exploitation attempts in the wild and have not seen any other large-scale successes for Spring4Shell as of yet. However, a recent analysis by Palo Alto Networks’ Unit42 threat intelligence group anticipates Spring4Shell being adapted to much more than just Mirai botnet malware. Much of the cloud infrastructure world rests on Linux, and compromised IoT devices can serve as a pathway into these systems.
Log4Shell is something of a comparable case, in that it is part of a Java software package that is in extremely wide use and is difficult for many organizations to completely patch out of existence. Log4Shell is much easier to exploit, however, and Sophos believes that awareness campaigns combined with quick global action kept it contained to a great degree. It was used to successfully exploit some organizations, but the mass exploit of it that was feared when it was announced has yet to materialize. Given a general downward arc of attack attempts since January, it appears that Spring4Shell could also be similarly contained if impacted organizations take remediation as seriously.
Mirai botnet malware may only be opening salvo
The recent incidents with the Mirai botnet malware are very likely not the end of Spring4Shell as an attack tool, but it serves as ample warning of the need to patch the vulnerability out as soon as possible.
Defense against any future exploitation of Spring4Shell is as simple as updating, at least in most cases. The vulnerability can only be exploited when running on Java Development Kit (JDK9) under an Apache Tomcat web server. Updating Spring Framework to versions 5.3.18 or 5.2.20 and Spring Boot to versions 2.6.6 or 2.5.12 solves the issue.
But there are some cases where this may not be possible. An alternate solution is to update Tomcat to 10.0.20, 9.0.62 or 8.5.78. If for some reason neither of these things can be done, downgrading to JDK8 is also a potential solution as the command Spring4Shell relies on was not yet present in that version.
But as Chris Olson (CEO of The Media Trust) notes, patching only solves the current problem of the day: “In the face of Log4Shell, many organizations rolled out patches to protect their internal systems and consumer-facing services. But the emergence of Spring4Shell reminds us that patching is only a temporary fix: as long as organizations are depending on third-party assets for website, app and backend development, they must exercise continual vigilance and monitoring to protect their users.”
And as Saryu Nayyar (CEO and Founder of Gurucul) observes, the patching process for remediating Spring4Shell could potentially take a long time given how frequently it tends to appear in software: “Until vulnerabilities such as these can be patched, which can take weeks or months, organizations need to augment their threat detection, investigation and response programs to determine if they are already under attack and certainly find any signs of an attack early in the kill chain. This can allow them to perform emergency patching on systems if threatened. However, this requires a solution not only with advanced analytics and non-rule-based machine learning models to detect any variations employed when Mirai is executed, but also threat intelligence combined with risk analytics to prioritize and escalate to security teams once the attack is potentially found. These capabilities are critical for accelerating response and rallying security teams to identify and focus efforts on a serious active threat. Unfortunately, most current SIEM and XDR solutions lack this combination of features to be enough to stop this attack so organizations must look at more advanced solutions to better enable security teams.”
