Live data from Hacker News

The MongoDB hack and the importance of secure defaults

snyk.io

1–10 of 223 posts

Re: The MongoDB hack and the importance of secure defaults

#2
I'll say this is even worse because whether or not to bind to localhost, all interfaces, or something in between is often highly dependent on how the software works - which you're less likely to know when just trying it for the first time. Even someone security conscious would have to pause and do some investigations to find out what mongo expected in terms of port and interface bindings. If the default was to bind to 0.0.0.0 my first assumption would be they require that.

Re: The MongoDB hack and the importance of secure defaults

#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 this was really bad design? Hopefully someone with MongoDB history can explain if this was a long term sticking point, etc. Thanks.

Re: The MongoDB hack and the importance of secure defaults

#5
MongoDB was hardly alone -- almost all of these projects favored getting people started quickly, and avoiding anything that slowed them for even a moment. And we've seen it in project after project that it absolutely helps uptake, and if your project requires an hour of analysis and configuration before being usable, even if this saves tens of thousands of hours in the future, it puts it at a dramatic disadvantage.

https://dennisforbes.ca/index.php/2012/10/02/trouble-with-se...

I realize this post is dead (I disagreed with dang once), and that's okay. This is for the edification for those who can see ghosts.

Re: The MongoDB hack and the importance of secure defaults

#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.

Re: The MongoDB hack and the importance of secure defaults

#8
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…

In production deployments, unsecured remote connections might be fine, because security would be handled at the network layer (e.g. by deploying MongoDB on a VLAN which only was accessible by your MongoDB clients which were on separate servers).

Re: The MongoDB hack and the importance of secure defaults

#9
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.

Re: The MongoDB hack and the importance of secure defaults

#10
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 line to a text config file that's probably buried eight directories down in a hierarchy that's owned by root? (I'm just hyperbolically guessing for effect; I generally avoid Mongo.) Do it, or you're hacked? And it's been this way for years? Come on.

Post reply on HN