6 ms·

Finding MongoDB instances without any authentication

131 points by yammesicka 11y ago

_pdp_ 11y ago
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 11y ago
  They're entirely responsible for the damage that was inflicted. Attempting to shift the blame to you is childish at best.
  - _pdp_ 11y ago
    Maybe, but there is such thing as responsible disclosure.
  - vacri 11y ago
    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 11y ago
      Maybe, but running unauthenticated databases on the public internet is negligent at best.
      - latch 11y ago
        No. It could be simple ignorance. Or an accident. In your world, what is it at worst? Criminal? Capital?
        alex_anglin 11y ago
        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.
        mentat 11y ago
        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.
        threatofrain 11y ago
        Of course it depends on the context. I don't know if it's reasonable to expect a small family clinic, therapist, or dental office to secure their client information. It seems that people just mass scan the internet looking for already known vulnerabilities. However, if it's a mid-sized business handling important information, like payment information, then I do think there ought to be a standard of dutiful behavior, because otherwise who pays for the externalities?
        vacri 11y ago
        It could also be leftover testing systems that haven't been torn down yet, with nothing interesting in them. The internet is full of them.
    - SamReidHughes 11y ago
      Why shouldn't we blame victims too? Should we not blame victims of shark attacks that swim in shark-infested waters?
      - vacri 11y ago
        Have another go at interpreting my comment.
    - deleted 11y ago
      [deleted]
- greglindahl 11y ago
  blekko's search engine received a lot of automated queries looking for that kind of info -- that and SEO ranking research were our top 2 types of automated search.
- achillean 11y ago
  I've tried to reach out for a few years now and spoke about it at every opportunity but for some reason people just aren't interested in looking at databases. Most of these MongoDB instances are running old versions and given the popularity of the project I suspect that this is a tiny fraction of deployments. Btw I'm still trying to find contacts at some organizations that are affected, but it's actually surprisingly difficult to reach somebody that is in charge of security :-/ Especially with servers hosted in the cloud doing attribution is difficult! 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.
- stevekemp 11y ago
  I did the same thing, spidering for open rsync shares: http://blog.steve.org.uk/secure_your_rsync_shares__please_.html 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.
- nemothekid 11y ago
  I remember (maybe it was the same service shodan) a year ago, looking at its scanning interface and seeing my instance of my toy database listed as open. I didn't think anything of it, and was too lazy to do anything about, but I've been aware for quite some time now that people will do ip scans against common ports. 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.
- realusername 11y ago
  That's exactly the reason why I'm not reporting anything anymore. The legal aspect is just really badly designed for this kind of situation. If I find something opened or unsecured by mistake, I just go somewhere else and don't report anything so this way I don't risk anything. That's sad because it's not helping anyone but I just don't want to handle any legal stuff.
  - redcalx 11y ago
    Sure, that's the legal environment we find ourselves in, and in many respects it's short sighted and counter productive, i.e. it actually fosters weak security in critical settings and the chance of those weaknesses being taken advantage of by malicious entities.
- eugeneionesco 11y ago
  >always take the necessary steps to ensure that no one is harmed. That is always publish anonymously.
- yeukhon 11y ago
  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.
jakobdabo 11y ago
Can't malware/bots use these databases for communication?
- captn3m0 11y ago
  Yes, but then you build your own layer of auth on top of it. Signed messages should work fine, though. Its an interesting idea, for sure.
- tracker1 11y ago
  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 11y ago
    Open ftp uploads all over again...
obblekk 11y ago
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 11y ago
  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/
nevi-me 11y ago
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 11y ago
  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 11y ago
    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.
joepie91_ 11y ago
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 11y ago
  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.
  - achillean 11y ago
    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.
    - threeseed 11y ago
      It actually affects a tonne of products, period. It's quite popular in enterprise software to listen on all interfaces.
  - rodgerd 11y ago
    > 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.
