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.
Hydra
Tired of scanning the internet for exposed databases, the endless hours of monitoring botnets for a worthy place to breach? Well rest your greedy little fingers, we have a solution! Here at Shodan, if you want to find a place to hack, we do all the prework for you, we do it all day every day. Our database has indexed more than you can imagine, looking for exposed webcams, we got it, data bases, we got that to, even infrastructure. And don’t worry about us going away, Uncle Sam has our back. This isn’t the dark net, no GDPR, no arrest, it’s research!!
Nobody_Holme
It’s a hell of a lot easier to find your own service on Shodan than for a hacker to do it. And adversaries have time to set up their own equivalent easily, but researchers don’t.
It’s about levelling the playing field for the good guys, that does mean every script kiddy out there gets a boost too, but that’s the cost of doing business.
This article is a prime example, the good guy got there first by using Shodan.
Paul Ducklin
I think you could write this the other way around – swap good/bad and hacker/researcher and it would as good as read the same.
(Did the good guy get there first in this case? Who can say?)
Mahhn
In response to “It’s a hell of a lot easier to find your own service on Shodan”
If you don’t know your own IP (or can’t find it) to have it pen tested, shodan isn’t going to be much help.