Researchers Discover Eight Thousand Unprotected ‘Redis’ Instances Online

• A large number of unprotected Redis instances were discovered online, sitting in popular public cloud services.
• Eight thousand of them are not password-protected nor using TLS encryption. 
• Redis is constantly trying to introduce fail-safes, but administrators ignore or disable them.

Trend Micro researchers report that they have discovered about 8,000 Redis instances that are not password protected and which don't use TLS encryption. These instances are spread all over the world, and some are deployed in public clouds. All of them are indexed by specialized search engines, such as Shodan. Redis stands for "Remote Dictionary Server," and it is an open-source database structure, cache, and message broker. It is particularly high-performing in terms of response times, which are valuable in gaming, financial services, chat apps, etc. Twitter is using Redis, while Amazon, Microsoft, Google, and Alibaba offer it as an option for their cloud services. However, it is only meant to be deployed in trusted environments.

Source: Trend Micro

By scanning deeper, Trend Micro has figured that most of the unsecured Redis instances were deployed in AWS, as shown in the above image. According to the Redis official deployment recommendations, these instances shouldn't even be exposed to the internet in the first place, let alone be online without a TLS and password protection. Redis has introduced a special "protected mode" in version 4.0 and even backported it to 3.2 to help negligent admins set up protections when they don't assign any passwords. However, some administrators ignore the error messages or even disable the "protected mode" to stop the message from irritating them.

One key problem is that Redis isn't using TLS by default, so it is up to the administrator to enable this option. Even when TLS is active, though, malicious actors could potentially access the Redis servers if a password hasn't been set. Another implication arises from the scenario of having set a password, but not having enabled TLS. In this case, an actor could potentially sniff the password, as that would be communicated in plaintext form over the TCP port 6379.

Source: Trend Micro

And then there is the issue of the lack of command execution limitations assigned to specific user categories. All versions prior to Redis 6.0 don't offer this security feature, so even non-admin users are allowed to execute critical commands. For those who haven't upgraded to that version - which is pretty recent (March 2020) anyway, Redis recommends to rename the commands and to use names that can't be easily guessed. Another resolution would be to disable the commands altogether by renaming them into an empty string. Other than that, you are advised to use TLS encryption together with password authentication, monitor command execution events, and avoid using Redis in the frontend development.