nodesocket 11y ago
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.
joshstuart 11y ago
I just reached out to a very big "startup" that had many many GeeBees available publicly. Such a rookie mistake!

131 points by yammesicka 11y ago

_pdp_ 11y ago

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 11y ago
They're entirely responsible for the damage that was inflicted. Attempting to shift the blame to you is childish at best.
- _pdp_ 11y ago
  Maybe, but there is such thing as responsible disclosure.
- vacri 11y ago
  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 11y ago
    Maybe, but running unauthenticated databases on the public internet is negligent at best.
    - latch 11y ago
      No. It could be simple ignorance. Or an accident. In your world, what is it at worst? Criminal? Capital?
      - alex_anglin 11y ago
        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.
      - mentat 11y ago
        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.
      - threatofrain 11y ago
        Of course it depends on the context. I don't know if it's reasonable to expect a small family clinic, therapist, or dental office to secure their client information. It seems that people just mass scan the internet looking for already known vulnerabilities. However, if it's a mid-sized business handling important information, like payment information, then I do think there ought to be a standard of dutiful behavior, because otherwise who pays for the externalities?
      - vacri 11y ago
        It could also be leftover testing systems that haven't been torn down yet, with nothing interesting in them. The internet is full of them.
  - SamReidHughes 11y ago
    Why shouldn't we blame victims too? Should we not blame victims of shark attacks that swim in shark-infested waters?
    - vacri 11y ago
      Have another go at interpreting my comment.
  - deleted 11y ago
    [deleted]
greglindahl 11y ago
blekko's search engine received a lot of automated queries looking for that kind of info -- that and SEO ranking research were our top 2 types of automated search.
achillean 11y ago
I've tried to reach out for a few years now and spoke about it at every opportunity but for some reason people just aren't interested in looking at databases. Most of these MongoDB instances are running old versions and given the popularity of the project I suspect that this is a tiny fraction of deployments. Btw I'm still trying to find contacts at some organizations that are affected, but it's actually surprisingly difficult to reach somebody that is in charge of security :-/ Especially with servers hosted in the cloud doing attribution is difficult! 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.
stevekemp 11y ago
I did the same thing, spidering for open rsync shares: http://blog.steve.org.uk/secure_your_rsync_shares__please_.html 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.
nemothekid 11y ago
I remember (maybe it was the same service shodan) a year ago, looking at its scanning interface and seeing my instance of my toy database listed as open. I didn't think anything of it, and was too lazy to do anything about, but I've been aware for quite some time now that people will do ip scans against common ports. 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.
realusername 11y ago
That's exactly the reason why I'm not reporting anything anymore. The legal aspect is just really badly designed for this kind of situation. If I find something opened or unsecured by mistake, I just go somewhere else and don't report anything so this way I don't risk anything. That's sad because it's not helping anyone but I just don't want to handle any legal stuff.
- redcalx 11y ago
  Sure, that's the legal environment we find ourselves in, and in many respects it's short sighted and counter productive, i.e. it actually fosters weak security in critical settings and the chance of those weaknesses being taken advantage of by malicious entities.
eugeneionesco 11y ago
>always take the necessary steps to ensure that no one is harmed. That is always publish anonymously.
yeukhon 11y ago
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.

jakobdabo 11y ago

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

captn3m0 11y ago
Yes, but then you build your own layer of auth on top of it. Signed messages should work fine, though. Its an interesting idea, for sure.
tracker1 11y ago
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 11y ago
  Open ftp uploads all over again...

obblekk 11y ago

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 11y ago
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/

nevi-me 11y ago

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 11y ago
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 11y ago
  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.

joepie91_ 11y ago

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 11y ago
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.
- achillean 11y ago
  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.
  - threeseed 11y ago
    It actually affects a tonne of products, period. It's quite popular in enterprise software to listen on all interfaces.
- rodgerd 11y ago
  > 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.

nodesocket 11y ago

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.

joshstuart 11y ago

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