Return of the Unauthenticated, Unfirewalled protocolsMattias Geniar, Monday, January 23, 2017
People are starting to realise that having insecure, unauthenticated and unfirewalled services running on the internet is a bad idea. Who knew, right?
What started with a MongoDB ransom is quickly spreading to new services that are equally easy to "exploit".
It's already been covered in great detail that service defaults are tremendously important. I'm the kind of sysadmin that likes to be explicit in server configs, not trusting default settings. Some argue that it's pointless and a waste of time, that system packages have good sane default values.
Well here's a little packaging secret: the ones doing the packaging aren't necessarily the ones creating the software. It's often a voluntary job, helping others with good RPM or DEB packages to use. And while I'm certain packagers do a reasonable effort to create secure default values, they might be missing important gotcha's.
UX vs. Security
Case in point: if you install Memcached on a Red Hat or CentOS machine, it will by default listen to all interfaces.
Super convenient as most users run their Memcached services on different servers. It's good UX. But as Memcached is an unauthenticated protocol, it also allowed anyone to connect to your Memcached instance and read/write data to it, flush the cache, ... if it's not firewalled properly.
Where should the trade-off be between UX and security? In order for a technology to become widely adopted, UX is arguably more important. However, as adoption grows, everyone quickly realises that security should have been the priority.
MongoDB servers worldwide have been held ransom. Attackers have already moved on to other services like Redis & ElasticSearch.
I feel it's incredibly important to highlight these are data storage engines. They're databases. They hold your company's and clients' data. This is your business.
If you're going to secure any service, it had better be the ones holding all the data.
As an attacker, what else can you hold ransom? Or phrased differently: what other services hold important customer data that is worth extracting?
I'll give you some ideas:
- RabbitMQ, ActiveMQ, ZeroMQ, ...
Note that most of these services have support for authentication, it just needs to be configured explicitly.
In a way, these ransom attacks are a good thing: they raise awareness to the acute problem that is an unauthenticated and unfirewalled service.
There's nothing wrong with a protocol that doesn't support authentication. It probably does so for good reason (simplicity, performance, ...).
There's also nothing wrong with unfirewalled services, some just need this (think webservers, mailservers, ...).
But there is a problem when those are combined and start to hold important company data.
It's almost as if an entire new generation of sysadmins have come online, started a few services here and there and called it a day. That's not what sysadmins do. That might be something developers do when they lack time or resources to contact dedicated sysadmins.
Let's hope these recent attacks cause a shift in the way these services are managed and highlight the need for skilled sysadmins and managed services.