275m personal records swiped from exposed MongoDB database

Another day, another massive MongoDB exposure. This time, a security researcher has discovered a public-facing database with over 275 million records containing personal information on citizens in India.

The researcher is Bob Diachenko, who spends a lot of time poring over Shodan search results. Shodan is a search engine, but unlike Google or Bing it indexes devices and software applications connected to the internet and viewable by the public. Shodan regularly surfaces everything from unsecured webcams to exposed databases.

Shodan first indexed the MongoDB instance on 23 April 2019. Its records included not only the individuals’ name, gender, and email address but also their employment history, current employer, current salary, and mobile phone number.

In his blog post on the topic, Diachenko explains that there were no clues in the database about who owned it. His best guess is that the database was the product of a data scraping operation.

Putting people at risk

This is one of the most frustrating things about public database exposures: Someone who doesn’t know what they’re doing can put millions of people in danger, and there’s no way to get hold of them so they can rectify the problem.

We’ve seen this before. Late last month, researchers stumbled on a database with information about 80 million US households, owner unknown.

Diachenko found another last September, again without an owner, exposing email addresses and physical addresses in a 43.5 GB data set. He has a long track record of exposed database discoveries.

Who is to blame for these exposed databases?

MongoDB has offered the ability to limit remote access since its early days. Version 2.6, released in April 2014, turned it on by default in certain distributions, while version 3.6 turned it on across all available versions of the product.

Whoever put this thing online was using an old version they hadn’t reconfigured, or a newer version with the protection disabled. They might do that for convenience, ignorant or uncaring about the security implications.

Naked Security asked MongoDB why it couldn’t just force developers to turn on authentication whenever they deliberately removed the remote access protections on the database. A spokesperson told us:

We respect that our innovative users ask for freedom to set their own course and we do what we can to keep that possible, while at the same time answering to the standards of care expected in safety-conscious measured operations. That balance has meant offering both a frictionless experience for developers and a thorough configuration guide to complex controls like authentication. We believe setting localhost by default puts users in a mode where they have to make a conscious decision about their own appropriate path to network safety.

At some point, Diachenko notified the Indian CERT team, but the database remained public until Wednesday 8 May, when someone hacked it and erased all its content. They left a message with the email address unistellar@hotmail.com, suggesting that the database owner could contact them to restore the data.

That’s the other thing about unprotected MongoDB instances: they’re hackable. Someone that finds them can access the database, delete it, and then hold the owner to ransom.

If you’re using a MongoDB server, take care when using anything other than the default configuration, with networking turned off, and make sure to follow its security checklist.

Naked Security’s Paul Ducklin on the responsibilities of data handlers:

If you collect data from other people, especially for your own commercial benefit, you owe it to them to look after it properly. If it so much as crosses your mind to slap it into an online database ‘just using the default settings’, whatever they might be, then you’re nobody’s true data friend. So don’t even think of taking shortcuts like that!

As for the rest of us, there’s no way of knowing whether someone has our data in a publicly facing server somewhere.

Turn on multi factor authentication in the services you use where possible. Use strong passwords and a reliable password manager, and don’t reuse your passwords. Keep an eye on your bank accounts. Check your credit, or even better still, set up a credit freeze. There’s no guarantee you won’t still get pwned, but personal risk lies on a continuum and multi-layered defences will help reduce it.