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

61–70 of 130 posts

Re: MongoHQ Security breach

#61

Post by theboss »

nfoz wrote: post #45
theboss wrote: post #13

One thing I hate seeing is startups and security. Not that mongo is bad or anything this is just a good time to say it. Build your product correctly from the start and have a security policy early. Don't leave XSS in your website, don't just hack code together and throw it on a server. As a security guy I love seeing new startups products because so often the code is so freshly written and immature that anyone it's a…

Capitalism often presents a choice between aggressively building unsafe products, or losing out to the competition. It's extremely hard to win in a fast market by being stable, secure, and correct, at least when it comes to software.

Capitalism will also say that I'm most likely to succeed if I can do all three.

Re: MongoHQ Security breach

#62

Post by joelgascoigne »

WestCoastJustin wrote: post #52
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…

Just trying to develop a timeline here. Buffer security breach - October 26, 2013 [1] MongoHQ security breach - October 28, 2013 [2] But the Buffer security breach was via MongoHQ, so MongoHQ has likely had the issue since at least the 26th, and probably earlier, since the attackers had to have enough situational awareness to target Buffer. I guess my point is, MongoHQ likely had the issue for a while and it went und…

Hi Justin. To clarify, from what I understand, October 28 is the date MongoHQ detected this. They've provided us with the logs of database access, and unfortunately the queries leading to our spam attack on Saturday started as early as October 19.

I can understand that MongoHQ wanted to obtain the full picture here and not put other customers at risk by exposing this information before the situation was fully locked down.

Re: MongoHQ Security breach

#63

Post by julian37 »

computer wrote: post #46
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…

Have you considered not outsourcing critical parts of your company to startups that are iterating fast and potentially breaking things? Could you share the reasoning behind Buffer choosing to store their customers' private data with MongoHQ, instead of your own secure infrastructure?

This is the elephant in the room and I'm surprised it hasn't been mentioned by any of the other comments.

When it comes to infrastructure as a service, it appears to me that there is an imbalance between the sensitivity of information entrusted to external systems on one hand, and the standards such systems are held up to on the other.

EDIT: case in point, on http://mongohq.com I can't find a single mention of the word "security". The language is all about ease of use, performance, scalability, disaster recovery, and low cost, but as far as I can tell not a single word is spent on what procedures are in place to safeguard your data from unwanted access.

EDIT: removed inflammatory comment.

Re: MongoHQ Security breach

#65

Post by WestCoastJustin »

joevandyk wrote: post #57

Anyone got any advice on setting up a VPN and 2 factor authentication? We use Ubuntu, AWS, and Rails.

I would configure your AWS instances inside a AWS VPC and then host the VPN endpoint inside the VPC. Then you can open up the VPN as needed via security groups. This gives you a secure channel directly to your instances -- something like this:

                  +------------------+
                  | AWS              |
                  |  +-----------+   |
                  |  | VPC       |   |
   +------+       |  | +-----+   |   |
   | You  | +----------->VPN |   |   |
   +------+       |  | +-----+   |   |
                  |  +-----------+   |
                  |                  |
                  +------------------+
AWS also provides a multi-factor authentication mechanism @ http://aws.amazon.com/mfa/

Re: MongoHQ Security breach

#66

Post by muns »

joshchaney wrote: post #38
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…

I was one of those people bitten by this last night. My client called and told me he was getting access denied when trying to upload files through his CMS. After some digging I found the S3 key had been revoked. This was concerning, as I hadn't touched the CMS code I wrote in like 3 years and I've had issues deploying old stuff to Heroku in the past. I really wish MongoHQ had contacted me first about revoking the key…

Best practice would be to create an IAM user for each purpose rather than sharing the same AWS key across all of your apps, for this exact reason

Re: MongoHQ Security breach

#67

Post by reidrac »

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!

I think in those cases you may not be legally allowed to use a 3rd party managed service to handle the data, although it probably depends on the country where your company is operating.

Also that "god mode" only makes things easier, if you're hiring a managed service by definition it means someone must have access to manage the service.

The answer is: manage it yourself effectively locking access to any 3rd party.

Re: MongoHQ Security breach

#68

Post by camus2 »

aroman wrote: post #21

As much as the actual cause of the concern (apparently serious employee error) was preventable, I was still impressed by their detailed disclosure, the steps that have been taken to mitigate it, and actual details about what was compromised other than the generic "non-credit card personal data". I don't use MongoHQ for any projects right now (I evaluated their offering a year or so ago and opted to go with MongoLab,…

I guess You meant "using" not "suing".

Re: MongoHQ Security breach

#69

Post by jumby »

tptacek wrote: post #48
DannyBee wrote: post #44

Earlier quoted context omitted.

Can you explain why this is better than allowing access using 2FA over HTTPS (with a non-crappy set of cipher choices)? IE What does the VPN buy you, specifically, on the employee side? (I understand entirely what it buys you on the other side of the equation, such as a smaller attack surface, i'm just trying to understand why you would think having a VPN would have made this particular case more secure)

The value of a VPN over individually-secured HTTPS/TLS+2FA connections is that you can configure the VPN once, use very standard networking tools to continuously ensure that your internal services are only available over the VPN, and not have to worry about individually securing different internal services. Another benefit is that as your internal userbase changes, you can revoke access from a single point and be rea…

Right, I think having a non-split tunneling VPN forces employees remote computers onto the "corporate" network where they are governed by the rules of that network and establishing rules for access to internal resources is done centrally.

I just wouldn't trust having something critical like "impersonate user" on the open internet - even if secured by https + 2fa.

Re: MongoHQ Security breach

#70

Post by aferreira »

While I commend the team at MongoHQ for detailing the attack, the strategy used to restrict any further damage and implementing new processes and additional security, I've heard this story one too many times.

When are companies going to realize that security is a critical aspect of their business? Why are people only acting when there's some big security breach, using trivial systems before this?

Post reply on HN