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

71–80 of 130 posts

Re: MongoHQ Security breach

#71

Post by jumby »

iloveponies wrote: post #43
jumby wrote: post #29

Earlier quoted context omitted.

Granted, but an airgap would make working with some internal support tool a bit cumbersome :) Bastion servers if properly firewalled might be OK for a short term solution. The concern there is if you allow unfettered ssh (for example) is someone watching for the inevitable brute-forcing that will ensue?

Mandatory SSH keys mitigates the brute forcing risk, and turns it into a nuisance. My employer presently has this arrangement and has done so for a while. Bastions only get you in the door: different entrances for different environments, users keys are only propagated to the machines they need.

Roger that. I keep thinking of my customer support people as non-technical and for whom ssh keys, port forwarding & bastion hosts are way over their heads but your point is taken. There are other (cheaper!) ways to secure an internal network.

Re: MongoHQ Security breach

#72

Post by oomkiller »

jumby wrote: post #29
iloveponies wrote: post #22

Earlier quoted context omitted.

2FA and VPNs are not exclusively the only way to secure things. X.509, bastion servers, airgaps that require physical access to a secure facility etc are also valid options, dependent on your systems and their configuration.

Granted, but an airgap would make working with some internal support tool a bit cumbersome :) Bastion servers if properly firewalled might be OK for a short term solution. The concern there is if you allow unfettered ssh (for example) is someone watching for the inevitable brute-forcing that will ensue?

Disable login via password, install fail2ban to help with the extra overhead/traffic.

Re: MongoHQ Security breach

#73

Post by pfg »

benmccann wrote: post #59

Putting support functionality on the VPN means folks from outside the organization can't get to it without VPN access. It also means that you must give more people within your organization access to your VPN which raises the chances of having a compromised account be able to access other valuable assets on the VPN such as your production hardware. How do you make a trade-off between these?

VPN access doesn't have to be all-or-nothing. They could (and should) lock each employees VPN access down as much as possible, i.e. support personnel has access to their support tool and nothing else, etc.

Production hardware should be on a separate network/VLAN/whatever anyway.

Re: MongoHQ Security breach

#74

Post by jumby »

julian37 wrote: post #63
computer wrote: post #46

Earlier quoted context omitted.

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 wo…

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

Re: MongoHQ Security breach

#75

Post by mrkurt »

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…

Joel and Josh have it right, we found the actual breach yesterday. You also have it right, the breach happened before Monday. We're hoping to find reasonably conclusive evidence of a start date we can share with affected customers.

Re: MongoHQ Security breach

#76

Post by DannyBee »

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…

I guess, in a lot of ways, i'm not sure about " and not have to worry about individually securing different internal services."

This is essentially something you need to worry about anyway, for other attack reasons.

Re: MongoHQ Security breach

#78

Post by tptacek »

DannyBee wrote: post #76
tptacek wrote: post #48

Earlier quoted context omitted.

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…

I guess, in a lot of ways, i'm not sure about " and not have to worry about individually securing different internal services." This is essentially something you need to worry about anyway, for other attack reasons.

That's true and a point worth making, but as a practical matter, breaching almost anyone's perimeter is game-over. To not have that be the case, you need to design from the ground up so that internal services don't trust their own deployment network; it's difficult, time consuming, and in many cases confining (ie, it makes some services prohibitively difficult to deploy).

It's for this reason that pentesters learn quickly that the "make an arbitrary HTTP query from the target's own server" bug is usually sev:critical; for instance, in virtually any Fortune 500 network, that pivot gets you (with a little effort and 50 lines of code) to a JMX console somewhere, and from there code execution.

There's no good reason not to do both (ensuring that your internal services are authenticated reasonably and don't expose functionality or information pre-auth, AND setting up a VPN). But the VPN is the most valuable step.

Re: MongoHQ Security breach

#79

Post by jumby »

DannyBee wrote: post #76
tptacek wrote: post #48

Earlier quoted context omitted.

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…

I guess, in a lot of ways, i'm not sure about " and not have to worry about individually securing different internal services." This is essentially something you need to worry about anyway, for other attack reasons.

Yes: from the internal rather than the external threat (bad guy employee).

As tptacek mentions, breaching perimeter security from external is "game-over" in most cases.

Re: MongoHQ Security breach

#80

Post by X-Istence »

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!

So why use their service then? Stand up your own database and use that.
Post reply on HN