Recent reports in the news of MongoDB databases being hacked are not new but the ransoms demanded for the return of data is a new twist on an old problem - insecure MongoDB databases. Compose MongoDB users haven't had to worry about the problem, but it is worth looking at what is going on and why it isn't a worry for them.
We've talked about unsecured MongoDB in the past, but these recent attacks show the problem has not gone away even though MongoDB changed the "out-of-the-box" defaults on the database.
So what was the problem and how is it back? Simply put, people often create their own MongoDB instances in the cloud or on web-facing servers and don't put any access controls on them. Back in 2015, the out of the box default for MongoDB let anyone access it over the network with no passwords until a user was created for the system. Although initially convenient, it was too easy for people to forget to lock down the database. That insecurity was mitigated in MongoDB by ensuring that only connections from the machine the MongoDB instance was running on were accepted by default. But old versions and bad habits persist. What were 40,000 exposed databases on the internet has fallen to around 25,000 databases, but that's still 25,000 opportunities for bad actors.
The problem for those bad actors wanting to exploit this issue was that the data involved on those attackable databases was usually only valuable to its owners. That's led to this new "ransom" strategy where the data is deleted and replaced with a single record containing a demand for payment to get the data back. Some people have apparently paid too. Unfortunately for them, researchers have found there's no record in the logs of any backup being taken. There's also multiple attackers who may be overwriting each other's ransom notes that are left in the database.
The chances are, unless the owners of the databases made backups, that the data is lost and paying the bitcoin ransom will do nothing but mark the victim as someone prepared to pay a ransom. With at least 500 victims, this current spate of fake data-kidnappings still has a way to go.
Interestingly, the reports of vulnerable databases also include versions that appeared since the defaults were fixed on MongoDB. This does suggest that some users are using new database versions but relying on old tutorials offering bad practices for configuring their new MongoDB systems. Worse still, they could be knowingly dropping security measures to simplify making a database available.
Compose MongoDB users have not had to worry about this problem: when we deploy one of our production-ready MongoDB database deployments for you, it's automatically secured with a locked down administration user. If you administer a Compose MongoDB deployment you have to create users through the Compose console to enable database access. This does mean a little more to do when setting up your database deployment at Compose, but it also means people can't walk in and delete your data. That's a trade-off that is simply best practice.
Then there's the fully automated backup system taking regular backups and preserved for three months so even if an authorized user does delete data, there's a backup you can go back to. Better still, you can even restore your backups into a completely new database – it's the default actually – so you can verify them or use them for staging tests. The current Compose MongoDB platform also turns on SSL/TLS on by default so you can have encrypted connections to the database for in-flight credentials and data security.
The current spate of MongoDB attacks is unfortunate, but also avoidable. Whenever you put a database on the web, make sure you secure it or create it with someone who can keep it secure for you.
If you have any feedback about this or any other Compose article, drop the Compose Articles team a line at firstname.lastname@example.org. We're happy to hear from you.