The Shellshock bugs — there are six related CVE designations — have the highest severity rating of 10. They exist in the Unix Bash shell, which is the default command-line interface on all Linux, Unix, and Mac-based operating systems. If successfully exploited, Shellshock could enable an attacker to cause Bash to execute arbitrary commands and gain unauthorized access to many internet-facing services, such as web servers, that use Bash to process requests.
Vulnerable software under active attack
The top three vulnerabilities currently being targeted with Shellshock attacks are in the chart below. They highlight how vulnerabilities can lurk for years undetected in the software supply chain.
A device could be running the latest version of firmware, yet still be vulnerable, because the people creating that software did not update the libraries in their supply chain.
CVE-2019-7481 is a 7.5 rated SQL injection vulnerability in a security service for which a patch exists. CVE-2021-42071 is a critical 9.8 rated vulnerability in a visual tool application that could allow an unauthenticated attacker to achieve remote command execution.
Installing Mirai botnet variants
CVE-2019-7481 has been targeted since at least 2021 by attackers trying to install Mirai botnet variants. The Mirai botnet comprises a vast number of hacked connected (IoT) devices and is used predominantly to launch DDoS attacks.
Since Mirai first came to the forefront in August 2016, researchers have seen multiple variants appear on the threat landscape. Mirai primarily targets IoT Linux-based devices. Most of the attacks start by downloading a shell script that then downloads several platform-specific malware binaries and attempts to run them. Once infected, the device becomes part of the growing botnet.
The first two Mirai variants that we saw in our logs were going after the LuCI web interface for OpenWRT-based routers. This is a management interface that should not be exposed to the internet. Unfortunately, it often is, and attackers use this to their advantage.
The first variant was used by attackers trying to execute a shell script named “sorry.sh”.
This script is no longer available. According to URLhaus, it has been reported and taken down. However, the analysis on URLhaus makes it clear that this is part of a Mirai/Gafgyt infestation attempt. A more detailed description is available on VirusTotal.
The second variant is still active.
The attackers using this variant delete everything in the root directory and then download a shell script in /tmp.
The shell script when executed downloads several platform-specific binaries and then executes them in order.
The developer of this specific script appears to have a sense of humor. The downloaded files are renamed using an escalating series of insults (duly censored in the screenshot.)
A different Mirai/Gafgyt variant was targeting a remote command execution vulnerability in Zyxel routers. The URLhaus entry shows that this was also a Mirai “infector” (huhu.mips) — though it is now offline. Looking at the entry for the IP address, it is currently serving the malware with a new name (skyljne.mips.)
Cryptominer infections targeting vulnerabilities
In addition to Shellshock, we have seen attackers targeting vulnerabilities to install cryptominers.
Back in 2022, we saw cryptominers attempting to exploit the then-new Atlassian Confluence vulnerability. In February 2024, we are seeing active attempts to exploit years-old ThinkPHP vulnerabilities and install XMRig miners.
The first URL we saw was:
Decoding the partial base64, we find the following command:
This shows up on ANY.RUN as the XMRig miner. At the time of writing this blog, the miner is still online.
An analysis of this shell script on ANY.RUN shows that it downloads the Redtail binary as well.
A third example of this is the same 45.x IP serving a different script:
This decodes to:
Per VirusTotal, this is likely a miner too.
A final example of the miner is this one:
This decodes to:
The name of the miner in this case is not obfuscated and is directly identifiable as XMRig. It is currently offline.
All the miner examples are targeting older ThinkPHP vulnerabilities — remote code execution (RCE) vulnerabilities from 2018 and 2020 that should rightfully be patched by now.
Keeping your applications secure
These types of attacks come and go in waves, with each wave — both for Mirai and for cryptominers —targeting specific vulnerabilities in campaigns.
Around 10 years ago, attackers mainly looked for and used newer vulnerabilities such as zero days to try to get into the network. This has shifted to attackers working smarter, not harder. They’ve caught onto the fact that software supply chains are rarely fully secure, and they are using older but still unpatched vulnerabilities to their advantage.
The software supply chain security issue is quite difficult to solve — you could deploy the latest version of your file transfer software, but under the hood that software might be using a vulnerable version of Log4J. You assume your application is secure, but it has a known vulnerability. And the only way to find this out is if you are running regular vulnerability scans. In the case of Log4J, you are likely doing this. But what happens if the vulnerability is in a relatively unknown library that is only used in this one software?
The old defense-in-depth advice remains relevant. Having a defensive “onion” for your network and applications is crucial to preventing attacks before they can reach your application. This approach will also give you time and aircover for when you have not yet been able to patch a new zero-day.
Protection against DDoS also remains critical. Attackers are using years-old vulnerabilities to create their botnets and perform newer types of DDoS attacks such as HTTP/2 Rapid Reset. Having a solution in place that can stop older volumetric DDoS attacks, and newer, subtler application DDoS attacks is critical for business continuity.
If you look at the vulnerabilities mentioned above, such as shellshock bugs, and in our recent application security Threat Spotlight, you see that when it comes to applications, the software supply chain is a weak link that needs and deserves a significant protective layer.
Photo: Cagkan Sayin / Shutterstock
