Tens of thousands of personal and possibly proprietary databases that were left accessible to the public online have just been wiped from the Internet, replaced with ransom notes demanding payment for the return of the files. Adding insult to injury, it appears that virtually none of the victims who have paid the ransom have gotten their files back because multiple fraudsters are now wise to the extortion attempts and are competing to replace each other’s ransom notes.
At the eye of this developing data destruction maelstrom is an online database platform called MongoDB. Tens of thousands of organizations use MongoDB to store data, but it is easy to misconfigure and leave the database exposed online. If installed on a server with the default settings, for example, MongoDB allows anyone to browse the databases, download them, or even write over them and delete them.
This blog has featured several stories over the years about companies accidentally publishing user data via incorrectly configured MongoDB databases. In March 2016, for example, KrebsOnSecurity broke the news that Verizon Enterprise Solutions managed to leak the contact information on some 1.5 million customers because of a publicly accessible MongoDB installation.
Point is, this is a known problem, and almost once a week some security researcher is Tweeting that he’s discovered another huge open MongoDB database. There are simple queries that anyone can run via search engines like Shodan that will point to all of the open MongoDB databases out there at any given time. For example, the latest query via Shodan (see image above) shows that there are more than 52,000 publicly accessible MongoDB databases on the Internet right now. The largest share of open MongoDB databases are here in the United States.
Normally, when one runs a query on Shodan to list all available MongoDB databases, what one gets in return is a list of variously-named databases, and many databases with default filenames like “local.”
But when researcher Victor Gevers ran that same query earlier this week, he noticed that far too many of the database listings returned by the query had names like “readme,” “readnow,” “encrypted” and “readplease.” Inside each of these databases is exactly one file: a database file that includes a contact email address and/or a bitcoin address and a payment demand.
Researcher Niall Merrigan, a solutions architect for French consulting giant Cap Gemini, has been working with Gevers to help victims on his personal time, and to help maintain a public document that’s live-chronicling the damage from the now widespread extortion attack. Merrigan said it seems clear that multiple actors are wise to the scam because if you wait a few minutes after running the Shodan query and then re-run the query, you’ll find the same Internet addresses that showed up in the database listings from the previous query, but you’ll also notice that many now have a different database title and a new ransom note.
Merrigan and Gevers are maintaining a public Google Drive document (read-only) that is tracking the various victims and ransom demands. Merrigan said it appears that at least 29,000 MongoDB databases that were previously published online are now erased. Worse, hardly anyone who’s paid the ransom demands has yet received their files back.
“It’s like the kidnappers keep delivering the ransom notes, but you don’t know who has the actual original data,” Merrigan said. “That’s why we’re tracking the notes, so that if we see the [databases] are being exfiltrated by the thieves, we can know the guys who should actually get paid if they want to get their data back.”
For now, Merrigan is advising victims not to pay the ransom. He encouraged those inclined to do so anyway to demand “proof of life” from the extortionists — i.e., request that they share one or two of the deleted files to prove that they can restore the entire cache.
Merrigan said the attackers appear to be following the plan of attack. Use Shodan to scan for open MongoDB databases, connect using anonymous access, and then list all available databases. The attacker may or may not download the data before deleting it, leaving in its place a single database file with the extortionists contact and payment info and ransom note.
Merrigan said it’s unclear what prompted this explosion in extortion attacks on MongoDB users, but he suspects someone developed a “method” for extorting others that was either shared, sold or leaked to other ne’er-do-wells, who then began competing to scam each other — leaving victims in the lurch.
“It’s like the early 1800s gold rush in the United States, everyone is just going west at the same time,” Merrigan said. “The problem is, everyone was sold the same map.”
Zach Wikholm, a research developer at New York City-based security firm Flashpoint said he’s confirmed that at least 20,000 databases have been deleted — possibly permanently.
“You’re looking at over 20,000 databases that have gone from being useful to being encrypted and held for ransom,” Wikholm said. “I’m not sure the Internet as a whole has ever experienced anything like this at one time. The fact that we can pull down the number of databases that have been compromised and are still compromised is not a good sign. It means that most victims are unaware what has happened, or they’re not sure how it’s happened or what to do about it.”
Normally, I don’t have great timing, but yesterday’s posts on Immutable Truths About Data Breaches seems almost prescient given this developing attack. Truth 1: “If you connect it to the Internet, someone will try to hack it.” Truth 2: “If what you put on the Internet has value, someone will invest time and effort to steal it.” Truth 3: “Organizations and individuals unwilling to spend a small fraction of what those assets are worth to secure them against cybercrooks can expect to eventually be relieved of said assets.”
H/T to Graham Cluley for a heads-up on this situation.
Update, 1:55 p.m. ET: Clarified the default settings of a MongoDB installation. Also clarified story to note that Gevers discovered the extortion attempts.
Can’t folks look at some logs to see the difference in data traffic to determine if just a delete command was issued or if all the files actually left?
Logs? What do you mean, logs?
Just curious. Doesn’t anybody do backups?
Doing backups would be a good idea. Not putting your database on the public ‘net and funneling traffic through some kind of app or web server would be even better.
The fact that the people running these things are (a) using MongoDB, (b) running a default unhardened configuration, and (c) putting it on the public Internet, would point to the fact that we’re not dealing with someone who follows IT best practice much, so the absence of backups isn’t much of a surprise.
Welcome to DevOPs deployment model.
You mean soon to be unemployed trash devops wannabes. Not all of us don’t know what we’re doing, bruh.
Welcome to the wonderful world of competitive free labor markets. Companies set salaries low, and get the talent and knowledge for which they are willing to pay. Same reason they use FOSS, with the cheap employees doing the builds, instead of spending more bucks on a vendor or employee that knows what they’re doing. It’s great, until it bites you in the ass.
dbleaks.com has informed thousands of folks of this issue, less than 1% reply and out of that 1%… its maybe 1 in 100 that actually secure their databases…
Security is the last thing these folks care about. You can tell them, they don’t care until its too late.
Seems like these people are providing a valuable service. Raising awareness of the dangers of putting a database on the @^$#!@# internet with no permissions at all.
95% of these DBs aren’t going to have data that can be brokered on a secondary market, so all that’s left is the dumbass admin learning a lesson on the dangers of being so catastrophically ignorant.
Like the early days when the default SQL Server install used a blank password for SA, and management didn’t authorize a firewall because NT had “C2 level security”.
Forgetting that those certifications are for standalone OS on non networked machines. Virtually no networked connected anything has a security rating.
Yeah, I remember that C2 hardening tool for NT4. Fully deployed, it created a totally non-functional system…which I guess is as secure as it gets!
Unfortunately people who do a default install — and don’t realize that’s a problem — probably don’t realize they need to do backups either. And while backups aren’t difficult there are some special considerations for backing up databases, beyond just backing up ordinary files.
I have no experience with MongoDB, But with Riak, it’s not so easy to do a “logical” backup (an export of the objects contained in the cluster). If doing a file system level backup of the database, you have to get all the data directories from every node. Not as simple as a relational database backup.
This seems to be a case of “insecure by default”.
Honestly, if you leave your DB accessible to the entire internet, this is a common case of “natural selection”.
murphy’s law corollary:
there’s no such thing as a foolproof system, because fools are so ingenious.
Crypto-extortion – just when crime starts to pay – greed interferes and all bets are off. Heh! Heh!
I’m glad I can now tell people with online data like that, to forget about paying the ransom!
I assume that you’re talking about the “re-extorters” who are trying to get “ransom for nothing.”
Isn’t it likely that major players in the malware and/or extortion business will take measures to punish and/or eliminate the “re-extorters” who are wreaking havoc with their business model(s)?
MongoDB requires a few moves by a system administrator to rig it so it’s secure. https://docs.mongodb.com/manual/tutorial/enable-authentication/ Unfortunately, it’s not secure out of the “box.” If the system administrator doesn’t make those moves, it stays insecure.
But never mind. It’s well known that database systems should be behind firewalls even if they do have strong passwords and other access controls. Why? Certain kinds of software, like web servers, have been subjected to vast amounts of penetration testing for attacks like buffer-overrun attacks.
Database software is NOT one of those kinds of software. Database servers usually have elaborate wire protocols, and wire protocols are easy to attack. So, hide your databases behind firewalls. Please.
The trouble with ransom scams is this: they require thieves to have a reputation for being honest. If I’m going to pay, I want some assurance that I’ll get my data back. If there’s any good news in this mongo attack on mongo db, it’s this: that reputation is now dissipated. For a 10% chance of getting your data back, does it make sense to pay a ransom demand?
Excuse the ignorance, but in the first picture Amazon leads the Organizations list.
Does it mean that business has 4K+ databases on mongoDB? And those are exposed?
On the question of backups:
If I could only remember where I put my portable external hard drives … 🙁
Amazon needed a lot of processing power and data storage. So they over-provisioned. Then they realized they could rent their spare capacity to others. They called this Amazon Web Services (AWS), you might just hear about it as “The Cloud”.
Microsoft offers a similar product called Azure.
Most likely, the bad databases counted against these two companies represent third party clients (like you) who are renting space within their cloud computing environments.
To be honest i cant undestood not single word only ransom.
Can anyone explain to me what is writed here???
What is crime exacly ? Who got killed here ?
Like this internet thing going too complicated.life must be simple
I hate complicated things.
First, you can ransom things in addition to free people*.
«Art theft is usually for the purpose of resale or for ransom (sometimes called artnapping).» (Wikipedia)
Ransom is about taking something, depriving someone of something, and then demanding payment in exchange for restoring the taken thing to its original state. Note that each thing/one in the previous sentence can be different or the same. You can ransom yourself, you can ransom something else taken from someone else. You can also ransom a corpse.
Also, people who ransom may or may not uphold their promise, in the case of kidnapping, they may take the payment and return a body or nothing.
In the case of kidnappers, they can even ransom information about the location of the victim as opposed to the actual victim.
That established, people have data, someone takes the data, someone demands payment — offering to return the data.
Again, there isn’t a requirement that the person (who is obviously unethical) be able to restore things, they are merely claiming to be able to.
People claiming to be able to restore data are demanding a ransom.
*The word free is important, as non-free are treated as property and ransomable just like art.
These simple issues would be resolved if laws were passed that made devices/software/firmware secure by default with requirements to change the password etc.
Yes, I’m sure a law will fix all those issues. Who is going to enforce those laws, the UN? Who is going to pay to enforce those laws? What if someone decides to simply ignore the law?
What if we started taking responsibility for our own actions instead of trying to “law” ourselves into a false sense of security?
Doesn’t the EU require you to register a database if you store personal info?
Have you ever made a model home as a school project? Or a doll house?
Can you imagine being required to install smoke detectors, carbon monoxide detectors, and locks on such projects?
It is common for students to build databases as a class project. It’s a good way to learn how they actually function.
Having a law would put a damper on such classes, needlessly complicating the instruction and necessitating additional time.
Most database software is open source, many were originally written by students as class projects.
I have no sympathy for someone who puts up a database without even checking if the default settings are wide open.
Its was an issue that was identified over a year ago. Some were notified and things were cleaned up. Some organizations that were notified pointed fingers at “researchers” for mucking around their DB’s and threatened to charge them.
Now, some entity goes on a rampage and makes the issue come to the forefront. Its now a repair and move on.
Ignorance is bliss. Its been in the news forever. Its like if people “don’t think” about the issue, the bad side will never come. Well, now there will be plenty of cleanup and mediocre amount of downtime.
The only thing people can hope for is that most of the databases are stale and no longer used. The organizations simply moved onto something else.
This should have never happened. Cyber news about hacking and issues have been in the limelight for 3-5 years. If people don’t know about this potential issue at hand, they have had their head buried in the sand.
“Tens of thousands of organizations use MongoDB to store data”
And those tens of thousands of organizations were prone to suffer data loss at any given point. This is part of the risk of using a NoSQL engine to store data. If someone didn’t steal your data, the engine itself would drop it for you eventually.
Articles like this (good one, by the way) always bring me back to Rumsfeld’s statement about “known knowns, known unknowns and unknown unknowns”. Too many times you have organizations with that “tech person” who often steps up to the challenge (a good trait) when needed. And often this person becomes the SME without really knowing what they are doing because they don’t know what they don’t know. These same organizations do not want to spend resources on real experts because their own “expert” doesn’t think they need to. And the cycle continues…
That and the Sys Admins are too cocky and when you alert them they have an issue they do one of two things:
1. Ignore the problem completely..
2. Attack you for showing them their config is insecure..
It’s hard to feel sorry for people who don’t use firewalls, and at the very least don’t hide machines behind NAT routers.
“In March 2016, for example, KrebsOnSecurity broke the news that Verizon Enterprise Solutions managed to leak the contact information on some 1.5 million customers because of a publicly accessible MongoDB installation.”
Brian, this part seems purely speculative. In March you suggested this as just a theory of yours…unless you have solid evidence the Verizon breach was actually the result of a MongoDB issue (and not that the data was merely being sold in that format, something suggested to you by readers in your comments section), I think you’ve made a questionable leap to that conclusion. Are you stating your opinion, or fact? You seem to be suggesting you released factual information about the cause of the Verizon breach in March, but based on your previous blog, you were just guessing, right? I think it’s important to separate facts from speculation with respect to these breaches, otherwise it just becomes FUD.
Law? You go and tell the law some big russian or ukrainen guy
Who dont have even right passport or id and drive with his bmw
With special number plate. You go and tell him about law??
Probably he gona laugh at your face those guys have money like mudd. They travel well they are connected.they have best lawers.
What law those guys have to follow really ?? This guys do what they want. . They are above any law. Many of them are probably 24/7 drunk or toxicated they probably not even undestood nothing.
Keep moving forward by backing up.
1995 called and wants their insecure defaults back.
That takes me back. I’m glad there haven’t been any insecure defaults since.
NoSQL sees security as an after thought. As a dba I have dealt with MongoDB and Couchbase and been extremely frustrated with the lack of security, especially as default. I have required either security_authorization enable or keyfile at minimum on all stand alone and cluster mongodb setups. People still try to look to get around that when installing so it will be easier.
Looks like they may be expanding beyond MongoDB. I browsed the elasticsearch section of Shodan. First install I connected to which was Shodan reported to be many MB in size had only one index of “please_read”.
Only record in there:
“_index” : “please_read”,
“_type” : “info”,
“_id” : “xxxxxxxxxxxxxxxxxxxxxxxxxx”,
“_score” : 1.0,
“Info”: “Your DB is Backed up at our servers, to restore send 0.5 BTC to the Bitcoin Address then send an email with your server ip”,
“Bitcoin Address”: “xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”,
“Email” : “firstname.lastname@example.org”
This just happened in the last 24 hours to a test server I had deployed using Bitnami’s version of elasticsearch on Google’s Cloud Platform using default settings. Nothing of value lost but watch out – it should be noted that it is happening to Elasticsearch too!!
I checked Bitnami’s blog and found they issued a security warning on Jan 13th related to this Elasticsearch cloud images, specifically Azure, but said all cloud users should check the information and make changes listed.
It is very unusual for criminals to destroy a source of future income. If it is not multiple OC entities fighting over fresh mongo pie, it is being done on instructions from a state actor.