Cloud
Exposed Redis Instances Abused for Remote Code Execution, Cryptocurrency Mining
Recently, we wrote an article about more than 8,000 unsecured Redis instances found in the cloud. In this article, we expound on how these instances can be abused to perform remote code execution (RCE), as demonstrated by malware samples captured in the wild.
Recently, we wrote an article about more than 8,000 unsecured Redis instances found in the cloud. In this article, we expound on how these instances can be abused to perform remote code execution (RCE), as demonstrated by malware samples captured in the wild. These malicious files have been found to turn Redis instances into cryptocurrency-mining bots and have been discovered to infect other vulnerable instances via their “wormlike” spreading capability.
Redis, which is intended to be used in trusted environments, has a protected mode configuration and is set to be updated to a new version, Redis 6.0, which will introduce new security features such as access-control lists (ACLs). However, as of now, Redis users with instances that don’t bear Transport Layer Security (TLS) encryption, password protection, or both are susceptible to having over 200 commands available once attackers get inside the environment. At present, Redis does not have authentication set by default. And even if a password is set, it’s important to keep in mind that the password should be strong enough in order to be resistant to brute-force attacks.
We’ve observed attackers using these scenarios in a honeypot we’ve set up to attract and monitor attackers in the wild:
Scenario 1: Abusing the config command
An attacker sets several keys on a Redis database file as cron tasks. The database values follow a specification of cron (a daemon that executes scheduled commands) and crontab (a file that is used to schedule the execution of programmes) file formats.
Figure 1. Setting keys as cron tasks
Using the config command, the attacker sets the directory to /var/spool/cron and the dbfilename to a username (e.g., root) and saves the database (with the file name root).
Figure 2. Saving the database to cron directories
The content of the root file name looks like the screenshot below — basically a few readable lines written in the cron file format in between binary data.
Figure 3. What the cron file name looks like
Despite the fact that the file has a partly binary format, when cron is installed, it finds a valid entry and executes a downloaded shell script at the attacker’s discretion — all caused by an unsecured Redis instance.
Figure 4. An example of an RCE attack performed on an exposed Redis instance using cron
Scenario 2: Abusing the slaveof feature
The second approach is based on the fact that Redis can be used as a distributed database. In this approach, an attacker first crafts a malicious Redis instance and compiles a malicious Redis module. The crafted Redis instance becomes a master server that sends the slaveof command to the vulnerable instance. The attacker then initiates a full resync from the master and sends the malicious Redis module. Afterward, the module load command is triggered, effectively loading a backdoor inside the vulnerable Redis module. This technique was discussed by Pavel Toporkov, a security researcher, in his “Redis Post-exploitation” presentation at the ZeroNights conference in 2018.
It should be noted that starting with Redis 5.0, which was released in October 2018, Redis no longer uses the word “slave” and uses the replicaof command instead. However, for backward compatibility, the slaveof command still works for earlier versions.
Figure 5. An example of a malicious Redis module registering three commands
Figure 6. An example of a malicious Redis module’s deployment and command call
The malicious Redis module in this case downloads a version of the Kinsing malware, which then downloads and executes the XMRig Monero cryptocurrency miner.
Figure 7. XMRig cryptocurrency miner executed from Redis found to be consuming significant resources
An overview of observed malware samples
In this section, we highlight a few notable malware samples that have been distributed in exposed Redis instances via either of the aforementioned methods, and that have been caught by our honeypots.
Case 1: Multiplatform shell-based worm installing cryptocurrency-mining malware
The first in-the-wild malware we observed was a newer version of a piece of cryptocurrency-mining malware that was detected to have taken advantage of known vulnerabilities in the search engine Elasticsearch. This malware is a multiplatform worm: It has both Linux and Windows versions with a set of scripts written in shell and PowerShell, and some of its components are binaries written in Golang that have been compiled into executable files. The infection can be noticed in a modified cron file (as seen in Scenario 1) containing a link to an init.sh file.
Init.sh
This is the starting or initialisation script of the shell-based malware. The important function of this script is to uninstall, terminate, and kill various resource-intensive and competing processes. This script runs the following tasks:
- Uninstall the Alibaba Cloud service (an action that may have been inspired by this repository).
- Uninstall the Tencent agent (an action that may have been inspired by this repository).
- Delete various files and kill various processes and Docker instances.
- Kill processes that bear the same name as the modules used by this specific malware:
- sysguerd
- sh
- sysupdata
- networkservics
- If root, download and instal malware files into /etc/, otherwise, use /tmp/. These files are miner, miner config, watchdog, update, and scanner.
- Add persistence through updata.sh, which has the same contents as init.sh and is added to crontab.
- Instal a new Secure Shell (SSH) authorised key into /root/.ssh/authorised_keys:
- Block outgoing traffic to ports 3333, 5555, 7777, and 9999 using the iptables command iptables -A OUTPUT -p tcp –dport ???? -j DROP.
- Clear bash history.
- For all hosts (public keys of previously accessed servers) in /root/.ssh/known_hosts, and if the /root/.ssh/id_rsa.pub file exists (a file with the public key of a previously generated SSH key pair), SSH then tries to connect to all of these known hosts via ssh -oBatchMode=yes -oConnectTimeout=5 -oStrictHostKeyChecking=no. For each successfully connected instance, it will download and execute https://<server>/<path>/is.sh.
- Download and execute https://<server>/<path>/is.sh on the affected machine.
Is.sh
This is an installation script used for performing the following tasks:
- Kill the following running processes:
- redisscan (a process that recursively scans the keyspace of Redis 2.8)
- ebscan (a scan process that uses the masscan tool)
- redis-cli (Redis’s command line interface, which allows the sending of commands to Redis and the reading of the server’s replies directly on the terminal)
- barad_agent (a cloud-related service)
- masscan (a mass IP port scanner)
- .sr0
- clay
- udevs
- .sshd (an OpenSSH server process that listens to incoming connections)
- xig
- Instal the required software via apt-get or yum package managers. The required software includes redis-tools, iptables, wget, curl, and unhide.
- Kill hidden processes.
- Download and instal masscan and pnscan.
- Download and execute rs.sh.
Rs.sh
This malicious, custom-made script is used to perform scans for Redis instances, with the following actions. Redis instances usually listen on port 6379. Two publicly available scanners are used for performing the Redis scanning task.
- Block all incoming traffic to port 6379 and allow only incoming traffic from the localhost using the iptables command.
- Create a.dat file that contains the following contents. This method was described in Scenario 1.
- Scan port 6379 with pnscan. In this method, pnscan sends bytes *1\r\n$4\r\ninfo\r\n and looks for os:Linux in the response from the scanned machine.
- Scan port 6379 with masscan. The scan is run with the shard parameter to randomly choose one of 22,000 IP address subsets.
- Scan port 6379 with masscan. In this scan, IP addresses from ranges of private IP addresses and ranges belonging to Alibaba Cloud, Chinanet Shanghai, and China Unicom are used.
- Scan port 6379 with masscan and take known IP addresses from the current network interfaces (using the ip a command).
- For active Redis instances (found via the scanning tasks mentioned in 3 to 6), run:
redis-cli -h HOST -p PORT –raw -a PASSWORD –raw <content of .dat>
The list of weak passwords used include:
- empty password
- redis
- root
- oracle
- password
- p@aaw0rd
- abc123
- abc123!
- 123456
- admin
After a successful connection to the newly found Redis instance, the init.sh script is executed via Scenario 1 and the whole infection process is repeated.
With the exception of the analysed scripts above, this malware also uses a few binaries.
The watchdog process, which is a Golang-based compiled file, functions mainly to start four watchdog threads:
- main_dog_protect_cron_thread
This cheques persistence in cron, and if necessary, adds persistence.
- main_dog_protect_process_thread
This cheques if required processes are running, and if not, starts them.
- main_dog_update_thread
If new versions are available, this updates the miner, config, scanner, and watchdog binaries.
- main_dog_protect_cc_thread
This cheques if a command-and-control (C&C) server is active. If it’s not, this looks for a hard-coded address via the Ethereum blockchain explorer.
The blockchain data is then transformed to the new C&C server address, which is a very useful feature especially when attackers lose their control of the current C&C servers. After a new C&C address is obtained, the thread cheques if the server is active. If it is, the thread appends a hard-coded string with a URL path and downloads the init.ps or init.sh initialisation scripts, and the whole infection process starts again from the beginning.
As of the publication of this article, there are no transactions associated with the hard-coded Ethereum address.
The scanner process, which is a Golang-based compiled executable, contains a set of exploits for various online services and devices.
The main_scan procedure calls the following scanning methods:
- scan_exp_Cctv_exploit
- scan_exp_Redis_exploit
- scan_exp_Drupal_exploit
- scan_exp_Hadoop_exploit
- scan_exp_Spring_exploit
- scan_exp_Thinkphp_exploit
- scan_exp_Weblogic_exploit
- scan_exp_Sqlserver_exploit
- scan_exp_Elasticsearch_exploit
Alibaba Cloud Security made an analysis of the scanner module with a list of exploits that is almost identical to the list above, with the addition of a new CCTV exploit routine.
It’s important to note that there is also a version of Case 1 for Windows using PowerShell; the Task Scheduler is used for persistence, while netsh and net user are used for adding backup entries to the system.
Case 2: Kinsing malware
The Kinsing malware supports several commands and functions, and has capabilities for both scanning of vulnerable machines and backdoor features. The function main_getTask queries <server>/get/ and enables the execution of a task.
The function main_doTask then implements the following commands:
| Command | Function |
|---|---|
| scan | TCP scanner |
| update | Downloads new bot version and runs it |
| exec | Runs from command line |
| masscan | Downloads and scans with masscan |
| exec_output | Runs from command line; output is POSTed to <server>/o |
| Socks | Socks proxy |
| backconnect | Connects to another machine using TCP |
| request | Performs HTTP request |
| tcp | Performs TCP request |
| download_and_exec | Downloads and executes |
| redis_brute | Brute-forces Redis instances |
The communication with a C&C server is encrypted with a hard-coded Rivest Cypher 4 (RC4) password, and the URL path depends on the type of request it sends:
- /get = get task
- /h = health
- /getT = get targets
- /l = log
- /o = execute output
- /r = result of the task
- /s = send socks
- /mg = get cryptocurrency miner’s process ID (PIC), e.g., {“Pid”:110}
- /ms = send cryptocurrency miner’s PID
Figure 8. Decrypting of a received response to /get path
The function main_minerRunningCheck runs in sequence with main_getMinerPid, main_isMinerRunning, and main_minRun, which first kills a currently running process called kdevtmpfsi, and then drops and runs the miner. This malware instals the XMRig malware and names it kdevtmpfsi.
The function main_healthChecker regularly cheques if a C&C server is present by sending the GET request to <server>/h. An RC4-encrypted response returns OK if everything is fine.
The function main_resultSender tries to POST the results of which tasks are completed to <server>/r. Communication is also RC4-encrypted.
Conclusion and security recommendations
Proper security measures should be taken, especially within the DevOps environment. Keeping Redis instances unsecured may lead to RCE, techniques for which are actively searched for and exploited in the wild by malicious actors. In this article, we discussed how exposed Redis instances can be abused for cryptocurrency mining, which is a relatively noisy process that uses a significant amount of resources in an affected device. However, this may not be the be-all and end-all of the possible abuse surrounding exposed Redis instances, as the ability to execute code is an attacker’s holy grail. Once RCE becomes possible, it can be the first big and detrimental step for malicious actors toward conducting stealthier and more targeted attacks.
For developers, here are several security recommendations for keeping environments better protected:
- When running server-side software, make sure that it is not running under root Even when running containers, users must follow best practises and apply the principle of least privilege.
- Keep your software updated to the latest version and use strong passwords. Don’t expose it to the internet without applying proper security measures.
- If you are inspecting Redis logs, you can see ongoing attacks from its actual lines. In the screenshot below, pay attention to the full resynchronisation request from the master. The replica received about 55 kB from the master, which is exactly the size of the malicious Redis module.
Trend Micro’s cloud security solutions
- The Trend Micro Hybrid Cloud Security solution simplifies security for organisations, allowing them to focus on security and compliance as they migrate to the cloud or adopt DevOps. It provides an all-in-one solution that has the breadth, depth, and innovation required by cloud security, and a single platform for visibility into leading environments like Amazon Web Services (AWS), Microsoft Azure, Google Cloud, and Docker.
- The Trend Micro™Cloud One™ software-as-a-service (SaaS) platform provides organisations with real-time security for workloads, applications, containers, serverless environments, file storage systems, and networks, and a single-pane-of-glass view of their hybrid cloud environments.
- The Cloud One platform also includes Cloud One – Conformity, which has automated controls for AWS ElasticCache, which is an in-memory data store for Redis. It ensures that Redis isn’t on the default port and has encryption for data while in transit and at rest.
- For organisations looking for runtime workload and container security or container image security as software, the Deep Security™and Deep Security Smart Check solutions can scan container images during pre-deployment and at runtime.
Trend Micro™ Deep Security™ and Vulnerability Protection protect users via the following rules:
- 1010231 – Redis Cron Remote Code Execution Vulnerability
- 1009967 – Redis Unauthenticated Code Execution Vulnerability
Trend Micro™ TippingPoint® protects customers through the following rules:
- 37633: TCP: Redis Crontab Command Injection Vulnerability
Indicators of compromise
| File | Function | SHA-256 |
|---|---|---|
| clean.bat | Add user script | 19967f6467f05f1ac286eb8b8bf7e251075b7d288fbe9b719b8de0b6330c8787 |
| config.json | Miner config | 2c2438019c10352cc6678474072coe57a4191fd6coe54391d4975012f587bec1a0 |
| init.ps1 | Init script | d0a28e1f768c524ed3ff962c36ab2861705cdd4fd83ee5b3dc8d897f2034cb05 |
| init.sh | Init script | 3c7faf7512565d86b1aec4fae2810b2006b75c3476b4a5b955f0141d9a1c237d38 |
| is.sh | Instal script | 6faa026af253c784ef97ffec3a9953055d394061a9a1fbfdcc5b28445b73ffdc |
| kdevtmpfsi | XMrig | 24FDF5B1E1E8086031931F2678D874487316DC1E266581B328D6E34A1FD7748C |
| kinsingbRiXVrNDJc | Bot | d247687e9bdb8c4189ac54d10efd29aee12ca2af78b94a693113f382619a175b |
| networkservics | Scanner | ea55a206f7047f54a9e97cc3234848dfd3e49d0b5f9569b08545f1ad0e733286 |
| networkservics.exe | Scanner | b6fc454e667081c2add1ffd5a54bafb428a82d8d8a3e34c61fc59075118f4afd |
| red2.so | Redis module | 1fd17076800d993609a8110084f9652d06fae50cd3a279ab709c65a044076fae6d |
| rs.sh | Redis spreader | e2b982f9540304e31ca8d1cdafb253da7d216d1cc939a281a1a95baaa4be9b2d |
| sysguerd | Watchdog | bceee7d9ace363ef2bfb1494a9784a6377fae14c4c5fefa0c180fcec33a5d1716 |
| sysguerd.exe | Watchdog | 37ecccdfc185615d4452b5c77b7313222b14776c3032c156846258c8f63185fae |
| sysupdata | Miner | e7446d595854b6bac01420378176d1193070ef776788af12300eb77e0a397bf7 |
| sysupdata.exe | Miner | 559a8ff34cf807e508d32e3a28864c687263587fae4ffdcefe3f462a7072dcc74 |
| updata.ps1 | Update | d0a28e1f768c524ed3ff962c36ab2861705cdd4fd83ee5b3dc8d897f2034cb05 |
| updata.sh | Update | 3c7faf7512565d86b1aec4fae2810b2006b75c3476b4a5b955f0141d9a1c237d38 |
Multiplatform worm C&C servers
- https://178[.]157[.]91.26
- https://45[.]137[.]151.106
Kinsing C&C servers
- https://45[.]10[.]88.102
- https://91[.]215[.]169.111
- https://139[.]99[.]50.255
- https://193[.]33[.]87.220
- https://195[.]123[.]220.193
Updated as of 7 p.m. PT to update Trend Micro solutions.