Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The MongoDB hack and the importance of secure defaults

snyk.io

Post reply on HN
Print view View original

121–130 of 223 posts

Re: The MongoDB hack and the importance of secure defaults

#121

Post by achillean »

exogen wrote: post #103
achillean wrote: post #95

The most common MongoDB versions that are being exploited with the ransomware come with secure defaults! https://www.shodan.io/report/kjVzjr3O Originally, I thought the problem would disappear once MongoDB changed the default from "0.0.0.0" to "localhost". However, that has had no impact on the number of exposed MongoDB instances on the Internet. Bad defaults are definitely a problem but in this case that isn't what'…

Just a guess, but those people probably updated their installation with an existing (insecure-by-default) configuration in place. Very little software like this will mess with an existing configuration, so that upgrading doesn't appear to break anything. That's how they'd be on a secure-by-default version but still be insecure.

Yeah, I could definitely see that happening though the overall number of exposed MongoDBs has also increased. And there are Docker images that come w/ insecure defaults ala:

https://hub.docker.com/r/swcc/docker-mongodb/~/dockerfile/

One of my concerns is that people are piling onto MongoDB because "it's web scale" and ignoring potentially systemic security issues that aren't specific to MongoDB. The same issue exists for Riak, Cassandra, Memcache etc.:

https://blog.shodan.io/memory-as-a-service/

Re: The MongoDB hack and the importance of secure defaults

#122

Post by polyfractal »

sneakymichael wrote: post #91
reqres wrote: post #47

Earlier quoted context omitted.

IIRC, there was also a time when Elasticsearch used multicast by default to detect other ES nodes on the network and to add them to the cluster automatically. So any node joining the same network will join a cluster and have shards allocated to it

It seemingly still does; I'm just getting started with Elasticsearch & your description aligns with what I've read in the introduction guide

Just FYI, multicast discovery was moved to a plugin in v2.0 [1], deprecated in v2.2 [2] and removed entirely in v5.0 [3]

- [1] https://www.elastic.co/guide/en/elasticsearch/reference/2.0/...

- [2] https://www.elastic.co/guide/en/elasticsearch/plugins/2.2/di...

- [3] https://www.elastic.co/guide/en/elasticsearch/plugins/5.1/di...

Re: The MongoDB hack and the importance of secure defaults

#123

Post by ajross »

mike-cardwell wrote: post #88

When our sysadmin set up our Mongo cluster, he firewalled out all IPs except our production systems, turned on authentication, set things up to ensure we used SSL, and configured backups. He didn't do this because he's an amazing sysadmin. He did it because he's competent, knows how to put a service on the Internet, and RTFM. I mean. If you can connect to something and use it without having to authenticate yourself,…

That's the same logic that says people who get fired from their jobs should be homeless and starve, or that those who get sick without insurance should be denied care. We don't do that in our society.

There's a moral distinction between culpability and impact. There are profoundly stupid things that people do, yet still need protection from.

Those DB admins were incompetent by lots of measures, but their data still has value and its seizure is a public harm. It's the job of the rest of us (in this case, MongoDB's developers) to take reasonable steps to minimize the chance of that happening.

Secure defaults are a very reasonable precaution. MongoDB fucked up.

Re: The MongoDB hack and the importance of secure defaults

#124

Post by hinkley »

aclsid wrote: post #104
hinkley wrote: post #64

Earlier quoted context omitted.

I still think the XP guys had this figured out. You scale with your customers and stop trying to write it perfect the first time. I'm a huge proponent of never making the same mistake twice but there is just not enough time in the day for perfect. Instead you write it in a way that it has the potential to be great. Customers that have been using your software for a year will have different problems when they have bee…

Sounds a lot like translating a web app after it was released. In a company I was working on, we made a commitment to call out strings without gettext as a bug, regardless if it was really was going to be used for a single country/language. It really takes no effort to do it the first time, but adding that stuff later on is major bs.

Oh, we did that too (and somehow I ended up being in charge of both. Whoopie!) But I decided to cut myself off at two sob stories :)

Security, concurrency, and localization are three things you can't just tack on later. Anyone 'test infected' would add automated testing to that list too. They all involve a long game of whack-a-mole and they're IME bad for morale and productivity.

Re: The MongoDB hack and the importance of secure defaults

#125

Post by LinuxBender »

