Use Redis? There’s a Good Chance It’s Been Co-Opted

Open source databases may have a problem. For the second time in just three years, a popular open-source database has become infected, on a massive scale, with cryptocurrency-related malware. In late 2016, the vector of the infection was MongoDB, and the source of the infection was ransomware. This year, the vector is Redis, another popular open-source database, and the source is crypto-mining malware.

Developers love open-source databases due to their flexibility, but two major incidents in such a short time is pushing it. What are the structural deficiencies that make these databases so vulnerable – and what can security professionals do to stem the bleeding?

Mapping the Redis Infestation

A recent study by the security firm Incapsula found that 75% of Redis servers are infected with malware designed to mine cryptocurrency. The time from setting up a vulnerable server to infection is now less than 24 hours. Not only were the servers themselves becoming infected, they were also being used as launchpads to attack other services.

An initial puzzling factor was the fact that Redis servers are not designed to be public-facing. In other words, a random user from outside a corporate network should not be able to navigate directly to a Redis implementation via the public internet. The fact that a large number of Redis servers appear to be public-facing regardless appears to be down to operator error. Many third-party Redis distributions are designed to be public facing by default – their administrators never bothered to set them to private.

Those currently running Redis should immediately check their servers for an assortment of malware and re-image where necessary. Although Redis does not ship with robust security tools (again, because it is designed to be used only on a LAN), it is possible to turn on an authentication layer, combine Redis with an SSL proxy, change default commands, and run Redis as an unprivileged user. These combined measures should make Redis safe – but they’re fixing the symptom, not the underlying problem.

Did we Learn Anything from MongoDB?

In late 2016 and early 2017, ransomware groups took over public-facing MongoDB implementations en masse. Over 30,000 databases were infected and deleted by ransomware, and 680TB of data was exposed. Like Redis, MongoDB has little in the way of built-in security protections – if you can access the database, you can change it. Unlike Redis, MongoDB was designed to be open to the internet by default – making it in some ways even less secure than its counterpart.

The MongoDB breaches were supposed to be a lesson for administrators – a simple, painful lesson. In brief, “don’t leave your mission-critical databases out in the open where anyone can modify them.” Yet in MongoDB, Redis, and even in AWS implementations, administrators are failing to check and correct for this critical error. What can be done?

It’s Time to Lock Down your Entire Perimeter – No Exceptions

The average enterprise runs hundreds of applications, each with its own set of permissions related to outside internet access. Although Redis and MongoDB are outliers because of the value of the data that they store, each of these other applications represents a vulnerability if it’s set to be public-facing. In other words, this is yet another problem where administrators have too many applications to monitor, and where a single mistake represents a potential data breach.

This best answer to this dilemma? Shut it all down. Safe-T Software-Defined Access helps administrators block every single one of your applications from the public-facing internet – without disabling their connectivity. Our Zero-Trust network segmentation model lets you keep your firewall 100% closed – with all of your applications behind it. Meanwhile, your users, customers, and vendors will still be able to access their tools, just as easily as if they were set to “public.” For more information, contact Safe-T today and ask for a free trial.