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

41–50 of 60 posts

Re: A deeper dive into our May 2019 security incident

#41

Post by LeifCarrotson »

curiousllama wrote: post #21
NieDzejkob wrote: post #18

Earlier quoted context omitted.

I don't think it's a good idea to make a password reset take 3 entire days. In this case, I'd say the costs outweigh the benefits.

Yea, 10 minutes & a text message would suffice, IMO...

I think the most important part would be to give someone time to vet that it's legitimate. Stack Exchange has on the order of 100 developers, it wouldn't be hard to CC account creation or password reset notices to the manager of a new hire, and in that case, 10 minutes would often be enough to say "Uh, I haven't hired anyone named Curious Llama, who are they and why are they requesting developer access to an obsolete resource?" and put the brakes on.

Re: A deeper dive into our May 2019 security incident

#42

Post by Spooky23 »

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.

I wouldn't say that, but I would say that 2FA is insufficient. MFA, where the "M" includes some non-zero level of trust in the devices used for user and application runtime becomes essential.

"2FA", as commonly implemented in many scenarios is weak and only helps address certain scenarios -- TOTP tokens, for example, are pretty trivial to compromise. Critical infrastructure needs hardened tokens and clients with more controls.

Re: A deeper dive into our May 2019 security incident

#43

Post by Robelius »

As someone who doesn't work much with software teams, can someone fill in my gaps for understanding timeline.

I'm imagining after a security issue is identified, the steps taken are roughly in the below order and close-ish for the date. I guess my question is, why does it take 20 months from start to blog post?

-Contain the issue (1wk) -Remove the threat (1wk) -Build up remedies (a few months) -Check and recheck what happened to make sure you're accurate when submitting final reports (a few months) -Release a blog post (1month)

The timeline is a cool day by day instance, but I just don't understand the larger timeline.

Re: A deeper dive into our May 2019 security incident

#44

Post by tclancy »

Robelius wrote: post #43

As someone who doesn't work much with software teams, can someone fill in my gaps for understanding timeline. I'm imagining after a security issue is identified, the steps taken are roughly in the below order and close-ish for the date. I guess my question is, why does it take 20 months from start to blog post? -Contain the issue (1wk) -Remove the threat (1wk) -Build up remedies (a few months) -Check and recheck what…

I assume it's related directly to "It’s been quite some time since our last update but, after consultation with law enforcement, we’re now in a position to give more detail".

Re: A deeper dive into our May 2019 security incident

#47

Post by kmontrose »

tclancy wrote: post #44
Robelius wrote: post #43

As someone who doesn't work much with software teams, can someone fill in my gaps for understanding timeline. I'm imagining after a security issue is identified, the steps taken are roughly in the below order and close-ish for the date. I guess my question is, why does it take 20 months from start to blog post? -Contain the issue (1wk) -Remove the threat (1wk) -Build up remedies (a few months) -Check and recheck what…

I assume it's related directly to "It’s been quite some time since our last update but, after consultation with law enforcement, we’re now in a position to give more detail".

It's this.

Discovery, immediate mitigation, deeper mitigation, general notice, notifying effected users - all these can happen pretty quickly once the ball is rolling. Once you're dealing with "the law" in any capacity you are constrained in what you details you can share broadly, and when.

I'm happy we were finally able to share this level of detail.

Re: A deeper dive into our May 2019 security incident

#48

Post by TrickyRick »

Eduard wrote: post #34

> Fortunately, we have a database containing a log of all traffic to our publicly accessible properties https://stackoverflow.com/legal/privacy-policy GDPR anyone?

> When you visit the Network or use our Apps, Stack Overflow automatically receives and records information from your browser or mobile device, such as your Internet Protocol (IP) address or unique device identifier. Cookies and data about which pages you visit on our Network allow us to operate and optimize the Products and Services we provide to you. This information is stored in secure logs and is collected automatically.

Clear as day that they're doing exactly that. You agree to this when you use the site.

Re: A deeper dive into our May 2019 security incident

#49

Post by brazzy »

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.

Yeah, I'm pretty sure the reason why the article keeps repeating that is not a desire to provide the most detailed information about the breach...

Re: A deeper dive into our May 2019 security incident

#50

Post by akersten »

deanward81 wrote: post #32
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…

Thanks, yeah I missed that on account of misunderstanding the nature of the access (bug vs token shenanigans)
Post reply on HN