A while back I published research on open, unauthenticated ICA (Citrix) instances that could be found by doing basic google queries. I was able to find a lot of interesting targets including some belonging to military and government organisations. I published my findings regarding the discovery without including any details. The blog post was very vague. Anyway, it doesn't take a rocket scientist to figure out what's going on once you know the basics. Someone did exactly this and wrecked a few systems. I was contacted later by the effected organisations holding me directly responsible for the damage that was inflicted. I had no involvement whatsoever but the information that I provided was crucial for the discovery of these targets. This was when I realised that regardless how cool is to publish security research you should always take the necessary steps to ensure that no one is harmed.
Edit: Btw I've also tried repeatedly to get some press coverage of this issue with reporters, but nobody was interested in covering this problem.
This later came back to bite me in the ass when I started messing around with elasticsearch. Elasticsearch had a pretty nasty default that let you run arbitrary code from its query api and within hours my box was compromised.
http://blog.steve.org.uk/secure_your_rsync_shares__please_.h...
Some scary stuff out there, freely available with minimal effort. Of course with rsync things were generally read-only, but even so lots of family financial-data, and pictures.
That is always publish anonymously.
Sorry, but if you're using MongoDB in production, this is the point where you should start reconsidering that. Two years to patch such a gaping security hole, regardless of any 'breakage', is completely unacceptable.
These things are designed for use by people running them on servers that are not directly exposed to the internet. If you're running it in a dev VM with no public address, it's fine. If you're running it on a database-optimized server in your datacenter/cloud which has a firewall only allowing connections from your web-application servers to particular ports, it's fine.
In fact I wouldn't trust mongodb auth anyway, that's not it's focus, much less its strength. Leave the auth to other mechanisms designed for it.
I try not to worry about the infinite multitude of idiots who can follow some bad advice and get some software running. No matter what you do to make things foolproof, human ingenuity comes up with better fools, and in the process you make things more complicated for people who know what they're doing.
"completely unacceptable"? no, reasonable.
Just as well internal attacks and fraud are never a thing, and pivoting attacks up a chain of successively less secure components never happens.
I agree with you on reconsidering MongoDB in production, but administrators failing to secure their systems is not why. Authenticating to a database is an antipattern. Stop making database vendors add this shit: HTTP basic authentication against your NoSQL hotness in prod, on a public IP, is a complete waste of time. Put it in RFC 1918 space or lock down security groups like everybody else and stop losing databases like this. That's what's unacceptable.
Seriously, this stuff is bananas. Now you have to ship passwords around in your automation because you can't be bothered to deploy a real DMZ and private network. Then you have to use Ansible Vault or whatever, and the complexity just rapidly multiplies.
Most enterprise systems e.g. Hadoop listen on all interfaces as well as we are routing traffic over multiple cards e.g. Infiniband. Does that mean we should be reconsidering those choices as well ?
And it's not a gaping security hole. It's a poorly chosen default. And most normal people read and understand the configuration files before they deploy anything into production.
If I can connect to an instance without auth, I can also create a DB and collections etc.
I'm not really one for super fine grained security at the database level, but you should at least have some level of connection controls in place.
iptables isn't that hard.
masscan -p27017 0.0.0.0/0 --excludefile data/exclude.conf
Furthermore, it should be the job of the firewall to limit access to server interfaces/ports, not the services inside of servers. Binding on 0.0.0.0 seems perfectly acceptable, especially for cluster/distributed services that talk amoung themselves.