One Petabyte of Data Exposed Via Insecure Big Data Systems 50
chicksdaddy writes: Behind every big data deployment is a range of supporting technologies like databases and memory caching systems that are used to store and analyze massive data sets at lightning speeds. A new report from security research firm Binaryedge suggests that many of the organizations using these powerful data storage and analysis tools are not taking adequate steps to secure them. The result is that more than a petabyte of stored data is accessible to anyone online with the knowledge of where and how to look for it.
In a blog post on Thursday, the firm reported the results of research that found close to 200,000 such systems that were publicly addressable. Binaryedge said it found 39,000 MongoDB servers that were publicly addressable and that "didn't have any type of authentication." In all, the exposed MongoDB systems contained more than 600 terabytes of data stored in databases with names like "local," "admin," and "db." Other platforms that were found to be publicly addressable and unsecured included the open source Redis key-value cache and store technology (35,000 publicly addressable instances holding 13TB of data) and 9,000 instances of ElasticSearch, a commonly used search engine based on Lucene, that exposed another 531 terabytes of data.
In a blog post on Thursday, the firm reported the results of research that found close to 200,000 such systems that were publicly addressable. Binaryedge said it found 39,000 MongoDB servers that were publicly addressable and that "didn't have any type of authentication." In all, the exposed MongoDB systems contained more than 600 terabytes of data stored in databases with names like "local," "admin," and "db." Other platforms that were found to be publicly addressable and unsecured included the open source Redis key-value cache and store technology (35,000 publicly addressable instances holding 13TB of data) and 9,000 instances of ElasticSearch, a commonly used search engine based on Lucene, that exposed another 531 terabytes of data.
Re: (Score:1)
NoSql = NoSecurity
Re: (Score:1)
Okay, that was over time top, I admit. How about "immature security"?
No, it's because the tools aren't user-friendly. (Score:2)
The tools aren't user friendly.
Setting up authentication for a web api should be trivial. Right now it's not--you can figure it out, but it's substantially more complicated than Googling "what authentication model should I use for this" and adding a couple of lines to your source files. Many programmers outside of critical areas are not going to spend enough time on it to get it right so long as that is true.
Making it worse is bad auth implementations by third-party providers which consume programmer-hour
Re: (Score:2)
I disagree. The problem is people that vastly over-estimate their own skills and insights and then proceed to mess it up. Authentication is never a trivial thing. Faking that triviality only makes things worse.
Re: (Score:2)
Yes and no. Just because it's hard to do well doesn't mean you can't make it easier to implement. The easier you make good programming, the more likely people are to do it. The entire point of API documentation, for example, is to make it easier to do good programming.
On web app scecurity, right now there's a hodge-podge of solutions and no clear industry leader for a secure and efficient answer.
They !!! (Score:3)
Re: (Score:2)
Worthless server logs???
Sure, nothing that would aid an intruder in server logs...
Re: (Score:2)
I have worked at more than a couple of places where the Oracle database and application passwords were all the default from installation
It can take a lot of work to identify every dependency on the defaults once that they have been in use for a few years and way too many admins just do not want to deal with it
Oracle used to have a sense of humor about it with one of the key default passwords being 'change_on_install', now they force you into a password generation cycle at the end of any install
Moreover, nev
Re: (Score:2)
Urethra Franklin is my fav.
No need to secure it (Score:4, Funny)
There's no need to secure mongoDB because it's webscale. That means it's invulnerable to hackers and bad programming.
Re: (Score:1)
There's no need to secure mongoDB because it's webscale. That means it's invulnerable to hackers and bad programming.
Was funny years ago.
https://www.youtube.com/watch?v=b2F-DItXtZs
Re: (Score:1)
At this point in time I would like to submit, for evidence, the GPs user name and indicate that, as such, they are likely to be "old."
So, of course, it stands to reason that their joke would have been funny years ago.
Re: (Score:1)
There is a high probability of your being mentally unstable. I wish you luck.
Re: (Score:1)
Is your life that boring? They replied with gibberish. Sheesh. Gibberish. If you want you can actually review the whole thing just for taking the time. Look carefully at the usernames. Unless you are all of them, in that case, I pay a lot for your insurance - take advantage of it.
Re: (Score:1)
Is your life that boring and meaningless? I know you think you're trolling and all but, no... I am afraid you don't get to rustle my jimmies because I can just point out that you're not that bright and be done or I can keep pointing it out and you keep coming back to amuse me. Which, really, has snared the other?
memcached (Score:2)
Status of memcached is quite infortunate. We need it to share sessions across hosts, which is a requirement for load balancing, but it has no authentication feature
I read that latest versions support SASL, though.
Clinton e-mails (Score:1)
So, how many of these databases contain Clinton's e-mail stash?
It's OK... (Score:2)
It's OK... it puts most of the bad guys over their data caps when they attempt to download it all.
What about data corruption or sabotage? (Score:2)
Even one focuses on ID theft. But how about some one intentionally corrupting data such as the 'deleted_beacuse_you_didn't_password_protect_your_mongodb' entry.
By corrupting data you can create a 'Tuttle vs Buttle' event if those data are use for intelligence dragnets or throw a nice monkey wrench into someones high speed trading algorithm. Remember, your results are only as good as your data allow them to be.
cali drought. (Score:1)
I'm lazy. (Score:2)
more than a petabyte of stored data is accessible to anyone online with the knowledge of where and how to look for it.
(Readable sites and login-credentials) picts or it didn't happen.
On an on-topic item: I, too, worked for a company where the SOP was to run a NAS with over 12PB of storage and the default credentials were used "for support reasons." For the rounding-off-error area of 40TB I controlled I was finally able to extract a concession and change a single character of the password: an "o" to a "0".
At least it wasn't accessible on the internet. And that change kept anyone internally from logging into my sectio
Re: (Score:1)
Of course, seeing as the USA is sick, they can now afford to go to their doctor thanks to the ACA.
Standard Joke (Score:2)
Insert "MongoDB only pawn in game of life" reference here.
obligatory xkcd (Score:2)
https://xkcd.com/1553/ [xkcd.com]