> Update 2: Earlier this afternoon, Chris Vickery confirmed that the three IP addresses that were disclosing user information have been secured. The issue wasn't a hack, but a misconfigured MongoDB installation.
> The source of the configuration error isn't clear, as neither the ISP nor Sanrio has answered questions on the matter.
A MongoDB database open to the outside world on a public IP address?
This is only true after the Mongo people were lambasted on the web for having such a terribly insecure out of the box product. Which was fairly recently. For years the product would bind to all IP addresses. Which is insane for a default install.
Feb 2015:
Discovered 40,000 vulnerable MongoDB databases on the Internet
These things happen to the best: In 2001, the World Economic Forum had their MS-SQLServer with personal data of the participants connected to the Internet. With the standard account enabled (user: "sa", password: empty). It then got "hacked" and the data leaked.
Why is everybody immediately making these types of diversion responses regarding relational datastores to mongodb breaches? Mongo has popularity and 2 fixable issues that make the exposure numbers outweigh those of every other datastore right now.
1. There is no password prompt during installation. This was the same problem many relational databases had back in the day with default user credentials. Today, I don't know of a single relational datastore that comes with default credentials during installation. (ignoring things that shouldn't go to production like homebrew) Individually, they all said it was a "security threat" and did something about it.
2. Things like MMS or other offering from MongoDB itself expect you expose your nodes externally so they can manage things for you. This can easily be made secure... but its contradictory in nature. It suggests to somebody who probably doesn't know what they're doing on the IT or DevOps fronts to do something more easily dangerous than not... just so they can sell their vendor services to you. Its a recipe for disaster but its also easily fixable with a few design changes on their side.
I guess you could read my post as "others aren't better than MongoDB", but that wasn't my intention. I merely remembered the WEF anecdote and thought I'd mention it here (although it's unfortunate I didn't find an English source for it).
MongoDB is repeating the same mistakes others made 15 years ago.
Apologize, wasn't really directed at you. I'm sure you've seen all the other comments related to this type of news.
Sounds like we both agree that MongoDB is repeating the same mistakes others had made 15 years ago. The only difference is, back then, there was a less dramatic excuse for how it got that way.
> At the moment, there are at least 35,000 publicly available, unauthenticated instances of MongoDB running on the Internet. [...] all of the exposed databases combined account for 684.8 TB of data.
I'm not sure what compels people to download and look at any of these leaks.
There's a real dichotomy between the mostly universal opinion on here that ad tracking is a terrible evil, but downloading and investigating people's private data that was illegally obtained and distributed is okay.
It's interesting to look at? I don't think most people looking at the leaks are trying to profit (exception of people exploiting people based on the data). Ad systems however, are always looking at the data as a way to increase profits.
So violating people's personal privacy is okay if it's interesting to look at? I guess people who put hidden cameras in bathrooms feel the same way as you.
subie didn't claim it was okay. It was just a guess at the implied question in "I'm not sure what compels people to download and look at any of these leaks."
No, I'm saying the person who did the leak or placed the camera did the breach of privacy. You want to say everyone looking at is also breaching the privacy. I'd say they are simply looking at the result of a breach not committing another one.
"There's a real dichotomy between the mostly universal opinion on here that ad tracking is a terrible evil, but downloading and investigating people's private data that was illegally obtained and distributed is okay."
What differs between these two is that the ad system is the person placing the camera, watching the video and distributing. The interested person is simply watching the video. Sure that doesn't seem fair to the victim but if they are not trying to exploit the victim I don't think it's a problem.
Often vegetarians will eat meat that was served to them by mistake. They don't want to contribute to demand for meat products, but if one has already been served to them it can't be taken back. There's no further harm in eating it.
Crooks will look at it to see what they can get out of it. Passwords, email, blackmail material. If nobody benevolent looks at it would we ever know what was actually leaked?
After previous leaks, the data has been looked over to produce lists of compromised accounts which at least one website lets you search to know if your account was in the leak (Kotaku/Gawker leaked my shit years ago). The data can be used to provide stats on the most common passwords.
Can we please get password storage built in to databases as a dedicated column type already? There are N-to-infinity crappy languages and CMS's out there, but only a handful of databases. It's becoming clear that widespread standard library support for decent password hashing just isn't enough to get people moved over.
No, because even this would be a total cock-up. Don't give anybody your password, and just can't mess it up. So i'm not really in favour of fixing backends at all. I think the password problem is entirely the browser vendors reponsibility. Solid password authentication already exists in TLS (which you need anyway), it's just not widely implemented or exposed via browser UIs.
There are too many vested interests from the big players, where the hope is that deliberately making authentication ever more burdensome for users will just lead them to give up and select 'login with Facebook/Google/Live' and hand them the keys to the kingdom.
This sounds like such an obviously great idea that I don't know how I haven't heard it before. Can someone who understands how databases are built explain why this isn't an obviously great idea?
The elephant in the room is what you return when you SELECT.
My POV is you should be able to verify user sign-in with something like "SELECT COUNT(*) FROM users WHERE email = 'maaku@hellokitty.com' AND password='hunter2';", which has the added bonus of not informing the client whether the query failed because the user didn't exist, or because the password was wrong. Imho, all queries for the column content should simply fail.
Note that this approach can expose the user entered password in application debug logs, MySQL's slow queries log (if you're not using bind variables), etc.
One thought is that it puts the computational load of verifying user-provided passwords in your database tier, rather than in your application tier, where it exists today. Let's say that right now, you have a 200ms computation necessary to verify a bcrypt-secured password. If you have that in your application tier, you can easily scale that horizontally with more CPUs if necessary. It may be a bit more difficult to scale CPU capacity in the database tier.
However, another approach would be extension of the database's client-server protocol and driver(s) such that the hash verification occurs within the application tier (as part of the driver). Or, moving further along that path, the field could be annotated in your ORM, exposing special set and verify methods. But at that point, you're very close to the current condition, where the hashing occurs within your web application framework.
Any good tutorial on how to deal with passwords? In a site of mine I generate a salt with UUIDv4 and generate a sha512 of the passsword+salt and store both the salt and hash. When the user authenticates I regenerate the hash and check. This is good, right? I still don't know how to deal with cookies/sessions though. And have no idea how basic http auth works.
I'd search myself but I'm afraid to find a "bad" tutorial.
Just use one of the existing key derivation functions. Scrypt and bcrypt should be good enough for most use cases, but you may want to google a bit before settling on one.
There's no way to beat around the bush: No, it is not good. It's better than a lot of sites, but it's still nowhere near good enough.
The key is speed: it's too fast. Far faster than you need it to be. Fast enough that attackers could attempt very large numbers of passwords per second.
What you want is something slow, to slow down the attackers.
Probably the most popular choice is bcrypt, and you can't go wrong making that decision. In some environments you may need something more standardised / accepted, in which case you want to look at PBDKF2. There's also scrypt, which is a bit stronger than bcrypt, but a bit newer.
_Any of these three are uncontroversial choices._ Using any of them is better than using just about anything else, and the gap between each of them is much smaller than the gulf between those three and schemes such as yours.
Once you've picked one you also need to tune it: make it as slow as you can bear. If your users won't be driven away by login taking a whole second, then make it take a whole second! The key is making it slow.
---
One broader piece of advice: Don't reinvent the wheel when it comes to security things. Passwords, sessions, and so on, you should be looking for well-supported, maintained, high-quality libraries that have been vetted for design and implementation mistakes. There's libraries out there to solve these problems, if you aren't a security expert you should be using them :)
Postgres has plenty of awesome data formats (JSON! Polygon areas!) that are rarely used, either because developers aren't aware, or Hibernate/ORMs don't support it, or devs only use features that are in all databases, you know, in case someone decides to switch dbs.
Almost as you said below: Passwords are long overdue. They are lost, written down, or 1password becomes the single point of failure, keylogged, recoverable by email, prone to brute-force or more clever attacks, the user types them in the username field (my security teacher did exactly that in front of the whole class while saying it), or worse, in the group chat window that just popped up...
We needed Persona. We needed an open marketplace for password replacement. Bash & SSH have pretty much gotten rid of passwords. I'd bet a year in prison that Mozilla has been served an NSL and ordered to shut down the project.
This is an interesting idea. I think you could take it a little further though.
How about databases explicitly disallow direct comparison or materialization of any field named 'Password', 'Passwd' etc. I'm aware that this would be a breaking change, and would require overrides to support legacy software. That said, the defaults would lead developers to a secure by default mindset. If n00b dev1 realizes that s/he can't store a password and get it back again, they go looking for why and find that the only way is to call something like:
SELECT IsPasswordValid(Password, @Password) FROM Users
UPDATE Users
SET Password = StorePassword(@Password)
Edit: I realize that there are security issues with the suggested sql. A PAKE is probably necessary.
This is the same guy that uncovered the MacKeeper user database as well, which also used MongoDB. From what I've read, he just used Shodan to uncover these instances. This isn't meant to discredit him, but it interesting how we're calling people like this "security researchers".
56 comments
[ 2.9 ms ] story [ 84.6 ms ] thread> The source of the configuration error isn't clear, as neither the ISP nor Sanrio has answered questions on the matter.
A MongoDB database open to the outside world on a public IP address?
But yeah, that's not good.
It also implies frontend server includes the DB, typically a sysadmin would de-couple it so this shows lack of experience.
The default configuration for MongoDB is to listen on localhost only. Someone changed the configuration if it was listening on a public IP.
That's true, but I remember that change was only made recently. Before, mongo would listen on all IPs and had no passwords.
Feb 2015:
Discovered 40,000 vulnerable MongoDB databases on the Internet
http://securityaffairs.co/wordpress/33487/hacking/40000-vuln...
The changes were made after this, so we're only talking a few months now.
German article about it: https://www.woz.ch/-41f8
1. There is no password prompt during installation. This was the same problem many relational databases had back in the day with default user credentials. Today, I don't know of a single relational datastore that comes with default credentials during installation. (ignoring things that shouldn't go to production like homebrew) Individually, they all said it was a "security threat" and did something about it.
2. Things like MMS or other offering from MongoDB itself expect you expose your nodes externally so they can manage things for you. This can easily be made secure... but its contradictory in nature. It suggests to somebody who probably doesn't know what they're doing on the IT or DevOps fronts to do something more easily dangerous than not... just so they can sell their vendor services to you. Its a recipe for disaster but its also easily fixable with a few design changes on their side.
MongoDB is repeating the same mistakes others made 15 years ago.
Sounds like we both agree that MongoDB is repeating the same mistakes others had made 15 years ago. The only difference is, back then, there was a less dramatic excuse for how it got that way.
Maybe someone was inspired by this article?
https://blog.shodan.io/its-still-the-data-stupid/
> At the moment, there are at least 35,000 publicly available, unauthenticated instances of MongoDB running on the Internet. [...] all of the exposed databases combined account for 684.8 TB of data.
"Hello Kitty fan site exposed, but no data stolen: web host"
"There is no evidence any data has been stolen, the Hong Kong-based company hosting the data said on Tuesday."
http://in.reuters.com/article/us-sanrio-cyberattack-idINKBN0...
"Hello Kitty and Minnie Mouse arrested after fight over tip money in New York's Times Square."
http://www.mirror.co.uk/news/weird-news/hello-kitty-minnie-m...
No, some things are better left unknown.
There's a real dichotomy between the mostly universal opinion on here that ad tracking is a terrible evil, but downloading and investigating people's private data that was illegally obtained and distributed is okay.
[citation needed]
"There's a real dichotomy between the mostly universal opinion on here that ad tracking is a terrible evil, but downloading and investigating people's private data that was illegally obtained and distributed is okay."
What differs between these two is that the ad system is the person placing the camera, watching the video and distributing. The interested person is simply watching the video. Sure that doesn't seem fair to the victim but if they are not trying to exploit the victim I don't think it's a problem.
After previous leaks, the data has been looked over to produce lists of compromised accounts which at least one website lets you search to know if your account was in the leak (Kotaku/Gawker leaked my shit years ago). The data can be used to provide stats on the most common passwords.
Can we please get password storage built in to databases as a dedicated column type already? There are N-to-infinity crappy languages and CMS's out there, but only a handful of databases. It's becoming clear that widespread standard library support for decent password hashing just isn't enough to get people moved over.
There are too many vested interests from the big players, where the hope is that deliberately making authentication ever more burdensome for users will just lead them to give up and select 'login with Facebook/Google/Live' and hand them the keys to the kingdom.
My POV is you should be able to verify user sign-in with something like "SELECT COUNT(*) FROM users WHERE email = 'maaku@hellokitty.com' AND password='hunter2';", which has the added bonus of not informing the client whether the query failed because the user didn't exist, or because the password was wrong. Imho, all queries for the column content should simply fail.
I would add that the 'bonus' of not informing of the correct error provides minimal security gain and hurts usability.
This would be a bug. There should be no way for someone with my e-mail address to determine if I use any particular service.
However, another approach would be extension of the database's client-server protocol and driver(s) such that the hash verification occurs within the application tier (as part of the driver). Or, moving further along that path, the field could be annotated in your ORM, exposing special set and verify methods. But at that point, you're very close to the current condition, where the hashing occurs within your web application framework.
Or hashing could be done on the client side.
Only if you use a proper PAKE. A vanilla password hash is still a bearer token on the wire.
I'd search myself but I'm afraid to find a "bad" tutorial.
The key is speed: it's too fast. Far faster than you need it to be. Fast enough that attackers could attempt very large numbers of passwords per second.
What you want is something slow, to slow down the attackers.
Probably the most popular choice is bcrypt, and you can't go wrong making that decision. In some environments you may need something more standardised / accepted, in which case you want to look at PBDKF2. There's also scrypt, which is a bit stronger than bcrypt, but a bit newer.
_Any of these three are uncontroversial choices._ Using any of them is better than using just about anything else, and the gap between each of them is much smaller than the gulf between those three and schemes such as yours.
Once you've picked one you also need to tune it: make it as slow as you can bear. If your users won't be driven away by login taking a whole second, then make it take a whole second! The key is making it slow.
---
One broader piece of advice: Don't reinvent the wheel when it comes to security things. Passwords, sessions, and so on, you should be looking for well-supported, maintained, high-quality libraries that have been vetted for design and implementation mistakes. There's libraries out there to solve these problems, if you aren't a security expert you should be using them :)
The catch is one of "what platform are you using", as bindings are somewhat limited.
Almost as you said below: Passwords are long overdue. They are lost, written down, or 1password becomes the single point of failure, keylogged, recoverable by email, prone to brute-force or more clever attacks, the user types them in the username field (my security teacher did exactly that in front of the whole class while saying it), or worse, in the group chat window that just popped up...
We needed Persona. We needed an open marketplace for password replacement. Bash & SSH have pretty much gotten rid of passwords. I'd bet a year in prison that Mozilla has been served an NSL and ordered to shut down the project.
How about databases explicitly disallow direct comparison or materialization of any field named 'Password', 'Passwd' etc. I'm aware that this would be a breaking change, and would require overrides to support legacy software. That said, the defaults would lead developers to a secure by default mindset. If n00b dev1 realizes that s/he can't store a password and get it back again, they go looking for why and find that the only way is to call something like:
Edit: I realize that there are security issues with the suggested sql. A PAKE is probably necessary.