Uber investigating breach of its computer systems

Regarding AWS, it's truly insane that they only support 1 device (breaking from the FIDO2 recommendation) but you can also put AWS behind SSO, and then have 2FA on the SSO.

Explain why what is false? You're just making vague claims about anecdotal experiences. It seems unlikely, in general, that a security team would not support a Yubikey rollout. Even one that only cares about compliance would likely support it because it will make compliance easier - auditors care a lot about phishing and if you can say "OK, yeah, we had some users fail the phishing test again BUT our 2FA is phish-proof" that's an easier conversation.

I'm sure there are truly lazy and incompetent security teams out there but it makes no sense that they would be the majority or even particularly prevalent. Maybe you're just unlucky and ran into one, or maybe there were real reasons why a Yubikey rollout wouldn't work;

a) Who's going to ship the keys? Yubico provides services for that, will you use those? Pay for them?

b) Who's paying for this? Did your infra team ask the security team to pay for it? Who's paying for replacements and support?

c) Is this a high priority for the team vs other issues?

d) Do all of your vendors support Yubikeys or are you going to have to have a hybrid solution? What will migration from vendors configured for some other FMA solution to Yubikeys look like?

I support a rollout at any company, for the record, but these vague statements with the conclusion of "security people don't care" leave a lot to be desired.

I sure hope WebAuthn is easier to implement than that site is making it look like. I know nothing about how it works, but the sample code (Under "Example: Parsing the authenticator data") that requires parsing slices of bytes out of the response and then constructing some object with magic numbers looks really hacky. Maybe it is supposed to be exposed at a low level like that so wrappers can be made around it, but if there is any hope of migrating sites over to it, it's going to need to be dead simple to implement without screwing up.

Why are people talking about MFA on this thread. Look, as someone whose day job is responding to such incidents, someone targeting Uber and is persistent will get in, MFA or not. Infostealers for Mac are a thing (Uber is a mac heavy shop I hear) and that's all it takes to steal cookies and tokens post-mfa, or why even bother with that, if you're running code just make it a reverse shell.

The big screw up here is powershell script on a network share. A cheap pentest would have uncovered something like that.

Modern security is not perimeter focused where you try to keep the bad guys out. Yes, you should do MFA,firewalls,vpns the whole schtick but(!!) your presumption should always be that threat actors already have a foot-hold in your network. This is very important because it helps you focus on basic things like scripts and gpos with creds in them but also you treat internal devices the same as internet exposed devices. It's sort of what the whole "zero trust" thing is about as well. In other words, host/user compromise is a given but lateral movement should be at least as difficult as breaching the perimeter.

But my prediction is, just like top commenters here, they will slap MFA on it and of course cleanup scripts with creds and call it fixed until the next compromise. Oh and FYI, MFA on VPNs is a PITA, that's rarely done for good reason, instead you use device certificates in addition to passwords which is what the recommendation should be not yubikeys or webauthn (vpn!=web??) because VPNs need to reconnect and you can't have people insert a yubi each time their connection drops. Ideal setup would have 7 day valid (or however long is reasonable for users to disconnect their PC and remain out of office) mutual-auth certs+ocsp getting conditionally reissued new certs to remain connected (compliance stuff like patching, unapporoved software,security alerts for the device). If you think about it, you typically issue users two yubikeys not just one so if the backup gets stolen you have a problem depending on how easy it is to social engineer users or reset their password with a good yubikey but a stolen laptop means certs+password revoked immediately.

Yes, you're correct. They don't. And it's pervasive - it's not just Uber, it's the developers of the software Uber writes. Shake out the tree of any Uber service and you'll find that maybe 0.1% of the code is written by someone who cares about security, and maybe 10% of that code was written by someone who knows about security.

Developers do not give a shit. Security is not something they're trained in, interested in, or competent in (though they often think they are).

Security is a couple of people trying to bucket out the water as fast as they can from every sinking ship while developers are taking a piss on the floor and poking holes in the hull.

I think the bar for devs is extraordinarily low and we'll keep seeing this sort of thing until it we collectively raise it. Thankfully it seems like, very recently, this is starting to maybe happen. Packages requiring 2FA is the first thing I've seen that seems to indicate that developers are going to have to do the bare minimum for security in order to participate.