tetha wrote: post #116
mike-cardwell wrote: post #88

When our sysadmin set up our Mongo cluster, he firewalled out all IPs except our production systems, turned on authentication, set things up to ensure we used SSL, and configured backups. He didn't do this because he's an amazing sysadmin. He did it because he's competent, knows how to put a service on the Internet, and RTFM. I mean. If you can connect to something and use it without having to authenticate yourself,…

Thoughts like this are, and will forever be, the one dividing thing between a more ops-y person versus a more dev-y person. But that's fine. At our place, our mysql cookbook is maturing. This mysql cookbook makes it really easy to say "hey, we need a mysql master with these 2 databases". The only security overhead consist of generating 4 passwords in that case (and we're planning to automate that). Once you've done t…

ops-y + dev-y, isn't that supposed to evolve into DevOps? I know the term is a bit overloaded.

Do the community chef, ansible and puppet cookbooks use secure defaults for MongoDB? Asking because I have never used MongoDB.

Re: The MongoDB hack and the importance of secure defaults

#126

Post by hinkley »

pjc50 wrote: post #119
hinkley wrote: post #55

Earlier quoted context omitted.

In other disciplines they call this pandering. I'll never know why some of us see it as virtue.

Pandering tends to be profitable in other disciplines too.

I know a couple where it's -really- profitable.

But most of us chose not to do that for a living.

Re: The MongoDB hack and the importance of secure defaults

#127

Post by maxlybbert »

overcast wrote: post #40
h4waii wrote: post #20

Earlier quoted context omitted.

This is absolutely the problem. There are high-horse developers who've made 4 webapps using PHP and don't know anything about the system they're deploying on -- but they're rockstars disrupting the world! They leave mysqld bound to 0.0.0.0 because they don't know any better. They SSH as root because they don't know any better. They have a default WordPress install with the config db sitting in webroot. But hey, their…

Everyone can't know everything, be realistic.

It's a requirement for a one-person shop. Or they have to get expert advice.

Re: The MongoDB hack and the importance of secure defaults

#128

Post by overcast »

maxlybbert wrote: post #127
overcast wrote: post #40

Earlier quoted context omitted.

Everyone can't know everything, be realistic.

It's a requirement for a one-person shop. Or they have to get expert advice.

Sure, but everyone is naive at some point. You can't expect one person to make ZERO mistakes. There is a huge amount of steps involved from conception to implementation. I've done many, and still forget things.

Re: The MongoDB hack and the importance of secure defaults

#129

Post by pmlnr »

mike-cardwell wrote: post #88

When our sysadmin set up our Mongo cluster, he firewalled out all IPs except our production systems, turned on authentication, set things up to ensure we used SSL, and configured backups. He didn't do this because he's an amazing sysadmin. He did it because he's competent, knows how to put a service on the Internet, and RTFM. I mean. If you can connect to something and use it without having to authenticate yourself,…

sysadmin - that title is becoming rare. Would you expect the same competancy from a devops, or a site reliability engineer? ( Not trolling, real question; as a sysadmin myself I do see that priorities differ in many cases when a dev or a manager wants to see a service running and you have until yesterday. )

Re: The MongoDB hack and the importance of secure defaults

#130

Post by hinkley »

aclsid wrote: post #104
hinkley wrote: post #64

Earlier quoted context omitted.

I still think the XP guys had this figured out. You scale with your customers and stop trying to write it perfect the first time. I'm a huge proponent of never making the same mistake twice but there is just not enough time in the day for perfect. Instead you write it in a way that it has the potential to be great. Customers that have been using your software for a year will have different problems when they have bee…

Sounds a lot like translating a web app after it was released. In a company I was working on, we made a commitment to call out strings without gettext as a bug, regardless if it was really was going to be used for a single country/language. It really takes no effort to do it the first time, but adding that stuff later on is major bs.

I've found that you can grease the wheels a lot by explaining to management that using the localization features of the language means that stories don't get held up by arguments about terminology. That's been sufficient to get them to agree to localization on three products, two of which almost immediately got surprise customers (or new owners) for our "always english only" application that suddenly wanted it in 3 languages in 3 months. :/

But for now, if I use this technique in the code, and you business guys want to start calling files 'assets', or clients 'customers' (or vice versa), then you guys can go fight it out in a room and just tell me what you want afterward.

Post reply on HN