NoSQL Ransoms Spreading Further

Once again, I’m hijacking a normal posting schedule to talk about the ongoing NoSQL crisis. Last week I talked about attackers taking MongoDB ransom here, here, and here. Even after posting, the list has grown, and unfortunately more than 100TB of data is gone.

Unfortunately, now it looks like the ransom has spread to Elasticsearch as well. Yesterday, a post on the Elastic forums describes a user who discovered a warning index that contained a ransom note:

Here’s a sample of what the ransom note looks like:

Screenshot of ransom index created in an Elastic instance

It looks as though the attackers are demanding 0.2 BTC, the same amount as the majority of MongoDB ransoms. The attackers are also registering email addresses at the same public mail server, There is no evidence yet to suggest the attackers are the same. This is a bandwagon that many are jumping on.

Long Time Coming

Unfortunately, similar to the MongoDB instance, security researchers have seen this a long time coming. I’ve been using ELK stacks for a long time to do enterprise DFIR and log analysis, but am usually building clusters within contained environments or restricting access on multiple levels.

Early versions of Elastic didn’t have much in the way of authentication and were readily accessible in default installs. Even as Elastic implemented additional security measures (see this article here), NoSQL DB admins are still installing instances and disabling authentication. As with MongoDB instances, the goal of rapidly Elastic deployment was to quickly spin up a data store, get data into it, and perform ${function} on that data.

I am still conducting research, however I am willing to bet that the data is being deleted and not backed up. If anyone is running an ELK stack that has been affected and they can share logs, please let me know. I’m wanting to determine if indices are simply deleted as we saw with MongoDB, and not backed up.

Another reason this is scary, again similar to MongoDB, is that we are talking about terabytes of data globally. A lot of data is potentially at risk here — we must get this data secured ASAP to prevent this from spreading too widely.

Thoughts on Securing Elastic

Unfortunately, the concept of securing Elasticsearch is not new, and Elastic has actually taken steps to help make default installs more secure. By default, Elasticsearch binds to localhost . Some other thoughts:

  • Do not expose Elasticsearch to the Internet. If your data needs to be accessible from anywhere, then you must have measures in place to prevent access.
Screenshot from Elastic’s Network Settings Documentation
  • Consider putting authentication in front of Elasticsearch to implement a first layer of security.
  • Elastic makes a plugin called Shield, which enables authentication and role-based access controls. If your data is important, it might be worth ponying up for the extra cost.
  • While it’s for newer versions, security is now a part of Elastic’s X-Pack. This enables integration with Active Directory, LDAP, or PKI. You can find more information here.

Open Season

Last but not least, I’m going to say that it’s open season right now on default install, unauthenticated NoSQL databases. It was fun while it lasted — maintaining databases that were easy to access and script against. Unfortunately, the game is up. Attackers are going to continue exploiting these databases, and as usual, we have very little evidence that anyone is actually going to get their data back.

Please, please, please, secure your data if you utilize one of these databases.

Until tomorrow, Happy Forensicating!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.