EmergencyEMERGENCY? Get 24/7 Help Now!

MongoDB Ransomware: Not Likely, But How Do You Know?

 | January 5, 2017 |  Posted In: MongoDB, Security

PREVIOUS POST
NEXT POST

MongoDB RansomwareIn this blog post, we’ll look at some of the concerns recently seen around MongoDB ransomware and security issues.

Security blogs and magazines have recently been aflutter with the news that a hacker is stealing data from MongoDB instantiations and demanding bitcoins to get the data back. This sounds pretty bad at first glance, but let’s examine the facts.

The hacker needs a few things to pull this off:

  1. MongoDB is running on default ports
  2. MongoDB is not using authentication
  3. MongoDB is accessible on the Internet with no security groups or firewalls

If this sounds familiar, you might remember a similar flurry occurred last year when people counted the number of open MongoDB installs on the web. That required these same conditions to all be true. This also means the solution is the same: you simply need to make sure you follow the normal security practices of locking down ports and using authentication. Not so scary after all, right?

What does this hack look like?

Finding out if this happened is simple: your data is removed and gone! In its place, you will find a “WARNING” database, which holds a “WARNING” collection. This collection has a document that looks like:

To fix this, hopefully, you have backups. If you don’t, you might want to look at https://www.percona.com/blog/2016/07/25/mongodb-consistent-backups/ on how to get consistent backups. If not, you will need to send the hackers the 0.2 bitcoins (~200 USD) to get your data back.

So, backup!

But this brings us to the real question: can you be hijacked? It’s pretty easy to check:

  1. Do you have authentication on? Try running this command:

  1. Are you running on a non-default port? Simply run this command (if you’re using 27017 or 29017, you’re using a default port):

The last part is a bit harder if the other two are both false. You will need to spin up a server outside of your environment and test the connection. I suggest an Amazon EC2 Micro instance (it’s very inexpensive – free if you use a new account). It’s simple to install a MongoDB client on. Check your setup:

  1. Login to Amazon and launch an EC2 node.
  2. Open a shell to this node (this can be done via their website).
  3. Get MongoDB’s binaries:

  1. Try and connect to your MongoDB Server

If this connects, and you can run “db.serverStatus()”, you are at risk and should enable authentication ASAP!

We will have a blog out shortly on the particulars of creating a user. To enable authentication, you simply need to add “–auth” to your startup, or the following to your YAML config file:

This should get you started on correctly protecting yourself against MongoDB ransomware (and other security threats). If you want to have someone review your security, or even help you use LDAP to tie into your main authentication systems, please contact us.

PREVIOUS POST
NEXT POST
David Murphy

David is the Practice Manager for MongoDB @ Percona.

He joined Percona in Oct 2015, before that he has been deep in both the MySQL and MongoDB database communities for some time. Other passions include DevOps , tool building, and security.

2 Comments

  • It seems that the command to check if authentication is “on” doesn’t take into account if you use internal authentication with –keyFile option which enables client authentication by default (at least from what I see).

  • Your right it could have been better to have used getParamter to check if the running config had changed this due to the key file. However it is still best practice to set both in the config file and the goal was to make the simple and quick for a general check. If someone used a key file they would know they had done this and it implied auth:true.

Leave a Reply