Unsecured MongoDBs taken hostage
15 comments
It's fascinating that someone installs and configures MongoDB and doesn't stop to think: "Hey, maybe this shouldn't be exposed directly to the internet". I mean you wouldn't do that with something like MySQL.
Some sort of analysis of the purpose of these directly exposed MongoDB instances could be interesting. Are they being used as a backend for JavaScript applications?
Some sort of analysis of the purpose of these directly exposed MongoDB instances could be interesting. Are they being used as a backend for JavaScript applications?
> I mean you wouldn't do that with something like MySQL.
Oh yeah? I dumped over 40TB of data from open MySQL instances. --skip-grant-tables is probably the most common advice for resetting your MySQL root password.
Oh yeah? I dumped over 40TB of data from open MySQL instances. --skip-grant-tables is probably the most common advice for resetting your MySQL root password.
Many database systems are by default only exposed to localhost, you'd have to specifically change the settings to be able to talk to it from outside. That's at least the case for Postgres and MSSQL, not sure about MySQL.
I don't see any reason that a database should allow to listen to any address without authentication. There shouldn't be a real world application requiring this.
I don't see any reason that a database should allow to listen to any address without authentication. There shouldn't be a real world application requiring this.
MySQL is the same with bind-address. If someone chooses to expose a db/store to the world, it would be nice if there was some automatic auth enabled. This isn't Mongo-specific, Elasticsearch is the same way.
Agreed. I think it should only work in non-auth mode if you're binding to localhost/loopback but if you go for any other interface it bombs out if auth isn't enabled. Have a flag if you want to override that (if you are doing some other sort of clever auth that the instance can't tell itself), but these defaults are really dumb IMO.
ES did have the same default, but that changed in 2.0. Since then the default is to bind to localhost only. However, ES does not at all provide any authentication without a plugin.
In MySQL you have to change the bind-address but also allow the user to access from any IP (%) in order to access from any IP. Opening the service to the whole web is not enough
True, and hopefully if/when people do that they're not GRANT to '%'@'%' or whatever, but I figure if you're not going to bother to tunnel who knows what other silly things you might do.
And this is case in point.
And this is case in point.
Yeah but webscale apps aren't vulnerable.
This has been a known issue for a long time and while I hadn't seen ransomware before these open databases have been attacked previously:
https://blog.shodan.io/its-the-data-stupid/
Note that MongoDB listens on localhost unless changed by the user or the developer is using an insecure image.
https://blog.shodan.io/its-the-data-stupid/
Note that MongoDB listens on localhost unless changed by the user or the developer is using an insecure image.
Hey Guys, we have been affected by this? What's the course of action that we should take? Data is pretty important to us.
Restore from backups.
I don't have any :(
Pull the plug on the server and send the disks to a data recovery company? Most file contents are probably still on the disk (just marked as erased), but the longer you wait the more likely it is that random temp files overwrite more of your data.
(Note: I have no idea how exactly mongo implements deletion.)
(Note: I have no idea how exactly mongo implements deletion.)
[deleted]
> Data is pretty important to us.
> I don't have any :(
You're aware those two statements conflict with each other yeah? :(
> I don't have any :(
You're aware those two statements conflict with each other yeah? :(
At the current price, 0.2 BTC is ~200USD.
Look at the btc address history: https://bitref.com/13zaxGVjj9MNc2jyvDRhLyYpkCh323MsMq
Looks like the guy pulled off these blackmailing/hostage tricks before as well.
Not to pile on to the already tense situation, would you be open to sharing how this happened, what the database contained etc, sort of like a post mortem without revealing any personally identifiable info.
Looks like the guy pulled off these blackmailing/hostage tricks before as well.
Not to pile on to the already tense situation, would you be open to sharing how this happened, what the database contained etc, sort of like a post mortem without revealing any personally identifiable info.
I am not affected by this hostage taking. On the contrary, I am one of the authors of the aforementioned info paper from early '15 warning about this kind of stuff. If you want more information about the incident back then, look me up my name is Kai Greshake. The paper linked above also contains all you need to know about why this incident today happened. As a response MongoDB also updated their security guidelines back then, but refused to change the open-default mechanism and easy-to-do-wrong configuration, arguing that it was aconcious design choice.Turns out this was a bad decision, at least in my eyes, as this is not the first related incident, there were many breaches etc. based around open-default databases in the past 2 years, exposing millions of account info, voting data, and industry equipment.
Shouldn't it be possible to trace the transactions to the point where they were used to pay goods or exchange them for real money?
It's been going on for quite some time already, see: https://twitter.com/achillean/status/816385533538631680
It might be entertaining to run a honeypot server that responds with some... unusual data. Does anyone know if the client they're using to do this has any vulnerabilities? ;-)
Shouldn't be hard to get the IP etc, as you can just connect to affected servers and review the global log. Just search for mongoDB on shodan and see for yourself.
MongoDB has a security checklist published, I think it is interesting to review it: https://docs.mongodb.com/manual/administration/security-chec...
Aquired log of such a hostage taking, contains the IP of the hostage taker, but beware it could be obscured by a botnet or similar.
Update: in a different log he used a different server for the attack, suggesting he might be using innocent servers, therefore I removed the log.
Update: in a different log he used a different server for the attack, suggesting he might be using innocent servers, therefore I removed the log.
Could someone more familiar with MongoDB please confirm that this does not show any backup of data? Maybe MongoDB does not log just looking up data?
The database was dropped within ~1 second of the connection, so either it was a very small database or he didn't have time to take a backup.
My thoughts, too. But before claiming this I at least wanted to encourage a second look. I also ensured this was the only time he connected, so there is no plausable way he is backing up the data.
There is now more evidence supporting that there are no backups, e.g. he doesn't even store information about which servers he already looted (he is erasing the same servers twice or more). Until someone has logs that prove otherwise on bigger datasets, nobody should pay this guy.
Also it seems implausible seeing the vast amount of data which he would need to have backed up, closing in several hundreds of terabytes, based on an estimation of last year.
The attacker could have used a script like this:
use foobar
db.collection.find()
db.dropDatabase()
cat script.js | mongo | tee backup
A separate connection was used to create the random note. There could have been an earlier connection from another IP that did the data dump that didn't make it into the log.
The IP listed in that log belongs to a DigitalOcean instance.
I also have been affected by the same "hack".
Turns out I have simply forgot to start mongod with --auth option, even through the I had created users for different databases, including the admin!
Looks like in "non secure mode" it allows logins with existing users as well as non-authorized.
I understand why the authentication is disabled by default, but it should fail to start with a DB that has users with roles and stuff.
I understand why the authentication is disabled by default, but it should fail to start with a DB that has users with roles and stuff.
How did you install MongoDB? I'm asking because by default it should only listen on localhost and I'm trying to understand whether there's a popular package/ repository that has changed that default from localhost to 0.0.0.0
Why should it be disabled by default? I don't see a reason why any database system would run without auth. At installation they can always use a local user account if no password is provided.
I wouldn't call it a bastion of security but MySQL typically installs with a root user with no password. So how do they not have the same level of exposed data? By default only local connections are allowed. If Mongo had the same pattern then this whole calamity could have been avoided whilst still allowing the ease of setting up on local environments.
- Why should it be disabled by default?
I don't agree it should, but understand why it is disabled by default: for easy and quick start of development on the local machine.
Isn't it as fast if you bind it to a local user by default? You can still change it afterwards, but that way there's no set up for developers.
Yes, it is the same.
In my case the database already had some users configured. But because I did't start the server with --auth option, MongoDB ignored all users and allowed everyone to connect.
In my case the database already had some users configured. But because I did't start the server with --auth option, MongoDB ignored all users and allowed everyone to connect.
An solution for the people like me, that forget the --auth would be:
Situation #1, new database: Start MongoDb without any users, but as soon as the admin user is added, drop all connections and enable authentication
Situation #2, existing database: In MongoDB is started with a database, that has admin user but the authentication is not enabled, fail and exit.
Situation #1, new database: Start MongoDb without any users, but as soon as the admin user is added, drop all connections and enable authentication
Situation #2, existing database: In MongoDB is started with a database, that has admin user but the authentication is not enabled, fail and exit.
2BTC for such felony does not sound a great deal to me
0.2BTC. But you have to multiply that by the number of open MongoDB installations. Tens of thousands at least. So, 20000*0.2BTC = 4000BTC if everyone pays. That's 4mil USD if everybody pays (not everybody will since many of the installations are personal or just tests running on amazon or other clouds). Still, a lot of money for little risk. BTC is pretty safe if you know what to do.
Worst thing is that the data loss impact in money is not limited to the blackmail rates. What I'm saying is that even if everyone pays and 4kBTC (4.3M USD today) is collected by the perpetrator, there are other impacts in terms of legal issues and insurance. I don't know how to calculate this, but it could be an interesting number tho.
You don't need to calculate it, don't even try to estimate it. Just make up a number. A huge number. Larger than the whole world's GDP if you can. That's how the RIAA did it.
Amazed this has taken so long. I think elasticsearch also suffers from this same 'no-auth-by-default' configuration, which is really silly.
Sort of. ES >= 2.0 only binds to localhost by default, so it's at least not by default exposed to the internet. Versions < 2.0 suffer from exactly that flaw: No auth, bind to all ports.
I think this is still a cop out: first thing junior will do when he can't connect to his database from home is google it, then find out how to bind to all ip's. Network access is BARELY viable access control, as it's too easy to fail open.
I absolutely agree with you. One of my biggest issues with ES is that authentication (even basic) and encrypted intra-cluster communication requires a (commercial) plugin. Either shield, which is not available as a standalone piece of software or SearchGuard, which is sort-of-free with limited functionality. I do consider those basic functions that should be available out of the box.
The basic version of Search Guard provides TLS/SSL encrypted intra-cluster communication and also HTTP basic authentication totally free of charge also for commercial projects. Only for authentication methods like LDAP or Kerberos, or for advanced features like Document-Level-Security and audit logging a license is needed. Disclaimer: I work for floragunn/Search Guard.
Another log shows that he even connects to the same server twice sometimes, deleting his own message just to re-insert it- That means he doesn't even save which servers he deleted. Such blunt action is remarkable.
Or that "he" is an automated distributed system without strong consistency guarantees.
So he deleted his email address or sigaint removed it:
Requested action not taken: mailbox unavailable 550 Invalid recipient
Requested action not taken: mailbox unavailable 550 Invalid recipient
Unsurprising. On their signup page at http://www.sigaintevyh2rzvw.onion/ it says:
Are there any rules to using this thing? Generally we are
pretty chill, all we ask is that you don't use our FREE
service to:
Spam people
Threaten people
Harm people
Everything else is cool with us.
"hack" is the wrong word considering we're talking about DB instances exposed to the Internet without access controls.
Please don't say "hack" when you've been auto-pwned by something that uses an OWASP TOP-10 to get you. It's carelessness, inexperience, possibly negligence or anything in between. But for sure it is not a hack!
Please don't say "hack" when you've been auto-pwned by something that uses an OWASP TOP-10 to get you. It's carelessness, inexperience, possibly negligence or anything in between. But for sure it is not a hack!
Using "hack" to refer to this is like leaving your front door wide open and referring to being robbed as an Ocean's 11 style escapade.
I'd argue this metaphor is why it IS appropriate to use the word "hack" here.
If you left your door unlocked and someone stole your stuff, that's still a robbery.
If you left your database accidentally midconfigured and someone stole your data and left you an extortion notice, that's still a "hack".
Is misconfiguring MongoDB really that different from e.g. installing a Wordpress plugin with a security flaw and getting hacked via that?
If you left your door unlocked and someone stole your stuff, that's still a robbery.
If you left your database accidentally midconfigured and someone stole your data and left you an extortion notice, that's still a "hack".
Is misconfiguring MongoDB really that different from e.g. installing a Wordpress plugin with a security flaw and getting hacked via that?
> If you left your door unlocked and someone stole your stuff, that's still a robbery.
True but hack in this context would be metaphorically closer to "breaking and entering". If your door is open, you've only got the latter half (from an english, not legal definition).
> If you left your database accidentally midconfigured and someone stole your data and left you an extortion notice, that's still a "hack".
I suppose it's a matter of semantics for me. If I use the word "hack" I'd expect a bare level of finesse to get past some defense or prevention system.
> Is misconfiguring MongoDB really that different from e.g. installing a Wordpress plugin with a security flaw and getting hacked via that?
Not in my book. They're all terrible decisions but then again anything that involves "Using X without understanding the implications of the default set up of X" tends to be a terrible decision.
True but hack in this context would be metaphorically closer to "breaking and entering". If your door is open, you've only got the latter half (from an english, not legal definition).
> If you left your database accidentally midconfigured and someone stole your data and left you an extortion notice, that's still a "hack".
I suppose it's a matter of semantics for me. If I use the word "hack" I'd expect a bare level of finesse to get past some defense or prevention system.
> Is misconfiguring MongoDB really that different from e.g. installing a Wordpress plugin with a security flaw and getting hacked via that?
Not in my book. They're all terrible decisions but then again anything that involves "Using X without understanding the implications of the default set up of X" tends to be a terrible decision.
I don't think you quite understand the comment you're replying to. By my reading at least, it's saying "hack" = "heist" and that "heist" is being used somewhere where "robbery" is more appropriate.
I agree that if you leave your door unlocked, it's a robbery but it's not a heist. Likewise, if you leave your database publicly accessible, it's extortion through technical means but it's not hacking.
> Is misconfiguring MongoDB really that different from e.g. installing a Wordpress plugin with a security flaw and getting hacked via that?
Yes. A service that is configured to be publicly accessible is very different to a service that requires active exploitation. Misconfiguring MongoDB is more like making your Wordpress admin page the home page and removing all login requirements.
I agree that if you leave your door unlocked, it's a robbery but it's not a heist. Likewise, if you leave your database publicly accessible, it's extortion through technical means but it's not hacking.
> Is misconfiguring MongoDB really that different from e.g. installing a Wordpress plugin with a security flaw and getting hacked via that?
Yes. A service that is configured to be publicly accessible is very different to a service that requires active exploitation. Misconfiguring MongoDB is more like making your Wordpress admin page the home page and removing all login requirements.
I've aquired the portion of the log related to the hostage taking, posted below. In particular this log shows that __no__ backup of the data was taken. So please don't pay any money!
------------------------------------------
Although my colleagues and I have already pointed out the issue of open-by-default databases in spring 2015 (look at the references), today it seems for the astonishingly first(?) time somebody took the opportunity to erase hundreds of MongoDBs leaving only this Message:
{ "_id" : ObjectId("5859a0370b8e49f123fcc7da"), "mail" : "[email protected]", "note" : "SEND 0.2 BTC TO THIS ADDRESS 13zaxGVjj9MNc2jyvDRhLyYpkCh323MsMq AND CONTACT THIS EMAIL WITH YOUR IP OF YOUR SERVER TO RECOVER YOUR DATABASE !" }
Well played, system admins.
Updates:
The price for the data seems to equate to about 200 USD currently. Thanks, wereHamster.
This has been going on since at least yesterday (https://twitter.com/achillean/status/816385533538631680). Thanks, NietTim.
There have already been transactions by presumed victims: https://bitref.com/13zaxGVjj9MNc2jyvDRhLyYpkCh323MsMq . Thanks, anondon.
Please read the official security checklist by MongoDB! In particular, use passwords and don't expose on all interfaces (duh!)! https://docs.mongodb.com/manual/administration/security-checklist/
Sources/References:
The Jan '15 info paper of which I am one of the authors: https://cispa.saarland/wp-content/uploads/2015/02/MongoDB_documentation.pdf
(Jan '17) http://www.csoonline.com/article/3154190/security/exposed-mongodb-installs-being-erased-held-for-ransom.html
http://www.theregister.co.uk/2017/01/04/mongodb_installs_wiped_by_bitcoin_ransoming_script/
(German) https://www.heise.de/newsticker/meldung/Eindringling-nimmt-offenbar-MongoDB-Datenbanken-als-Geisel-3587479.html