It's odd not to examine the "contacted a friend at GitHub" part. On the one hand, it's all too common to see this as the only escalation path at a modern tech company. On the other hand, at companies without strong internal controls, it raises the question of how to authenticate yourself to the friend at the company - especially in what the author describes as a stressful 10 minutes.
We know from postmortems that the error-handling code tends to be among the least-tested parts of a codebase, which leads to cascading failure. I wonder if an even wilier attacker could have leveraged the analogous failure here.
> It's odd not to examine the "contacted a friend at GitHub" part.
Authentication aside: what does somebody do to talk to GitHub if you don't have a friend at GitHub that's willing to chat with you? Would Kenneth have been given the Source IP address of the attacker if he didn't know someone there?
I don't see how "contacted a friend" enables an exploit - in this case (and many others I've heard on the 'net) this channel only provides info or verification about the breach, and specifically doesn't provide, and IMHO won't provide, either of (a) any security credentials or (b) resetting any security credentials.
The question isn't about how to authenticate yourself to the friend at the company, the issue is that the friend in the company shouldn't (and shouldn't be able to) perform privilege escalation. They can tell you what has/hasn't been done with your account, but then you have to login or reset password the normal way in any case.
We know from postmortems that the error-handling code tends to be among the least-tested parts of a codebase, which leads to cascading failure. I wonder if an even wilier attacker could have leveraged the analogous failure here.