Live data from Hacker News

The MongoDB hack and the importance of secure defaults

snyk.io

21–30 of 223 posts

Re: The MongoDB hack and the importance of secure defaults

#21
post #7
post #4

I have never used MongoDB so I admit I'm talking blind here, but can someone explain how/why a piece of highly popular software gets to version 2.6 allowing unsecured remote connections by default? Further to that is that type of thinking you want in the development process of something as critical as a database engine? It just seems amazing to me that it got so far before the community in general pushed back that th…

At a guess, it became popular through easy setup. That includes not having to configure login. That's why so many other systems are insecure. Security nearly always increases friction.

IIRC on Debian it is by default not listening externally. So ideally on Ubuntu as well. Though that is Debian / Ubuntu specific, elsewhere they likely ship with default configs. Still no default authentication, but still better than just letting anyone externally connect to it.

Re: The MongoDB hack and the importance of secure defaults

#22
post #16
post #4

I have never used MongoDB so I admit I'm talking blind here, but can someone explain how/why a piece of highly popular software gets to version 2.6 allowing unsecured remote connections by default? Further to that is that type of thinking you want in the development process of something as critical as a database engine? It just seems amazing to me that it got so far before the community in general pushed back that th…

at v2.6 the product was only about 4 years old and underwent a lot of change during that time. (For comparison Postgres version 3 was released in 1991) I think the main guilty parties at mongodb were/are in marketing. technically sophisticated users understood the immaturity of the product and the tradeoffs that came with its architecture. however it was sometimes marketed as a general purpose data store, or as an al…

Even technically sophisticated users should be able to expect secure defaults.

Re: The MongoDB hack and the importance of secure defaults

#24

Earlier quoted context omitted.

I think the problem is developers running apt-get install mongodb and assuming all other considerations, like a firewall, are somehow magically taken care of, then patting themselves on the back for not needing a sysadmin.

I think it's more of a case of assuming that the database wouldn't expose itself to the internet at large, because why would it? It's like buying a new car, and checking for holes in the gas tank before rolling off the lot.

To make this analogy a bit more accurate. With this car instead of filling the gas tank by opening the gas tank door and removing a gas cap you just put the pump into a hole in the side of the car/tank. Then act like you had no idea gas was sloshing out the side hole of this tank.

You didn't do anything special to connect to MongoDB, and are able to connect to it from your other servers. Why would you expect the same wouldn't apply to everyone?

I will say that people who ran MongoDB on their app server get somewhat of a pass on this.I could imagine that they would find the idea of MongoDB running open to the world with no auth to be so nuts that they assumed it was only allowing connections from the local machine.

Re: The MongoDB hack and the importance of secure defaults

#25

Microsoft took a rash of shit some time ago (15 years?) for shipping MS Proxy Server with every port open by default. From the POV of employee-at-the-time, it took them a disappointingly long time for them to not do that anymore. Since then, I've learned to not assume that products are secure-by-default. At the same time, I kind of thought we learned our lesson and cut that shit out low these many years later. Add a…

Do it, or you're hacked? And it's been this way for years? Come on.

It's not though. And it never really has been. A simple approach to security is to only expose the absolute minimum to the internet - you close everything and then open one thing at a time until your service works. Had those 30,000 MongoDB instances been sitting on IP addresses behind routers that only allowed local traffic, or specific IP addresses, then they would have been a lot harder to steal data from. The fact that they were willing to give up data to an unauthorised user would still be a problem, but it'd be a local network problem rather than something anyone with a port scanner could do.

This is not a case of discovering some arcane setting you have to change to make sure your data is secure. This hack was a case of people putting services on open connections without bothering to follow even basic practises. It's bad that MongoDB gave up data without auth details, but your infrastructure can be designed to block an attacker even when they have security details so the fact that MongoDB had this problem is never going to be the whole story.

Re: The MongoDB hack and the importance of secure defaults

#26
post #7

Earlier quoted context omitted.

At a guess, it became popular through easy setup. That includes not having to configure login. That's why so many other systems are insecure. Security nearly always increases friction.

IIRC on Debian it is by default not listening externally. So ideally on Ubuntu as well. Though that is Debian / Ubuntu specific, elsewhere they likely ship with default configs. Still no default authentication, but still better than just letting anyone externally connect to it.

But if a substantial use case requires it to listen remotely, you're just delaying disaster. Listening remotely should have required an authentication setup, or an additional configuration directive like "imbeingatotalidiotandamopeningmydatatuptoanymaluciousactors": true

Re: The MongoDB hack and the importance of secure defaults

#27

I find it interesting that there's no firewall with a default deny rule between these exposed mongodb installs and the Internet. All I can think is that most of them are on cloud services which are directly exposed. It reminds me of the fiasco with all of the directly-connected vulnerable network cameras on the Internet.

I think the problem is developers running apt-get install mongodb and assuming all other considerations, like a firewall, are somehow magically taken care of, then patting themselves on the back for not needing a sysadmin.

On the subject of apt-get, Ubuntu (and most distros) have the firewall disabled by default because out of the box installs have no listening ports. This makes it very easy for the uninformed to have insecure systems. https://wiki.ubuntu.com/SecurityTeam/FAQ#UFW

Re: The MongoDB hack and the importance of secure defaults

#28

Earlier quoted context omitted.

I think the problem is developers running apt-get install mongodb and assuming all other considerations, like a firewall, are somehow magically taken care of, then patting themselves on the back for not needing a sysadmin.

I think it's more of a case of assuming that the database wouldn't expose itself to the internet at large, because why would it? It's like buying a new car, and checking for holes in the gas tank before rolling off the lot.

Your car analogy fails because safety is highly regulated by the government, and the manufacturer can be sued for their failings.

When it comes to server security, you are responsible, and should never make assumptions. If you don't know how, or simply can't be bothered to check, then you shouldn't be administering a server.

Also a firewall is a most basic requirement, even something simple like UFW would do.

Re: The MongoDB hack and the importance of secure defaults

#29

Microsoft took a rash of shit some time ago (15 years?) for shipping MS Proxy Server with every port open by default. From the POV of employee-at-the-time, it took them a disappointingly long time for them to not do that anymore. Since then, I've learned to not assume that products are secure-by-default. At the same time, I kind of thought we learned our lesson and cut that shit out low these many years later. Add a…

Microsoft is a different beast. They ship things based on the principal of least surprise. There are incredible features in newer versions of SQL Server that aren't turned on by default when upgrading, even though no one would want to not have them on.
Post reply on HN