Redis, is a popular open source data structure tool that can be used as an in-memory distributed database, message broker or cache. The tool is not designed to be exposed on the Internet, however, researchers spotted tens thousands Redis instance publicly accessible without authentication.
The researcher Victor Zhu detailed a Redis unauthorized access vulnerability that could be exploited to compromise Redis instances exposed online.
“Under certain conditions, if Redis runs with the root account (or not even), attackers can write an SSH public key file to the root account, directly logging on to the victim server through SSH. This may allow hackers to gain server privileges, delete or steal data, or even lead to an encryption extortion, critically endangering normal business services.” reads the post published by Zhu on September 11, 2022.
The experts found evidence that demonstrates the ongoing hacking campaign, threat actors attempted to store malicious crontab entries into the file “/var/spool/cron/root” using several Redis keys prefixed with the string “backup.” The crontab entries allowed the attackers to execute a shell script hosted on a remote server.
The shell script was designed to perform the following malicious actions:
The researchers used a recent list of unauthenticated Redis services running on TCP port 6379 to run a one-time scan that looked for the existence of the key “backup1” on every host. Censys found that out of the 31,239 unauthenticated Redis servers in this list, 15,526 hosts had this key set. These instance were targeted by threat actors with the technique described above.
Most of the Internet-exposed Redis servers are located in Chine (15.29%) followed by Germany (14.11%), and Singapore (12.43%).
“Still, this does not mean that there are over 15k compromised hosts. It is improbable that the conditions needed for this vulnerability to be successful are in place for every one of these hosts. The primary reason many of these attempts will fail is that the Redis service needs to be running as a user with the proper permissions to write to the directory “/var/spool/cron” (i.e., root).” concludes the report. “Although, this can be the case when running Redis inside a container (like docker), where the process might see itself running as root and allow the attacker to write these files. But in this case, only the container is affected, not the physical host.”
The report also includes a list of mitigation for these attacks.
Follow me on Twitter: @securityaffairs and Facebook
(SecurityAffairs – hacking, mining)
Post expires at 5:19pm on Wednesday March 22nd, 2023