3 ms·

"Messing with configurations" enough to add a password requires no more specialized knowledge than installing a database server. Personal responsibility has to

"Messing with configurations" enough to add a password requires no more specialized knowledge than installing a database server. Personal responsibility has to come in to play at some point here. We're talking about real companies who said "We're going to put all of our data into this system and not set a password", not a fast food worker trying to pick up Rails development in his/her free time. Furthermore, running "apt-get install" usually isn't enough to get something exposed onto the public network, even for home users, whose routers block all incoming ports by default. Someone has to go in and explicitly open the traffic before something like Mongo gets exposed; there's no reason that labs, developer machines, etc., would be publicly accessible. Mongo is hardly alone here; comparable services like MySQL, PostgreSQL, and Redis also install without a password by default. For MySQL, this is perhaps less noticeable because Debian/Ubuntu (and probably some other distros) include a prompt to allow the user to set a new root password as a post-install script. For PostgreSQL, the default mode uses IDENT authentication, i.e., it's accessed by dropping to the "postgres" user ... and, like all other system users, including root, this user is passwordless by default. For Redis, it's passwordless by default and I'm sure there are many installations that have this same "vulnerability" in redis-land (there are also many installations that have real vulnerabilities, because Ubuntu's redis-server package in 14.04 hasn't been patched), because people rarely think about redis auth either. Just since last year, there is a feature called "protected mode" that requires the user to explicitly disable a flag if they intend to run a server that is a) bound to a non-loopback interface and b) not passworded (but it doesn't actually require someone to set a password). That's a cool feature, but as users don't RTFM, I'm sure they either flip protected mode to false without understanding what it does or just give up on redis and install MongoDB instead. :) The point here is that pretty much everything you can install on a server is passwordless by default. I don't think the system of someone who never thinks about passwords would last very long at all. This is NOT a MongoDB-specific anomaly. Passwordless is the typical case for most services. A feature like Redis's protected mode is a nice bonus, but it's not fair to lay responsibility for this at the feet of Mongo or to call it a "vulnerability", as the OP does. The responsibility lies with people who say "I'm going to put all of my company's data in here and push it live without thinking even a tiny bit about security." Do a lot of people do that? Yes. Should MongoDB take more steps to protect such people from themselves? Maybe. But this is a very basic, very routine thing, which is easy to look up and rectify -- not some obscure anomaly buried under 600 pages of documentation or requiring a special compile-time flag. Mongo doesn't deserve the heat for people who never set up a password.

z3t4 10y ago
MongoDB has learned the lesson and will no longer listen on public IP by default ... For a while it was common for ISP's to install a router on the customer side, basically creating a firewall because of NAT. But now it's usually up to the customer whether to install a router or not. And most people do not run a dedicated firewall. And with IPv6 rolling out there's really no need to have NAT as there are plenty of IP addresses. With IPv6 it's also possible for one interface to listen to many IP's. You can not assume something will only run on a private network! As a security practice you should assume all networked machines are connected (and accessible) to/from the Internet because 99% of the time they are! Having something listening on a public IP without any password protection is irresponsible whether it's a database or security camera. Last time I installed mySQL I had to both set a root password and specify socket to listen on, and it took five seconds and no documentation reading was needed, so it is possible to both be user friendly and have good security. With mySQL you also have to explicitly set from what IP a user can connect from. Secure should always be the default! Making it not secure should require messing with config files, not the other way around. Most people will just stick to the defaults. There are plenty of examples where you do not need a password, for example opening your fridge or turning on your TV, both being connected to the Internet. Being able to connect to it from your friends place should ring a bell, but I don't think most people try that. Just like people don't regularly port-scan their networks.
- cookiecaper 10y ago
  >MongoDB has learned the lesson and will no longer listen on public IP by default ... For a while it was common for ISP's to install a router on the customer side, basically creating a firewall because of NAT. But now it's usually up to the customer whether to install a router or not. And most people do not run a dedicated firewall. And with IPv6 rolling out there's really no need to have NAT as there are plenty of IP addresses. With IPv6 it's also possible for one interface to listen to many IP's. You can not assume something will only run on a private network! As a security practice you should assume all networked machines are connected (and accessible) to/from the Internet because 99% of the time they are! This is not the case in the United States at all. In fact, it's the opposite. ISPs used to only offer modems that were intended to plug directly into one's computer, which would bridge to the computer's ethernet interface and expose it directly to the internet. Third-party routers would be placed in the middle to allow multiple computers to connect and they almost always include a firewall that has everything blocked by default. Recently, ISPs have been bundling their modems into routers and providing customers with a single device that facilitates multiple computer access, wifi, etc. Every time I've encountered such a thing, it has had a firewall that blocked everything (except maybe a port for remote tech support) by default. This is by far the most common. IPv6, as always, is a pipe dream, but when it becomes real, yes, we will not have the assumption of NAT to fall back on -- though it's pretty safe to assume that consumer-level hardware will continue to block all ports by default. >Last time I installed mySQL I had to both set a root password and specify socket to listen on, and it took five seconds and no documentation reading was needed, so it is possible to both be user friendly and have good security. With mySQL you also have to explicitly set from what IP a user can connect from. This is not a feature of MySQL, but a feature of the distribution you installed it on. It is true that MySQL's configs don't listen on all interfaces by default. IP-based security generally means that every user is wildcarded, and MySQL auto-generates a wildcard root account without a password iirc. >There are plenty of examples where you do not need a password, for example opening your fridge or turning on your TV, both being connected to the Internet. MongoDB is not the equivalent of a fridge or TV. MongoDB is the equivalent of a power saw. If you can't be arsed to take basic precautions while using it, you really shouldn't be anywhere near it. And while many TVs and fridges may have an annoying built-in wifi feature now, most people do _not_ think of these in the same context as server software. :)

