NICER Protocol Deep Dive: Internet Exposure of Redis

Welcome to the NICER Protocol Deep Dive blog series! When we started researching what all was out on the internet way back in January, we had no idea we’d end up with a hefty, 137-page tome of a research report. The sheer length of such a thing might put off folks who might otherwise learn a thing or two about the nature of internet exposure, so we figured, why not break up all the protocol studies into their own reports?

So, here we are! What follows is taken directly from our National / Industry / Cloud Exposure Report (NICER), so if you don’t want to wait around for the next installment, you can cheat and read ahead!

Redis (6379)

Even non-relational databases shouldn’t be on the internet!

TLDR

• WHAT IT IS: An in-memory key-value database created in 2009 with a special focus on scalability and performance.
• HOW MANY: 102,801 discovered nodes
• VULNERABILITIES: Twelve CVEs since 2013, but CVEs don’t tell the complete story about exposure for Redis.
• ADVICE: Use it! Just, y’know, don’t expose it to the public internet (especially since it was never meant to be exposed to the public internet).
• ALTERNATIVES: etcd and memcached are two similar, alternative in-memory key-value stores with characteristics similar to Redis.

Redis fundamentally reshaped or, at least popularized, the idea of having data that you need always resident in-memory and on-disk, with the sole purpose of the on-disk version to be that of rebuilding the in-memory version and for use in synchronization in high-availability configurations. It is immensely popular in the category of “NoSQL” databases and is used in production at Twitter, GitHub, and many other large-scale environments.

Finding Redis in cloud environments is no real surprise, since that’s where a great deal of public web applications reside today. Microsoft tops the list, as it relies heavily on Redis for its Azure Cache offering, and Amazon’s second-place finish is a result of direct AWS support for Redis and their Redis-compatible ElastiCache service.

But, if you’re looking at the cloud counts and thinking they seem low, keep reading, since we’ll speak to this in the Exposure Information section.

Exposure information

As noted in the TLDR, Redis has not had too many CVEs (one in particular was pretty bad), but the chief weakness of Redis is that—by default—it binds to all network interfaces. That means unless you go out of your way to secure a Redis instance or Redis cluster, anyone with access to the same network segment will be able to talk to it (we’ll come back to this statement in a bit). The developer of Redis, antirez, demonstrated that with just a little knowledge of how SSH works, it takes just about five seconds to gain remote access to an unsecured Redis instance.

Redis can be run on alternate ports, configured to require authentication, and wrapped in TLS tunnels to help secure the service, but it really has no business being on the internet. Since there are over 100,000 of them on the internet (on the default port), let’s see what state they’re in.

Redis Server State	Count	Percentage
Requires authentication	77,050	74.95%
Returned version	13,590	13.22%
Running protected	9,255	9.00%
Encountered error	2,765	2.69%
IP whitelisting	130	0.13%
Reported busy	11	0.01%

Given how easy it is to compromise a remote Redis instance, it is reassuring to see around 75% of these servers requiring authentication. We have no idea how strong those credentials are, since testing credentials without permission is verboten. It was also encouraging to see 9% of systems running in “protected” mode. Since version 3.2.0, when Redis is executed with the default configuration (binding all the interfaces) and without any password in order to access it, it enters a special mode called “protected mode” and will only reply to queries from the loopback interface and reply with an error message to queries from all other interfaces.

We were able to extract version and other information (via an INFO request) from around 13% of Redis instances and managed to count 112 different version strings. Thirty of them cover 90% of the discovered versions:

Redis Version	Count	Percentage
3.0.504	2,303	21.25%
3.2.12	1,314	12.12%
5.0.8	878	8.10%
5.0.7	843	7.78%
3.0.6	793	7.32%
3.2.100	728	6.72%
4.0.9	657	6.06%
3.0.503	364	3.36%
5.0.5	327	3.02%
3.0.501	235	2.17%
2.6.12	212	1.96%
2.8.17	191	1.76%
5.0.3	188	1.74%
5.0.6	175	1.62%
3.2.6	169	1.56%
4.0.14	160	1.48%
3.0.7	158	1.46%
3.2.8	122	1.13%
3.0.500	109	1.01%
2.8.4	106	0.98%
5.0.4	98	0.90%
2.8.19	93	0.86%
3.2.11	91	0.84%
2.8.23	85	0.78%
4.0.11	83	0.77%
3.2.9	81	0.75%
3.2.10	78	0.72%
3.0.5	72	0.66%
3.0.1	70	0.65%
4.0.10	55	0.51%

Part of the reason version 3.0.504 is so prolific is due to improperly secured TencentDB instances (that appears to be one of the versions it reports, though there are others). That version was also the last version released by Microsoft before Azure Managed Cache was shuttered.

One final thing to note here is that the most current version from these April 2020 studies was 5.0.8, and indeed, that is the third most common version of Redis. At the time of publication, though, Redis is already on version 6.0.5. Redis version numbers increment fast.

Attacker’s view

Given how easy it is to compromise an unsecured Redis instance, it stands to reason attackers do all sorts of terrible things to them, such as gaining a new host to perform other malicious actions from, holding them for ransom, or installing a cryptocurrency miner.

Project Heisenberg does not emulate Redis, but we can use attempted TCP connections to port 6379 as an initial, imperfect proxy to see whether attackers are, indeed, scouring the internet for exposed Redis nodes.

Since we saw that highly abnormal spike, and since Redis is one of those “you can shove as many commands into a single packet as you can,” type of protocols, our interest was piqued sufficiently to dig into the packet captures for that time period.

It turns out that we certainly did receive many Redis requests during that period, specifically in our Rackspace honeypot nodes, and that it appears someone misconfigured their Redis cluster replication configuration to include our Heisenberg IPs (at that time) and managed to send us ~5GB of web server log count data, making an average of 1,700 Redis PUBLISH requests an hour.

This is the perfect time for us to remind you to not only secure your Redis instances but also maintain draconian control over your cluster configurations, lest ye inadvertently leak 5GB of your own data to unsuspecting security researchers.

Our advice

IT and IT security teams should have well-established playbooks and automation for running Redis in production. They should also ensure developers configure Redis properly during application development to further ensure they aren’t exposing unsecured instances for attackers to take advantage of. No Redis instance should be internet-facing.

Cloud providers should ensure their managed Redis services are secured in their own defaults and make it super hard to run them insecurely. After all, Redis was explicitly designed to favor openness and usability over security. If machine images with Redis pre-installed are provided, those images should be updated with each Redis release, and users of those images should be notified they need to upgrade their deployed nodes.

Government cybersecurity agencies should provide guidance on running Redis safely and monitor for malicious actors attempting to gain a foothold on Redis systems.