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

MongoHQ Security breach

security.mongohq.com

Post reply on HN
Print view View original

121–130 of 130 posts

Re: MongoHQ Security breach

#121

Post by [deleted] »

memset wrote: post #110
theboss wrote: post #49

Earlier quoted context omitted.

You're right that it is a luxury but you are wrong that it is unfair to expect startups to set a higher standard. Startups have fewer assets than big companies. If you can't secure 1 webserver or you have a security breach with only 3 employees, there is something seriously wrong. If you expect to one day have 10,000 servers you better believe I expect you to be able to handle 3 or 5 or 10 by yourself.

How, or where, does one learn how to implement a secure application (say, nginx + uwsgi + python + mongodb)? This is a serious question - the best that I'm aware of are blog posts, but every time someone writes a post about security, HN comments (et al) give contradictory advice.

[deleted]

Re: MongoHQ Security breach

#122

Post by theboss »

memset wrote: post #110
theboss wrote: post #49

Earlier quoted context omitted.

You're right that it is a luxury but you are wrong that it is unfair to expect startups to set a higher standard. Startups have fewer assets than big companies. If you can't secure 1 webserver or you have a security breach with only 3 employees, there is something seriously wrong. If you expect to one day have 10,000 servers you better believe I expect you to be able to handle 3 or 5 or 10 by yourself.

How, or where, does one learn how to implement a secure application (say, nginx + uwsgi + python + mongodb)? This is a serious question - the best that I'm aware of are blog posts, but every time someone writes a post about security, HN comments (et al) give contradictory advice.

things like nginx and apache are quite secure out of the box.

There are three or four main things you need to do for your architecture though.

1) Change default passwords. You might be surprised how often I am able to get in with root toor or root no password. Mysql? Remember to change the root password (because there is none by default)

2) Learn OWASP top 10 and write good code. They have code RIGHT ON THE SITE for how to write a better more secure web-app. There aren't a whole lot of sites out there that make it hard to break their web-app

3)Keep your stuff updated. There was a apache php 0day today. You better believe everyone needs to update their services.

4) Disable extra services you don't need. Telnet, FTP, 53, 445, the list is long depending on what you're running. IF you don't need it, disable it. Don't set a firewall in front of it and call it secure, disable it.

To top it off. 5) 2 factor your ssh (and make sure you're using ssh2 always.) if you don't have a VPN set up. Make it so an attacker needs the key and your password.

If you do this minimal stuff you should be fairly secure.

edit: Securing particular services takes a lot of experience and knowledge about the service. nginx, apache, etc. To do special things to it you need expertise. This is why out of the box, nginx and apache run with low privileges and are fairly secure.

Re: MongoHQ Security breach

#123

Post by mhitza »

Kiro wrote: post #115

I've never understood what people use MongoHQ for. I mean, the data is completely open and it doesn't seem to have any support for authentication.

What do you mean the data is completely open? Do they generate just a tokenized endpoint to which everyone can have access to unauthorized?

Re: MongoHQ Security breach

#124

Post by rsynnott »

sjtgraham wrote: post #95
joelgascoigne wrote: post #42

Hi everyone. Joel here from Buffer. Some of you might have heard about our security breach on Saturday. I just wanted to leave a quick note and clarify that this MongoHQ security breach was the method used to obtain our users' access tokens, which led to the wave of spam on Saturday. This is a key final piece of our investigation which brings it back full circle. I'm very happy that we have been able to gain the full…

It's not cool throw your upstream vendors under the bus.

Huh? This is pretty normal, I think. When a service has downtime because AWS was having a bad day, say, they normally declare that...

Re: MongoHQ Security breach

#125

Post by rsynnott »

flyt wrote: post #3

Especially bad for people that were using MongoHQ to manage their DB backups to S3: As a precaution, we took additional steps on behalf of our customers to invalidate the Amazon Web Services credentials we were storing for you (for the purposes of backups to S3). While this prevents the abuse of your AWS credentials by any malicious party, it may have resulted in additional unintended consequences for your AWS enviro…

While annoying for users who we're using the credentials they provided for other things (which they really shouldn't have been doing anyway, and hopefully MongoHQ makes it clear that they shouldn't) this really seems like about the only thing they could safely do under the circumstances.

Re: MongoHQ Security breach

#126

Post by rsynnott »

jturolla wrote: post #40
leokun wrote: post #20

So I am wondering if any service I'm using is using MongoHQ to store my sensitive information in plain text and was breached. Like, it is a bigger deal than just "change your password" when an attacker can "god mode" into customer databases.

The question remains: Will they disable god mode? I'm truly not comfortable with this feature, I should be able to block total access from my database. I deal with extremely sensitive personal information of thousands of users, and I would never give access to it for support people from a company I hired - Not even MY support team has access to it!

This is the sort of circumstance where you really don't want to be using a hosted databases provider, to be honest....

Re: MongoHQ Security breach

#127

Post by zaroth »

joelgascoigne wrote: post #42

Hi everyone. Joel here from Buffer. Some of you might have heard about our security breach on Saturday. I just wanted to leave a quick note and clarify that this MongoHQ security breach was the method used to obtain our users' access tokens, which led to the wave of spam on Saturday. This is a key final piece of our investigation which brings it back full circle. I'm very happy that we have been able to gain the full…

So you were not storing billing, login, or other such account information in MongoHQ, just the access tokens?

Or were you somehow able to identify which fields from your MongoHQ database were actually accessed by the hacker?

Re: MongoHQ Security breach

#128

Post by jumby »

enko wrote: post #119
jumby wrote: post #74

Earlier quoted context omitted.

"security" is always left for after-the-fact ---- exactly as evidenced by this disclosure and their poor in-house practices.

While I can see your point of view, and the grandparent's, let's be fair. These are startups in a rapidly evolving, highly competitive marketplace and they have limited resources. If they spent months triple checking every dotted i and crossed t they might never even launch, and there'd be no company. Like everything in software it's about tradeoffs. Maybe they erred a little too far on one side of the curve, so let'…

I reject the tradeoff that your internal customer support 'impersonate user' web app would be available via simple password on the open internet.

Re: MongoHQ Security breach

#129

Post by bdcravens »

richadams wrote: post #19
bdcravens wrote: post #2

detected unauthorized access to an internal support application using a password that was shared with a compromised personal account Someone's updating their resume tonight.

Seems a bit harsh to fire someone for that. People make mistakes. If anything, you know that this person isn't going to make the same mistake ever again. Of course, if they do, then firing might be the way to go. First time mistake, second time incompetence.

Perhaps something like this should be in a policy handbook?

"Employees may not use passwords that are used with any service outside of the company."

Zero enforceability (but some companies would probably ask for a list of outside passwords I'm sure), but in the face of a direct policy violation, 100% fireable, and can help a company in terms of liability.

Re: MongoHQ Security breach

#130

Post by tsenkov »

dotmanish wrote: post #118
tsenkov wrote: post #113

Disclaimer: I haven't used MongoHQ. Yesterday, I decided to go with MongoHQ for my current project and this morning I saw they got hacked. Irony aside, couple of months back I decided to check AppFog (PaaS) and the next day they were acquired. :) I believe this is a great time to become a new user of MongoHQ - security has been tightened, experience has been built. The "storm is over" and the chances of a new "storm"…

Can you please choose Microsoft and decide to use Windows? I want to see what happens tomorrow. :)

I can be used as a weapon. :)
Post reply on HN