z3t4 10y ago

MongoDB has learned the lesson and will no longer listen on public IP by default ... For a while it was common for ISP's to install a router on the customer side, basically creating a firewall because of NAT. But now it's usually up to the customer whether to install a router or not. And most people do not run a dedicated firewall. And with IPv6 rolling out there's really no need to have NAT as there are plenty of IP addresses. With IPv6 it's also possible for one interface to listen to many IP's. You can not assume something will only run on a private network! As a security practice you should assume all networked machines are connected (and accessible) to/from the Internet because 99% of the time they are! Having something listening on a public IP without any password protection is irresponsible whether it's a database or security camera. Last time I installed mySQL I had to both set a root password and specify socket to listen on, and it took five seconds and no documentation reading was needed, so it is possible to both be user friendly and have good security. With mySQL you also have to explicitly set from what IP a user can connect from. Secure should always be the default! Making it not secure should require messing with config files, not the other way around. Most people will just stick to the defaults. There are plenty of examples where you do not need a password, for example opening your fridge or turning on your TV, both being connected to the Internet. Being able to connect to it from your friends place should ring a bell, but I don't think most people try that. Just like people don't regularly port-scan their networks.

cookiecaper 10y ago
>MongoDB has learned the lesson and will no longer listen on public IP by default ... For a while it was common for ISP's to install a router on the customer side, basically creating a firewall because of NAT. But now it's usually up to the customer whether to install a router or not. And most people do not run a dedicated firewall. And with IPv6 rolling out there's really no need to have NAT as there are plenty of IP addresses. With IPv6 it's also possible for one interface to listen to many IP's. You can not assume something will only run on a private network! As a security practice you should assume all networked machines are connected (and accessible) to/from the Internet because 99% of the time they are! This is not the case in the United States at all. In fact, it's the opposite. ISPs used to only offer modems that were intended to plug directly into one's computer, which would bridge to the computer's ethernet interface and expose it directly to the internet. Third-party routers would be placed in the middle to allow multiple computers to connect and they almost always include a firewall that has everything blocked by default. Recently, ISPs have been bundling their modems into routers and providing customers with a single device that facilitates multiple computer access, wifi, etc. Every time I've encountered such a thing, it has had a firewall that blocked everything (except maybe a port for remote tech support) by default. This is by far the most common. IPv6, as always, is a pipe dream, but when it becomes real, yes, we will not have the assumption of NAT to fall back on -- though it's pretty safe to assume that consumer-level hardware will continue to block all ports by default. >Last time I installed mySQL I had to both set a root password and specify socket to listen on, and it took five seconds and no documentation reading was needed, so it is possible to both be user friendly and have good security. With mySQL you also have to explicitly set from what IP a user can connect from. This is not a feature of MySQL, but a feature of the distribution you installed it on. It is true that MySQL's configs don't listen on all interfaces by default. IP-based security generally means that every user is wildcarded, and MySQL auto-generates a wildcard root account without a password iirc. >There are plenty of examples where you do not need a password, for example opening your fridge or turning on your TV, both being connected to the Internet. MongoDB is not the equivalent of a fridge or TV. MongoDB is the equivalent of a power saw. If you can't be arsed to take basic precautions while using it, you really shouldn't be anywhere near it. And while many TVs and fridges may have an annoying built-in wifi feature now, most people do _not_ think of these in the same context as server software. :)