
Finding MongoDB instances without any authentication - yammesicka
https://blog.shodan.io/its-the-data-stupid/
======
_pdp_
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 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.

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

~~~
vacri
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.

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

~~~
latch
No. It could be simple ignorance. Or an accident.

In your world, what is it at worst? Criminal? Capital?

~~~
alex_anglin
Agreed that it could be either of those things. I'm not trying to excuse
criminal behavior at all, rather stating that if one puts an unauthenticated
database on the internet, it's going to be compromised. For software
professionals, my opinion is that to do so would be negligent.

------
obblekk
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](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.

~~~
dordoka
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/](https://registry.hub.docker.com/u/dordoka/masscan/)

------
nodesocket
I honestly blame DigitalOcean a bit for not providing a VPC and/or a
centralized firewall. It is tedious to configure iptables rules on each server
and easy to overlook and make mistakes.

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.

------
joepie91_
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.

~~~
ploxiln
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 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.

~~~
rodgerd
> 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.

~~~
coldtea
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.

------
jakobdabo
Can't malware/bots use these databases for communication?

~~~
tracker1
Hehe, for that matter it'd make a hell of a means of distribution for illicit
materials (pirate software/movies)...

Think db nodes to find/query for torrents...

~~~
mentat
Open ftp uploads all over again...

------
nevi-me
Am I right that HackedDB could be because someone who noticed the lack of
authentication created such database?

If I can connect to an instance without auth, I can also create a DB and
collections etc.

~~~
achillean
Yes, it could be that there was somebody before me that already noticed this
issue and decided to exploit it :-/ I saw on Twitter that there actually was a
talk in 2013 at DEFCON about these sorts of problems in NoSQL, so in certain
circles it's been known for a while just not acted upon.

~~~
tracker1
It's still surprising... I've used MongoDB a few times, but I was always well
aware to put it behind a firewall and setup basic auth.

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.

------
joshstuart
I just reached out to a very big "startup" that had many many GeeBees
available publicly. Such a rookie mistake!

