1. 44
  1.  

  2. 15

    The attacks don’t target all MongoDB databases, but only those left accessible via the Internet and without a password on the administrator account.

    So this isn’t a Mongo-specific problem, this is a deployment issue.

    It is very hard to believe that after this highly-mediatized rash of ransom attacks any database administrator won’t double-check to see if his MongoDB server is available online and if the admin account doesn’t use a strong password.

    Ditto to this.

    In a couple of weeks, it is reasonable to expect that all MongoDB servers exposed to the Internet will lose their data and have their content replaced with a ransom demand.

    These “hackers” aren’t doing anything particularly intelligent, only targeting unsecured Mongo instances, so I don’t see where this statement is coming from. If everyone who publicly exposes Mongo to the Internet set the admin password, it sounds like the problem would be solved.

    1. 28

      This is focusing on Mongo mostly because “no password, bind all” is the default setting for any mongo deployment as it assumes you have a working firewall.

      I have a web service (forum) that uses a “no password” mongo, but I only make it bind to a loopback address which I can probe from the outside using SSH tunnels if needed (and if anything happens, I still have daily backups). Even if I didn’t modify the settings to let it bind to that port, my firewall would have stopped the server from being publicly accessible.

      1. 25

        This is a deployment issue.

        I thought this, so I read their Python Getting Started Guide - not a single mention of authentication.

        You either have great documentation with big warning signs or safe secure defaults. Mongo currently has neither.

        Personally, I would always advocate safe secure defaults, not everything can be solved with education.

        1. 6

          I agree with you, I was mostly commenting on the sensationalism of the prose. This sort of “hack” is not all that advanced, it comes from misconfiguration. The default configuration should of course be more secure by default, there have been a number of articles written to this effect, cf. this one from Shodan ~1 year ago warning about this very issue with Mongo, and how easy it is to exfil/destroy publicly accessible instances.

          1. 6

            Absolutely, it’s the equivalent of a port scan. Some “hack”.

            It is very hard to believe that after this highly-mediatized rash of ransom attacks any database administrator won’t double-check

            I do take issue with this though as it makes some assumptions which from experience have never been true: a) that any given deployment will have a database administrator & 2) that said database administrator will be competent.

            To expect developers that have picked a database based on how easy it is to dump JSON in to have any clue about secure database deployment is asking way too much. And the only way to solve that is, as you say, sane defaults.

            1. 2

              To expect developers that have picked a database based on how easy it is to dump JSON in to have any clue about secure database deployment is asking way too much.

              maybe i’m missing sarcasm here. imho, one of the first things one has to do when using new software which is reachable from the network is to check how access can be restricted. regardless if developer or admin. if you use a new power tool which has the capability to maim yourself, you are also expected to take the common precautions.

              1. 4

                No sarcasm, it was aimed at new developers though. Expecting new developers to know the world == trouble. To be clear: the “imho” line is your (good) view, which you’ve probably garnered from years of experience and mistakes: a new developer would not have that world view yet.

                It causes very little extra pain to have some form of authentication by default. Then the user of said software has to learn about authentication from the get go, and expects that they have to handle it post deployment. It’s about creating the right intentions.

                1. 4

                  Many of my younger colleagues simply don’t know how packets get from point A to point B, as well. So the idea that it could be insecure is surprising or something they just don’t consider.

                  1. 2

                    i’d like sane defaults for authentication too. it just feels wrong that the expectations for the knowledge of developers are that low :/

          2. 13

            I wouldn’t say it’s a deployment problem per se. I believe it’s more of a consequence of the industry valuing products that are “easy” above all else. Defense In Depth is a pretty standard security perspective and popular solutions such as Cassandra, Riak, MongoDB, and redis all prioritize making the default configuration very simple at the cost of security. But that’s what the people want.

            I’m not saying it’s ok to open your database up to the world but just that this is expected if you look at the incentives users are giving authors of databases these days.

            1. 9

              So this isn’t a Mongo-specific problem, this is a deployment issue.

              It is Mongo specific in that the default settings of MongoDB are brain dead and stupid with respect to security.

              It is very hard to believe that after this highly-mediatized rash of ransom attacks any database administrator won’t double-check to see if his MongoDB server is available online and if the admin account doesn’t use a strong password.

              Ditto to this.

              Again, this is somewhat Mongo specific because (a big IME here) MongoDB administrators are not usually at the same level as traditional DBAs. That’s why we’re seeing thousands of MongoDB instances compromised, and no mention of PostgreSQL, Oracle, MySQL, DB2, etc. Sure, this attack is possible with those databases, but they have more sane defaults, and their admins (again, IME) have a better idea of what they’re doing, so it’s not so much an issue there. Yes, now and then you’ll see some idiot leave his Oracle DB exposed, but you don’t see thousands and thousands of Oracle DBs exposed all at once for the same reason.

              These “hackers” aren’t doing anything particularly intelligent, only targeting unsecured Mongo instances, so I don’t see where this statement is coming from. If everyone who publicly exposes Mongo to the Internet set the admin password, it sounds like the problem would be solved.

              From the context it’s clear that “exposed to the Internet” in that statement is referring specifically to the MongoDB instances using the default setting of no password and no firewall.

              I agree with you that it’s really low hanging fruit as far as “hacking” goes. The MongoDB community should be really embarrassed about this.

              1. 5

                It seems it’s easy to hyper-inflate the impact or serious skill of a particular culprit behind acts like this. E.g., the Podesta phishing scandal & related events had the momentum of a US Presidential election behind their news cycle, even so it was highly over excitable in its attempt to paint the hacker a Mr. Robot Dark Army type person.

                The problem isn’t “oh shit hackers are dangerous” it’s “people should learn fundamental cybersecurity concepts before deploying anything with even remotely identifiable or important information.”

                Count me as a cynic, but if you don’t put a password on your internet-connected database administration account… then you can eat a plate of crow and stfu. Wake up tomorrow and start using better security practices. This is natural selection. We must expect and prepare for the worst, not just hope for the best.

                1. 2

                  https://snyk.io/blog/mongodb-hack-and-secure-defaults/ is spot on. This happened because of ridiculous defaults.

                  Apparently MongoDB disabled public access by default in April 2014:

                  https://docs.mongodb.com/manual/release-notes/2.6/#security-improvements

                  … so apparently lots of configurations have been left untouched for years. Sounds about what one would expect.

                  1. 0

                    But MongoDB is web scale!

                    1. 1

                      Indeed, it quickly escalated to 10.000.

                      1. 1

                        28.000 now!