Threat actors are actively targeting exposed instances of SSH and Redis Redis open-source data store with a peer-to-peer self-replicating worm with versions for both Windows and Linux that the malware authors named P2Pinfect.
Written in Rust, the malware relies on at least two methods to establish foothold: a critical vulnerability disclosed and patched last year, and a feature that allows replicating the main database for high availability and to counter failover scenarios.
Exploiting Redis replication feature
P2PInfect was initially documented by researchers at Palo Alto Networks’ Unit 42, who found that it exploited the maximum severity vulnerability tracked as CVE-2022-0543.
The security problem is a Debian-specific LUA sandbox escape vulnerability due to a packaging issue that allows remote code execution, with a critical severity score of 10 out of 10.
After compromising a vulnerable Redis instance with an initial payload, P2PInfect downloads new OS-specific scripts and malicious binaries and adds the server to its list of infected systems.
The malware then adds the infected server to its peer-to-peer network so that future compromised Redis servers can access the bundle of malicious payloads.
Researchers at cloud forensics and incident response company Cado Security also found on their honeypot a P2PInfect sample, which included both Portable Executable (PE) and ELF binaries, which indicates cross-platform compatibility between Windows and Linux.
The sample they analyzed also used a different initial access route by exploiting the Redis replication feature that allows the creation of exact replicas of the main/leader Redis instance.
“A common attack pattern against Redis in cloud environments is to exploit this feature using a malicious instance to enable replication” – Cado Security
A threat actor can achieve this by connecting to an exposed Redis instance and issuing a specific, documented command; the method dates since 2018 and has been used in multiple campaigns.
source: Cado Security
Prepping for botnet assimilation
According to Cado Security, the primary payload is an ELF binary “written in a combination of C and Rust” that ultimately executes the Rust component of the payload.
After execution, the binary updates the SSH configuration of the host and modifies the OpenSSH server configuration “to a near default state” that allows the attacker to connect to the server via the secure shell (SSH) protocol and enables password authentication.
Cado Security says that the threat actor then restarts the SSH service and added an SSH key to the list of authorized keys for the current user.
In the next step, the attacker uses a bash script to modify the names for the wget and curl binaries, checks for the presence of specific utilities, and installs them if not available.
The list below shows some of the actions resulting from running the script:
- Renames the wget and curl binaries to wgbtx and clbtx respectively. This is likely an attempt to hinder any incident responders from using them to pull down forensics tools, as well as preventing EDR solutions from detecting the usage of the command. This is a common TTP for cloud threat actors.
- Checks for the iptables command, and installs it if it is not found. It has several commands specific to individual package managers, so it can be installed regardless of the Linux distribution in use.
- Checks for the awk command, and installs it if it is not found. Like the previous command, it will try to use several package managers.
- Checks for the netstat command, and installs it if it is not found. Like the previous commands, it will try to use several package managers.
- Uses netstat and awk to collect a list of all IPs that are currently connected to the Redis server running on the target host.
- Adds an iptables rule to allow traffic from each of these IPs to the Redis server.
- Adds an iptables rule to deny all other traffic to the Redis server.
- Adds an iptables rule to allow all traffic to a randomly chosen port that the primary payload listens on for botnet communications.
The researchers explain that the use of iptables may be to prevent other attackers from compromising the vulnerable Redis server. They add that the malware also establishes persistence on the compromised host.
Following this step, the infected server receives at least one binary that can scan through /proc and opens the stat for each process there. It can also monitor the /proc directory for changes.
Additionally, the binary can upgrade the main binary of the malware and execute it if its signature does not match the one pulled from the botnet.
The researchers say P2PInfect treats each compromised Redis server as a node, turning the network into a peer-to-peer botnet that can receive instructions without the need for a centralized command and control (C2) server.
“It is assumed that commands are issued by propagating signed messages across the network,” Cado Security researchers say.
A simple HTTP server enables communication between peers over a random port between 60100 and 60150, as well as receiving certain payloads. However, botnet coordination is done over HTTPS using a hardcoded certificate.
Based on this certificate, Cado Security assesses that the campaign started “on or after June 29th.”
Finding vulnerable servers
Infecting more hosts is done after checking the bash history to pull available IPs, users, and SSH keys to exclude from the search.
The malware selects a random /16 network prefix and starts scanning for exposed SSH and Redis servers. It accesses weakly-protected hosts using a list of passwords for brute-force attempts.
With Redis servers, P2PInfect will try to exploit CVE-2022-0543 or the replication feature to load malicious modules on the host.
Palo Alto Networks researchers said that at the time of their research that there were more than 307,000 Redis instances reachable over the public internet. While not all of them may be vulnerable, P2PInfect is likely to test them for weaknesses or vulnerabilities and compromise them.
At this moment the purpose of P2PInfect remains unclear. Neither Palo Alto Networks nor Cado Security researchers were able to determine the reason behind infecting Redis servers.
One potential clue to the purpose of P2PInfect is the presence of a binary called “miner,” which could point to cryptocurrency mining activity.
However, Cado Security observed that the file was executed and then deleted but no evidence of cryptomining. Instead, it just kept making the sleep syscall, which is doing nothing.
This may be just the initial stage of the campaign and additional functionality, possibly cryptomining, will be added after a sufficient amount of Redis instances have been compromised.
Source: www.bleepingcomputer.com