Trend Micro’s security researchers discovered roughly 8,000 unsecured Redis instances that were exposed to anyone with an Internet connection.
Spread all over the world, the unsecured instances were found to lack Transport Layer Security (TLS) encryption and without any password protection. Some of these instances were even deployed in public clouds.
An open source, in-memory data structure store, Redis (Remote Dictionary Server) was designed for use within trusted environments. Thus, if left unsecured and Internet-accessible, Redis instances are prone to all kinds of abuse, including SQL injections, cross-site scripting attacks, and even remote code execution.
Moreover, cybercriminals able to connect to unsecured deployments can view, access, and modify stored data, and upload malicious files. Several years ago, the FairWare ransomware targeted over 18,000 unsecured Redis instances.
A protected mode configuration has existed since Redis 4.0, which was released in July 2017, and was also backported to Redis 3.2.0. This protection is automatically enabled when Redis is executed in default configuration without password protection.
When in this mode, Redis only replies to queries from loopback interfaces and sends an error message to other clients attempting to connect. However, admins might still ignore the message and manually bind all of the interfaces, or even disable the protected mode completely.
Redis is highly popular, with its official Docker Hub image registering more than 1 billion downloads to date, Trend Micro’s security researchers point out.
With the help of Shodan, a search engine for Internet-connected devices, the researchers identified over 8,000 unsecured Redis instances worldwide, some in public clouds such as AWS, Azure, and Google Cloud.
By default, Redis listens in on TCP port 6379, which is plaintext-based, without providing an option to encrypt data using TLS. On the other hand, Redis users have the possibility to enable TLS and secure communications, yet that would only ensure that data is secured while in transit, and will not protect the deployment against unauthorized access.
On exposed Redis servers, malicious actors can abuse commands to crash the installation (denial of service), execute a LUA script inside the server context, retrieve or modify data, empty or delete all the keys, and sniff users’ traffic.
To keep their Redis instances secure, admins should make sure that deployments are properly secured and that only authorized users have access to them, use TLS together with password authentication, keep an eye on the execution of commands, apply network segmentation when using containers, and avoid using Redis in the frontend development.
Related: Cryptomining Campaign Targets Linux Servers with Go Malware
Related: New ‘Xwo’ Malware Looks for Exposed Services, Default Passwords
Related: Over 18,000 Redis Instances Targeted in FairWare Attacks
