New research shows 75% of ‘open’ Redis servers infected

Since our initial report on the RedisWannaMine attack that propagates through open Redis and Windows servers, we’ve been hearing about more and more attacks on Redis servers.
Redis is a great tool, it can serve as in-memory distributed database, cache or a message broker and is widely popular. Redis is aimed at high performance and in doing so, some other aspects of it occupy a slightly lower priority level.

(If attacks against databases including NoSQL ones such as Redis worry you, please check out our related webinar held with the International Information System Security Certification Consortium (ISC(2)), “Best Practices for Mitigating Data Breach Risks.”)

Browsing through the Redis security advisory there are three important facts:

1. “Redis is designed to be accessed by trusted clients inside trusted environments. This means that usually, it’s not a good idea to expose the Redis instance directly to the internet or, in general, to an environment where untrusted clients can directly access the Redis TCP port or UNIX socket.”
2. “While Redis does not try to implement Access Control, it provides a tiny layer of authentication that is optionally turned on editing the conf file.”
3. “Redis does not support encryption”

Simply put – Redis should not be publicly exposed as it has no default authentication and all the data is stored in clear text. We often see issues arise when people don’t read the documentation and migrate services to the cloud, without being aware of the consequences or the adequate measures that are needed to do so.
In order to understand the magnitude of the problem we set up publicly available Redis servers to serve as a honeypot, recorded the traffic and analyzed it. Within less than 24 hours, our servers started to register the first attacks – vulnerability scanners, simple crypto mining infections and crypto mining worms, like the one we saw in the aforementioned RedisWannaMine.
The attack anatomy is quite simple – the attacker sets a key/ value pair in the memory and then saves it to a file in the disk in a location that will force the file to run (e.g /etc/crontabs, /var/spool/cron/crontab etc.).
The image below illustrates the difference between a fresh Redis installation and an infected Redis.

Attackers usually set values that include commands to download external remote resource and run it. Another popular type of command is adding SSH keys, so the attacker can remotely access the machine and take it over (see Table 2).

Having let our honeypot collect data for some time, we noticed that different attackers use the same keys and/ or values to carry out attacks. As such, a shared key or value between multiple servers is a clear sign of a malicious botnet activity.
To check our theory, we decided to scan publicly available Redis servers and look for these keys and values that we saw in our honeypot data. We used a shodan query ‘port:6379’ to locate 72K Redis servers and scanned them. On one hand only 10K servers replied to our scan attempts without an error, but on the other hand, most of the servers that replied were infected with a malware.
The results are as follows:

Unsurprisingly, more than two-thirds of the open Redis servers contain malicious keys and three-quarters of the servers contain malicious values, suggesting that the server is infected. Also according to our honeypot data, the infected servers with “backup” keys were attacked from a medium-sized botnet ( ) located at China (86% of IPs).
In the last month alone, Imperva customers were attacked more than 75k times, by 295 IPs that run publicly available Redis servers. The attacks included SQL injection, cross-site scripting, malicious file uploads, remote code executions etc. These numbers suggest that attackers are harnessing vulnerable Redis servers to mount further attacks on the attacker’s behalf.

Private information exposed

As a side note; going through the huge amount of publicly available data, we found private SSH keys that can be used to access servers, certificates that can be used to decrypt network traffic, PII, and more sensitive data.

So, what can you do to protect yourself?

• Make sure you follow Redis Security notes, i.e.
  • Don’t expose your Redis to the internet
  • If possible, apply authentication
  • Don’t store sensitive data in clear text
• Monitor your Redis server to make sure it is not infected.
  You can monitor processes or CPU consumption to check if a crypto mining malware is running. You can also use the keys and values mentioned in the tables above to monitor the data stored in your Redis server.
• Make sure you run Redis with the minimal privileges necessary. Running it with root user, for example, is a bad practice, since it greatly increases the potential damage that an attacker can cause.
• Run Redis 4.X with “protected mode” on.

As we’ve said before, Redis is an awesome tool, with loads of benefits. That doesn’t mean it can be used without following recommended protocols to ensure safety. We hope this post shed some more light on how to operate Redis safely and will help you get the most out of it.