Live data from Hacker News

Finding MongoDB instances without any authentication

blog.shodan.io

31–40 of 44 posts

Re: Finding MongoDB instances without any authentication

#31

Holy crap, TWO YEARS to patch an insecure default? 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.

You're talking nonsense.

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.

Re: Finding MongoDB instances without any authentication

#32
post #17

Earlier quoted context omitted.

memcached has the same default to this day - listen on all interfaces, no auth. 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…

Yeah... Memcached is one of the other ones that has the same problem but around 100,000 public instances... Maybe I shouldn't have even mentioned MongoDB since everybody's so focused on it now, but this sort of configuration issue affects a ton of database products.

It actually affects a tonne of products, period.

It's quite popular in enterprise software to listen on all interfaces.

Re: Finding MongoDB instances without any authentication

#33
post #2

This information is dangerous :) 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 rock…

This is known for many years so author is not the first to acknowledge that problem (just do an online search). This is a known operational problem / must-avoid / best practice for Mongo deployment.

Re: Finding MongoDB instances without any authentication

#34
post #23
post #17

Earlier quoted context omitted.

memcached has the same default to this day - listen on all interfaces, no auth. 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…

> These things are designed for use by people running them on servers that are not directly exposed to the internet. Just as well internal attacks and fraud are never a thing, and pivoting attacks up a chain of successively less secure components never happens.

For any given system you can saw me I can show you 100 things that could be extra hardened.

At some point you stop caring about security and start caring about convenience / practically.

Re: Finding MongoDB instances without any authentication

#35
post #27

Earlier quoted context omitted.

Maybe, but running unauthenticated databases on the public internet is negligent at best.

No. It could be simple ignorance. Or an accident. In your world, what is it at worst? Criminal? Capital?

An ignorance is an excuse for compromising your company or customer's data in exactly what situations? Let's just all cover our eyes and not look, then the data will be safe I'm sure.

Re: Finding MongoDB instances without any authentication

#37
post #8

FYI: if you don't want to pay shodan for search results, you could run your own port scan using masscan( https://github.com/robertdavidgraham/masscan ) by running the command masscan -p27017 0.0.0.0/0 --excludefile data/exclude.conf Be warned that this will scan the entire IPv4 namespace.

If somebody wants to give obblekk's suggestion a try, you can use my docker masscan container right away [0]

[0] https://registry.hub.docker.com/u/dordoka/masscan/

Re: Finding MongoDB instances without any authentication

#38
post #21
post #4

Earlier quoted context omitted.

They're entirely responsible for the damage that was inflicted. Attempting to shift the blame to you is childish at best.

This is a victim-blaming myth. The prime responsibility for the damage is the person who did the damage. Not the discloser, and not the victim.

Why shouldn't we blame victims too? Should we not blame victims of shark attacks that swim in shark-infested waters?

Re: Finding MongoDB instances without any authentication

#39
post #21

Earlier quoted context omitted.

This is a victim-blaming myth. The prime responsibility for the damage is the person who did the damage. Not the discloser, and not the victim.

Why shouldn't we blame victims too? Should we not blame victims of shark attacks that swim in shark-infested waters?

Have another go at interpreting my comment.

Re: Finding MongoDB instances without any authentication

#40

Earlier quoted context omitted.

Regardless of my thoughts on MongoDB in particular, if you are relying upon authentication mechanisms built into infrastructure software so that you can put, say, MongoDB on a public IP address and communicate in the open, you are operating your infrastructure completely unacceptably. There is absolutely zero excuse for not doing this right, and if MongoDB's default fucked you here, you're not doing it right in the f…

You're missing the point. Listening on all interfaces was the default . Defaults should be secure and fail-closed, and that it takes them two years to patch that is extremely worrying.

I wouldn't worry so much. What can you infer by that? It's completely normal that people working on database engines don't know that much about operational stuff like what network connections to listen to. The product I used to work on, for example, had this exact same misfeature. The real motivation for fixing it was that developer machines would be listening to the outside world, whenever we or our users ran tests and such. The idea that people would run it this way in production was completely foreign to me, personally.
Post reply on HN