Cloud
More Than 8,000 Unsecured Redis Instances Found in the Cloud
We discovered 8,000 Redis instances that are running unsecured in different parts of the world, even ones deployed in public clouds.
Save to Folio
We discovered 8,000 Redis instances that are running unsecured in different parts of the world, even ones deployed in public clouds. These Redis instances have been found without Transport Layer Security (TLS) encryption and are not password protected. Redis, according to its developers, is originally intended to be used only in trusted environments. However, when left unsecured and allowed to be internet-facing or integrated into internet of things (IoT) devices, cybercriminals can find and abuse Redis servers to launch attacks such as SQL injections, cross-site scripting, malicious file uploads, and even remote code execution, among others. Threat actors can also view, access, and modify stored data in exposed Redis instances. In a previous case, a fake ransomware called Fairware targeted 18,000 unsecured Redis instances on hacked Linux servers.
We’ve reached out to Redis and they’ve shared that Redis has a protected mode configuration, which has been available since Redis 4.0 version and was released in July 2017. This special configuration was also backported to an earlier version, Redis 3.2.0. The protected mode kicks in when Redis is executed with the default configuration without any password protection. In this special mode, Redis will only reply to queries from the loopback interfaces and an error message is sent to other clients attempting to connect to Redis from other IP addresses. This is an extra protective measure that aims to lessen the chances of unsecured Redis instances being accessed from external networks. Redis cautions, however, that despite the error messages being sent in the protected mode, system administrators can still ignore these messages, manually bind all of the interfaces, or even disable protected mode completely.
Redis also shared that the stable version of Redis 6.0, which they plan to release in April 2020, will feature Access-control Lists (ACLs) and TLS, to help significantly improve Redis’s security capabilities.
What is Redis?
Redis, which stands for Remote Dictionary Server, is a popular open-sourced in-memory data structure store that is used as a database, cache, and message broker. Because Redis resides in-memory, it can deliver sub-millisecond response times to a multitude of applications that require on-demand responses in large volumes, such as chat and messaging, financial services, healthcare, and gaming, among others.
Redis has a wide user base — in fact, its official Docker Hub image has over 1 billion downloads at the time of writing — and is used by companies such as GitHub, Craigslist, and Twitter. Redis is also being used in cloud deployments, allowing organizations to save on cloud database calls via caching.
It is also increasingly becoming a popular tool for DevOps engineers who use microservices and containers. In 2018, it was reported that 900 million containers are running on Redis compared to the 650 million using MongoDB, another well-known database program. Through DevOps, developers and IT teams are able to create compliant and secure applications, hence, each layer of the production and deployment process — including data structures such as Redis — must be kept secure.
A closer look at unsecured Redis instances
Using Shodan, a popular search engine for internet-connected or IoT devices, we discovered over 8,000 unsecured Redis instances deployed worldwide. Some of these unsecured Redis instances were deployed in public clouds such as AWS, Azure, and Google Cloud.
A note on Shodan scan results: Any mention of cloud service providers in this research does not suggest any issue or vulnerability with the related service but only that it is searchable in Shodan.
As with any cloud type and deployment, it’s imperative to note that security is a shared responsibility — the cloud infrastructure is secured by cloud providers while the data, applications, and OS are secured by the user.
Figure 1. Shodan scan results for unsecured cloud deployments of Redis — those without TLS encryption, password protection, or both — running in different cloud providers
Note: We listed only the cloud providers that have 50 or more unsecured instances.
Figure 2. Geographical distribution of deployed unsecured Redis instances
Redis’s general security model is described in their official documentation, which states that:
“Redis is designed to be accessed by trusted clients inside trusted environments. This means that usually it is 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.”
This means that the recommended use of Redis — whether for database, cache, or messaging system purposes — involves the use of a mediator or an ACL layer between Redis and requests made by untrusted sources. Hence, it should not be directly connected to the internet.
By default, Redis listens in on the Transmission Control Protocol (TCP) port 6379. Similar to other known protocols like the Simple Mail Transfer Protocol (SMTP), this communication protocol is plaintext-based. There is also an option to encrypt data using TLS; however, this is not Redis’s default setting. Redis users are responsible for ensuring that TLS is enabled.
It is important to note that when TLS is enabled in a Redis server, it is securing the communication transport channel. This means that threat actors won’t be able to sniff data while it’s being transmitted. However, even when TLS is enabled, it doesn’t protect Redis servers against unauthorized access.
To enable authentication, the configuration option requirepass must be set, which can be done inside redis.conf or by executing CONFIG SET requirepass password command. However, the password is stored in plaintext, meaning everyone who can read the configuration can disclose the password. When set, users need to authenticate their session with a password using the AUTH command before performing other Redis commands.
It should be emphasized, however, that even though authentication is set using the AUTH command, the password can still be sniffed over the network when TLS is not enabled.
Figure 3. An example of network traffic capture when TLS encryption is not enabled
Until Redis 6.0 (Beta), which was released on March 5, 2020, Redis had not implemented ACL that can allow access to specific user roles and limit access to critical Redis commands for non-administrators. To limit the risk of allowing normal users to execute critical commands, Redis recommends two methods — disabling commands or renaming commands into unguessable names.
However, we recommend disabling commands completely rather than renaming them as it is more effective than security by obscurity. Redis users can disable commands completely by renaming it to an empty string.
Figure 4. Example of disabling CONFIG command using the rename-command
When Redis servers are left exposed, malicious actors could abuse the following commands to target Redis instances or the applications relying on them:
This command performs an invalid memory access that crashes Redis. During the development stage, this command is used to simulate bugs. When abused, it can allow an attacker to perform a denial of service attack as it can shut down any running Redis instance. We believe that this command shouldn’t be available in development builds.
This command executes a LUA script inside the server context. Fortunately for Redis users, security measures are in place — the LUA engine is sandboxed, putting restrictions on certain functionalities. Critical libraries are not loaded (such OSs), mitigating remote code execution attacks, while functions such as loadfile and dofile are also disabled, ensuring that arbitrary files are not read. Despite these security measures, this command may still be a potential attack vector for malicious actors.
Both the GET and SET commands have legitimate use cases, which are retrieving or modifying data. However, in the wrong hands, these commands can be used to influence the behavior of a dependent application, such as leaking data or modifying access tokens.
This command is capable of emptying or deleting all the keys — or data items that identifies records within a database — existing in all databases. If the FLUSHALL command is maliciously or accidentally used, it can wipe out all the keys or all data that exists in the entire server and not just in one database (the command FLUSHDB deletes keys in a particular database). This can result in data loss, especially if data on Redis is not properly backed up. It can also cause a service error on an app.
This command displays requests processed by the server, which is helpful for bug-spotting during production. However, threat actors can also abuse it to sniff users’ traffic as well as the types of traffic being sent and received on their machines. When network logs can be seen, cybercriminals can gain insight into which machines are sending and receiving mission-critical documents and use the information for illicit attacks.
Figure 5. An example of the MONITOR command at work
Security recommendations: Keeping Redis instances protected
To ensure that Redis instances are kept secure while leveraging performance and simplicity benefits, we recommend the following security steps:
- Identify where you want to deploy Redis (whether on the cloud, in a Kubernetes cluster, etc.) and identify access roles or the people who need to be able to access it.
- Make sure that the environment is properly secured, disallowing other deployments to interfere with Redis, e.g., by dumping its process memory.
- Use TLS together with password authentication.
- Keep watch over the execution of commands. Commands like DEBUG SEGFAULT and MONITOR need not be executed inside a production environment.
- Observe proper network segmentation when using containers. Redis instances should not be exposed to other containers that don’t require access to them.
- Do not use Redis in the frontend development, leaving it exposed to malicious actors. Redis should not have a connection using JavaScript inside a browser. Instead, we recommend using Redis on the backend.
Meanwhile, Redis Enterprise, a distributed NoSQL database engine that adds to Redis with an enhanced deployment architecture, provides added security controls for compliance and has security recommendations for securing data against cyberthreats. According to Redis, Redis Enterprise does not allow users to run databases without password protection and supports TLS configuration, client-side authentication, as well as other security features.
Trend Micro’s Cloud Security Solutions
The Trend Micro Hybrid Cloud Security solution simplifies security for organizations, 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, Microsoft Azure, Google Cloud, and Docker. The solution features automated deployment and discovery, extensive API integration, and security technologies to meet operational efficiency, security, and compliance needs.
The Trend Micro™ Cloud One™ SaaS platform provides organizations with real-time security for workloads, applications, containers, serverless, 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 strengthens organizations’ cloud security posture by running automated compliance checks to ensure that they adhere to regulations and industry standards such as PCI, GDPR, HIPAA, and NIST. Cloud One – Conformity also features a knowledge base, a continually growing library that contains checks that run against AWS and Microsoft Azure accounts and provides step-by-step remediation rules to rectify any failures. Cloud Conformity 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 organizations 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 predeployment and at runtime.