Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Security Databases

Over 650 TB of Data Up For Grabs From Publicly Exposed MongoDB Database (csoonline.com) 96

itwbennett writes: A scan performed over the past few days by John Matherly, the creator of the Shodan search engine, has found that there are at least 35,000 publicly accessible and insecure MongoDB databases on the Internet, and their number appears to be growing. Combined they expose 684.8 terabytes of data to potential theft. Matherly originally sounded the alarm about this issue back in July, when he found nearly 30,000 unauthenticated MongoDB instances. He decided to revisit the issue after a security researcher named Chris Vickery recently found information exposed in such databases that was associated with 25 million user accounts from various apps and services, including 13 million users of the controversial OS X optimization program MacKeeper, as reported on Slashdot on Wednesday.
This discussion has been archived. No new comments can be posted.

Over 650 TB of Data Up For Grabs From Publicly Exposed MongoDB Database

Comments Filter:
  • Impressive that 35,000 users forgot how to NAT and firewall. "Oops!"

    • by Anonymous Coward

      I am behind TWO nat/routers/spi firewalls with DD-WRT client bridging.

      This is probably more of an issue for cloud hosted software (data).

      Locking down / securing is never easy for people who just want things to work. I blame the designers of the software and hostiing for this not the user.

      • Re: (Score:2, Informative)

        by Anonymous Coward

        Read the documentation for the software which even comes with reasonable guides for Linux and Windows?

        https://docs.mongodb.org/v3.0/core/security-network/

        For best results and to minimize overall exposure, ensure that only traffic from trusted sources can reach mongod and mongos instances and that the mongod and mongos instances can only connect to trusted outputs.

        Sorry but anybody working in this space should know better.

        • by Anonymous Coward

          Sorry but anybody working in this space should know better.

          Yes, but untrained monkeys work so much cheaper!

        • It's an issue as old as this industry.

          NoSQL needs a boost in adopters to gain momentum and beat-out a lot of entrenched relational databases?

          Easy. Just make it easy. Make it mind numbingly easy to make the database perform useful work. Simple package installation, no need to configure anything away from defaults. Example project can connect and do CRUD-y things in minutes. Explain away security and good practice in the documents no one will read, (because the manual as they see it is the blog post on "

      • by Anonymous Coward

        Locking down / securing is never easy for people who just want things to work. I blame the designers of the software and hostiing for this not the user.

        This. Secure the default install. It's so simple. Turn off services until used. Generate a random password on startup, not a default one. Encrypt partitions automatically during install. Open ports only to the local machine not to the internet by default. Save attachments don't execute. Turn on SSL and not unencrypted connections. etc.etc.

        OpenBSD etc have shown this works. You may lose a few users, but Apple, though far from perfect, has shown that you can do okay security whilst keeping a simple

    • by vtcodger ( 957785 ) on Thursday December 17, 2015 @08:09AM (#51136249)

      Doesn't matter if they forgot or tried, but their defenses were flawed by a misspelling, or misunderstanding, or a semicolon that should have been a colon. Truth is that trying to secure information on computers connected to the Internet of Horrors is roughly equivalent to stashing your wealth in a huge paper tent guarded by an elderly german shepard who has been sedated and two winos who have provided themselves with a liberal supply of cheap booze.

      Folks, this internet thing really does have enormous potential. And it will always be useful for broadcasting and reference work and cat videos. But it's way too complex to provide a reliable vehicle for financial information, personal data, or command and control of most infrastructure. No amount of frantic patching, blaming someone else, and trying to administer remote computers with unknown configurations is going to fix that. This sucker just can't do what "they" want it to do. At least not safely.

      What's the answer? I haven't a clue. But acknowledging that there is a problem is probably a good first step.

      • Isn't it a fundamental issue with the design of these NoSQL DBs? Security seems to be almost an afterthought. Compare and contrast even a bog-standard SQL database like MySQL or Postgres. Unless you're completely mental you can't create a database installation without at least some kind of security.

        Mongo on the other hand comes with access controlled turned off by default.

        Perhaps the answer is start with proven technologies before adding immature tools like Mongo into the mix. And before any NoSQL fan
        • > Security seems to be almost an afterthought.

          By the time you get done activating security high availability, and integrity checking, you've often lowered the performance to below that of a more mature, well-tuned SQL database. There is a very amusing video that covers some of these issues in passing:

          http://www.mongodb-is-web-scal... [mongodb-is-web-scale.com]

      • What's the answer?/p>

        The Cloud, trickle down economics, and CoCo-Puffs.

    • Not NATing is sensible. Not firewalling your unpassworded database? Not so much.

      In the (slight) defense of people running these servers, the article points out that MongoDB's default configuration used to be to accept connections from the internet. They've changed that, but upgrading uses your old config file so you won't get the new defaults automatically.

      But still, this is something you should be checking for.

  • by Sir Holo ( 531007 ) on Thursday December 17, 2015 @07:41AM (#51136177)

    I've posted a clone of this data-cache on my BBS. Just make sure you have at least a 54.6 baud modem, so ensure a speedy download.*

    Long-distance telephone charges may apply.

  • Whom to measures in bits? Dum motha fux.

    • Yes, it should be To, I mean if they specified it in Bytes they'd have to specify the byte size too. 5 bit? 6 bit? 9bit? Who could tell?

    • I'm sure the poster would have typed "TB". Remember how Slashdot's backward article system can't handle Unicode characters? Well, it also messes up the letter case of article titles, first lower casing them then upper casing the first letter of each word - which is why you also see "Mongodb" up there instead of "MongoDB".
  • by JustAnotherOldGuy ( 4145623 ) on Thursday December 17, 2015 @08:16AM (#51136267) Journal

    .....something something webscale.

    If you're gonna leak data, go big or go home!

  • ... that shipping with bad default security settings and/or allowing bad security settings was going to cause an issue: https://www.trustwave.com/Reso... [trustwave.com]
    • by Anonymous Coward

      Unlike, say, Subversion, that stores your passwords in local cleartext by default? At least it announces now when it's doing so the first time. Or unlike, say, every SSH key generator on the planet, that also stores your private SSH keys with no passphrase by default? Or unlike, say, MySQL and Postgresql, that also both are installed with no password by default?

  • by jeffb (2.718) ( 1189693 ) on Thursday December 17, 2015 @08:26AM (#51136299)

    Once AT&T hooks us up, I'll be able to download this volume of data in a mere two months.

    Oh, wait. 1TB monthly data caps.

    Okay, once AT&T hooks us up, I'll be able to download this volume of data in a mere 54 years.

  • by Anonymous Coward

    This is what happens when you let hipster doofus script kiddies decide your database architecture.

  • by Viol8 ( 599362 ) on Thursday December 17, 2015 @08:30AM (#51136331) Homepage

    ... deserves to lose their data as a lesson not top use amateur hour software.

    Field data longer than 8kb? Ooh, can't index that and it won't get returned in a query using that index.

    Shard gets corrupted? Oh bad luck, thats some of your data gone - unless you've used also replication in which case you'll have spent 2 months trying to set it all up.

    Lots of concurrent writes? Yeah, well, with monogdbs single monolithic write lock - good luck with that.

    Want a DB that uses encrypted network transfers between shards and replica sets? Sorry.

    Want a DB that uses a sane query language - ie not one thats a nightmare mashup between pure javascript and parameter passing using javascript to an underpowered underlying query engine? Don't use mongo.

    Etc , the list goes on.

    • Want a DB that uses a sane query language - ie not one thats a nightmare mashup between pure javascript and parameter passing using javascript to an underpowered underlying query engine? Don't use mongo.

      Etc , the list goes on.

      Don't forget that you have different dynamic typing rules to battle with depending on whether you're doing a regular json query (BSON type rules) or whether or not you're doing something javascript-ey (like collection.mapReduce, where you get Javascript type rules).

      Example (code is probably wrong; I'm working off memory and haven't touched Mongo in nearly a year):

      db.collection.insert({foobar: "1"});

      db.collection.find({foobar: 1}); //no results

      db.collection.mapReduce(function(){
      if (this.fooba

    • Shard gets corrupted? Oh bad luck, thats some of your data gone - unless you've used also replication in which case you'll have spent 2 months trying to set it all up.

      To be fair, I think all exposed MongoDBs mentioned in TFA are being replicated right now, so they've inadvertently got that side of things covered! :D

  • by 140Mandak262Jamuna ( 970587 ) on Thursday December 17, 2015 @08:54AM (#51136441) Journal
    It is very much possible many users of Mongodb are not even aware that they are Mongodb users. And also many users of these websites might not know that their web site is using Mongodb unbeknownst to even the web site owners.

    There are so many people with very little internet skills own domains and basically hire someone to build their site. I recently registered a domain and I am being swamped by solicitations to "the new small business owner" about "making a great website to sell your product" with "search engine optimization" and "customer support data base" blah blah blah. Frankly even their email skills are fishy and I am sure they will jury-rig some solution. If they change the default installation to make it less secure, it definitely looks like someone managing something for someone else where convenience overrides security.

    • by PPH ( 736903 )

      This.

      I installed Debian on a laptop some time ago. Occasionally I'd experience some temporary performance issues. A quick review of 'top' showed mongodb to be at the top of the process list, hogging resources. I've looked at a number of apps to figure out what might be using it and found nothing, so I killed it. Nothing seems to have suffered, so I just disabled its startup.

  • MongoDB is web scale. Did this happen because of sharding? That data never would've been breached if they'd stored it on /dev/null. Plus it would have been fast as hell.
  • How do you do a scan of your network to find unsecured NoSQL databases like this? I bet that I'd find a few of them on my work's intranet.

  • MacKeeper's only reason for existence is people who don't know any better. It's malware, pure and simple. I really wish that decent sites would ban MacKeeper ads.

  • "684.8 terabytes of data"

    So wouldn't that be "650TB", not "650Tb"?

    • Headline should be "5.5Pb."

      • No. Headline should be 650 TB. Counting data size in bits makes no sense. Bits are no longer used except to obfuscate figures, or in some very special cases like network speeds, and even there it's mostly used just to brag about high speeds (100 Gb/s !!! Wow !!!).
  • The real problem is that MongoDB is the Visual Basic of databases.

    People have been flocking to MongoDB because they consider SQL databases "too difficult" and "require too much effort". They want something easy that they can just slap together and get up and running, and all other considerations be damned.

    And this is the result. Databases are *not* hard, but they *do* require you to actually think things through. If you can't do that, you shouldn't be doing development to begin with.

  • I up your NoSQL databases with NoSecuritySQL. Not only is it webscale, but it's now it's even faster without security checks.

  • He should be the one taking care of Mongo's databases!

Some people manage by the book, even though they don't know who wrote the book or even what book.

Working...