SophosLabs has detected a new DDoS botnet targeting poorly secured SSH servers. Called Chalubo (or ChaCha-Lua-bot) in honour of its use of the ChaCha stream cipher, the malware started circulating in August before seeing an activity spike in early September.
The malware’s purpose is to compromise the large global population of Linux servers running SSH (Secure Shell) for remote admin, which these days includes the expanding population of Internet of Things (IoT) devices.
It does this by scanning large IP address ranges looking for devices running SSH on port 22, attempting to brute force the credentials using common defaults or by trying weak passwords.
In Chalubo’s case, the ultimate goal is to download and run malware designed to launch Distributed Denial of Service (DDoS) attacks using DNS, UDP, and SYN floods.
In the example analysed by SophosLabs, the target appeared to be a single Chinese IP address but in principle it could be any network.
Given clues hidden in its design, the IoT theme seems clear, as Timothy Easton of SophosLabs points out:
Like some of its predecessors, Chalubo incorporates code from the Xor.DDoS and Mirai malware families.
Where did it come from?
SophosLabs noticed the attacker’s command-and-control (C&C) server retrieving a second piece of malware, Linux/DDoS-BD (Linux/BillGates), which has been connected to the Chinese Elknot botnet first seen in 2014.
However, if Chalubo has a larger theme it would be SSH itself, which is supposed to be a secure way to remotely manage just about anything running Linux.
Unfortunately, SSH is not always well secured, which makes it at best an inviting target, and at worst a liability, given that SSH can be used not only for shell logins but also for proxy tunnelling and file transfer.
What to do?
One way to spot Linux/Chalubo-A, is to look for outbound C&C traffic on port 8852, although this isn’t always used. It might also be possible to detect its presence by checking logs for failed logins or paying attention to whether servers have been eating an unusual amount of bandwidth.
Prevention is even better – by securing SSH. As with all brute-forcing attacks, Chalubo thrives when it finds default or weak credentials, cycling through lots of known examples or possible combinations.
There are lots of tweaks to minimise SSH brute-forcing but setting a strong password is the obvious first step. Better still, stop using passwords and use an SSH key authentication instead, which has the added advantage that it can be used across different servers.
Indicators of compromise (IoCs) for the malware components and payload URLs can be found in the SophosLabs analysis.
Frank
A few other hardening techniques would be to use a different port number than 22 for Internet facing ssh access.
If practical, set up the firewall to only allow remote ssh access from a specific IP or range of IPs.
Don’t permit root login via ssh.
Use something like Denyhosts that bans ssh access via a specific IP when the password is guessed wrong x amount of times.
Bryan
Good points Frank.
Be aware DenyHosts intrinsically relies on TCP wrappers, which is depreciated (and which OpenSSH stopped supporting [IIRC] last year). You can still use wrappers with 3rd party patching, but I’ve not tried that–nor would I believe it’s ideal.
Best use of DH now is its detection, the PLUGIN_DENY directive triggering another utility–thereby firewalling an offending host.
Valdis
Let the servers be defended by legal codes of them own. And let block the oversignals from shit .😁
Anonymous
Seriously, key only access. So many ways to harden.