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

A deeper dive into our May 2019 security incident

stackoverflow.blog

Post reply on HN
Print view View original

31–40 of 60 posts

Re: A deeper dive into our May 2019 security incident

#31

Post by vntok »

akersten wrote: post #27

Interesting that most of the mitigations are "move resource behind firewall." Kind of an indictment of the whole BeyondCorp idea - unless we really trust our 2FA to never have any access bypass issues like the initial access to the dev environment here. Speaking of that, I didn't see "fix bug allowing unauthenticated access to dev environment" listed as one of the mitigations, but maybe I glossed over it.

> Hardening code paths that allow access into our dev tier. We cannot take our dev tier off of the internet because we have to be able to test integrations with third-party systems that send inbound webhooks, etc. Instead, we made sure that access can only be gained with access keys obtained by employees and that features such as impersonation only allow de-escalation—i.e. it only allows lower or equal privilege users to the currently authenticated user. We also removed functionality that allowed viewing emails, in particular account recovery emails.

Re: A deeper dive into our May 2019 security incident

#32

Post by deanward81 »

akersten wrote: post #27

Interesting that most of the mitigations are "move resource behind firewall." Kind of an indictment of the whole BeyondCorp idea - unless we really trust our 2FA to never have any access bypass issues like the initial access to the dev environment here. Speaking of that, I didn't see "fix bug allowing unauthenticated access to dev environment" listed as one of the mitigations, but maybe I glossed over it.

It's in the remediations section, but maybe the wording isn't clear:

*> Hardening code paths that allow access into our dev tier. We cannot take our dev tier off of the internet because we have to be able to test integrations with third-party systems that send inbound webhooks, etc. Instead, we made sure that access can only be gained with access keys obtained by employees and that features such as impersonation only allow de-escalation—i.e. it only allows lower or equal privilege users to the currently authenticated user. We also removed functionality that allowed viewing emails, in particular account recovery emails.*

There was no "unauthenticated" access into dev - the access key here is what allows login at all to our dev environment, but the attacker was able to bypass that protection.

Re: A deeper dive into our May 2019 security incident

#33

Post by cbg0 »

> Our dev tier was configured to allow impersonation of all users for testing purposes, and the attacker eventually finds a URL that allows them to elevate their privilege level to that of a Community Manager (CM)

> After attempting to access some URLs, to which this level of access does not allow, they use account recovery to attempt to recover access to a developer’s account (a higher privilege level again) but are unable to intercept the email that was sent. However, there is a route on dev that can show email content to CMs and they use this to obtain the magic link used to reset credentials.

Many of these debugging tools are great for devs to test things quickly but I've always felt very weary of having these exist in an app without some strict access control with 2FA. Ideally you'd not have them in the app at all, maybe just on local dev.

Re: A deeper dive into our May 2019 security incident

#35

Post by pc86 »

TacticalCoder wrote: post #13

> However, there is a route on dev that can show email content to CMs and they use this to obtain the magic link used to reset credentials So many sites do this: allowing major changes to be effective immediately (like resetting credentials/password) by simply opening a "magic link" sent by email. I think that this "immediately" is a major security antipattern. I prefer it when such changes have a "cooldown" period o…

The next time you forget a password and need to reset it, how likely are you to be willing to wait three days?

Re: A deeper dive into our May 2019 security incident

#36

Post by fredley »

CountHackulus wrote: post #2

I found it interesting that the attacker looked for help on the attackee's own site. I guess it truly proves how good of a repository of information StackOverflow is.

Although the article was written in an extremely straightforward and dry technical manner, this was comedy gold.

Re: A deeper dive into our May 2019 security incident

#37

Post by dividuum »

120bits wrote: post #28

Thank you SO for being open and listing the best practices. It seems like even few security best practices makes it harder for hackers to get in to your system. I have database connecting strings and password as ENV variables. But I still don't know what is the best practice. Lets say someone gets access to the server, they can still read the ENV vars, right? It definitely prevents from accidently checking in your co…

> Lets say someone gets access to the server, they can still read the ENV vars, right?

Correct. Easiest way is to look at `/proc/$pid/environ`. It contains the \0 separated values for that process.

Re: A deeper dive into our May 2019 security incident

#40

Post by spelunker »

TacticalCoder wrote: post #13

> However, there is a route on dev that can show email content to CMs and they use this to obtain the magic link used to reset credentials So many sites do this: allowing major changes to be effective immediately (like resetting credentials/password) by simply opening a "magic link" sent by email. I think that this "immediately" is a major security antipattern. I prefer it when such changes have a "cooldown" period o…

I think the problem is showing the "magic link" anywhere other than in the email for the intended recipient, since it's effectively a password.

As others have mentioned though, if you as a user know someone has access to said password and you're resetting it as an emergency, that's 3 more days of some hacker being able to log in with your password!

Post reply on HN