MongoDB is a popular NoSQL database with a serious problem. Tens of thousands of MongoDB databases have been hacked by criminals, who replace the data with a simple message: “Send us money or your data is gone forever”. In fact, calling it a hack is overly generous, since there’s very little hacking involved: the databases have no protection and are exposed to the internet.

By default, MongoDB doesn’t force its users to create authentication credentials. It appears that many users don’t understand that MongoDB is insecure by default, and so they do nothing to mitigate the problem. We’re seeing the power of defaults in action, and many argue that it’s unconscionable for a database used in business-critical applications to have defaults that expose its contents to the whole world.

There are arguments on the other side too. It’s much easier to quickly deploy and test a MongoDB database if you don’t have to deal with authentication and security every time. MongoDB experts who understand the thinking behind the defaults are often in favor, and so it appears are the project’s developers.

But that doesn’t help the thousands of companies who have lost critical data because their database is happy to let everyone with an internet connection examine and manipulate it.

It’s not a new problem, but over the past couple of months, the incidence of ransom attacks against MongoDB has skyrocketed, and everyone who uses MongoDB should take action to ensure their database is configured correctly.

MongoDB has published guidance for making the database secure.

These attacks are especially pernicious, because unlike the typical ransomware attacks against businesses, the data is often not returned. Attackers aren’t encrypting data in place; they’re copying it off the server and then deleting the original, leaving nothing behind but an email address to contact for payment.

ransomware-attack

The attack has become so widespread that criminals are competing against each other. An already compromised database will often be compromised again by another attacker who simply changes the ransom demand. The second attacker never had access to the data in the first place because the first had already deleted it — even if the company pays, they won’t get the data back and they lose any hope of contacting the original attacker.

Insecure MongoDB sites are easy to find. It appears many of the attackers are using the Shodan search engine, which helpfully allows people to search for devices and services connected to the internet.

There are two lessons to be learned here. Secure defaults matter. There’s nothing to stop the MongoDB project or downstream distributors from releasing packages with “testing” or “production” versions with appropriate defaults.

But perhaps even more importantly, if you’re going to a deploy a piece of software  on the internet, make sure you understand it — take the time to look at the documentation, or at least Google for information about how to secure it.