Live data from Hacker News

Uber investigating breach of its computer systems

nytimes.com

271–280 of 327 posts

Re: Uber investigating breach of its computer systems

#271
post #98

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

There’s a trend of storing MFAs in password managers like 1Password. If the password manager is compromised then what was the point in having MFA…

The point is to have the same amount of security of a strong password, with the same amount of hassle as a strong password.

Not every little SaaS needs MFA.

Re: Uber investigating breach of its computer systems

#272

I think it's worth repeating: at this point, MFA that is not based on Webauthn ( https://webauthn.guide/#about-webauthn ) should be considered dangerously insecure. Uber almost certainly enforces MFA for remote access; I strongly suspect we'll end up hearing that it was successfully provided during the authentication step (update: screenshots on Twitter appear to confirm this). As we saw in the case of the 0ktapus ca…

No post body was provided.

Re: Uber investigating breach of its computer systems

#273
post #147

Former Uber employee. I'm not a fan of the company. But don't shit on the efforts of the security team please. They were actually quite thorough. We used online MFA (you had to respond to MFA requests on your phone). Not even sure why this is a discussion as the hacker confirmed it was a case of social engineering. No MFA protects against social engineering (no, not even ____ - don't try to convince me). And yes, at…

[deleted]

Re: Uber investigating breach of its computer systems

#274
post #147

Former Uber employee. I'm not a fan of the company. But don't shit on the efforts of the security team please. They were actually quite thorough. We used online MFA (you had to respond to MFA requests on your phone). Not even sure why this is a discussion as the hacker confirmed it was a case of social engineering. No MFA protects against social engineering (no, not even ____ - don't try to convince me). And yes, at…

Oh, cloud-based MFA. Dream stuff where you SaaS can reauthenticate at any time, and it just sends a request to the users, without having to rely on them to initiate anything. No idea what could go wrong with that. /s

Re: Uber investigating breach of its computer systems

#275
The common thread in all of these recent attacks (Uber, Twilio, Okta, etc) is the “phishability” of the authentication methods involved. Remote attacks like this only work when you can socially engineer an employee and phish sensitive credentials like a password from them (or a SMS one-time passcode during the MFA step).

What’s head-scratching to me is why tech-forward enterprises haven’t been faster to adopt unphishable forms of authentication like WebAuthn. WebAuthn supports both built-in device biometrics like FaceID/TouchID and external hardware keys (eg YubiKey), which are inherently incapable of being phished — there’s no text-based secret for an attacker to deceive a user into sharing with them.

I’m biased as I run an identity and access management company (stytch.com), but I hope more companies will consider integrating WebAuthn to support unphishable MFA.

Today, WebAuthn introduces some nuances that can discourage a B2C company from supporting it today (e.g. account recovery with lost devices), but it’s a clear win for corporate network/workplace authentication and B2B apps. I believe some of the lack of adoption is due to complexity to build (more complex than traditional MFA) and cost for off-the-shelf solutions (Incumbents like Auth0/Okta require ~$30k annual commitments to let developers use WebAuthn). If you decide to build with Stytch, WebAuthn is included in our pay-as-you-go plan (https://stytch.com/products/webauthn)

Re: Uber investigating breach of its computer systems

#276

I think it's worth repeating: at this point, MFA that is not based on Webauthn ( https://webauthn.guide/#about-webauthn ) should be considered dangerously insecure. Uber almost certainly enforces MFA for remote access; I strongly suspect we'll end up hearing that it was successfully provided during the authentication step (update: screenshots on Twitter appear to confirm this). As we saw in the case of the 0ktapus ca…

100%. The common thread in all of these recent attacks (Uber, Twilio, Okta, etc) is the “phishability” of the authentication methods involved -- as you mention, the unphishability of WebAuthn is what makes it particularly compelling.

What’s head-scratching to me is why tech-forward enterprises haven’t been faster to adopt unphishable forms of authentication like WebAuthn. I’m biased as I run an identity and access management company (stytch.com), but I hope more companies will consider integrating WebAuthn to support unphishable MFA.

Today, WebAuthn introduces some nuances that can discourage a B2C company from supporting it today (e.g. account recovery with lost devices), but it’s a clear win for corporate network/workplace authentication and B2B apps. I believe some of the lack of adoption is due to complexity to build (more complex than traditional MFA) and cost for off-the-shelf solutions (Incumbents like Auth0/Okta require ~$30k annual commitments to let developers use WebAuthn). If developers decide to build with Stytch, WebAuthn is included in our pay-as-you-go plan and can be integrated in an afternoon(https://stytch.com/products/webauthn)

Re: Uber investigating breach of its computer systems

#277
post #122

Earlier quoted context omitted.

So that you're protected from data breaches of the service itself (e.g. revealing a reused password)

That doesn't have anything to do with MFA. If for some reason your 1Password masterpass is compromised, the hacker has access to your passwords and your MFA tokens. If you use 1Password and say Authy (Assuming your Authy pass isn't in 1Password) or Google Authenticator. Then all services with MFA wont be compromised if the 1Password masterpass is...

Hi there!

Not quite. An attacker would need either your account password AND an already authorized device, OR they would need both your account password AND Secret Key. If you have 2FA enabled for your 1Password account, and the attacker doesn't have one of your authorized devices, they would also need your second factor (TOTP or hardware key).

Additionally our Principal Security Architect, Jeff Goldberg, wrote some thoughts on this subject, here: https://blog.1password.com/totp-for-1password-users/

- Ben, 1Password

Re: Uber investigating breach of its computer systems

#278
post #177

Earlier quoted context omitted.

No – the problem here is really the reverse: they limit the number of devices which can gate access to your account, on the theory that you'll handle a breach by contacting them. That's theoretically more secure but slower. (Non-root MFA can be reset by another admin or root so this is most of a concern for the root account)

> That's theoretically more secure I fail to see how that can be true. How will they validate that it is you on the phone?

If you haven't dealt with this before, it's not calling support and social-engineering someone into hitting the reset button. The last time I knew someone who had to reset an AWS root account password (broken Yubikey), it required multiple phone calls AWS initiated to the billing & technical contacts (which can only be set by root so an attacker can't easily change them) to confirm intention and then they had to sign a form in front of a notary who checked photo ID.

I classed that as more secure since you can't do it remotely and the in-person portion further increases the difficulty.

Re: Uber investigating breach of its computer systems

#279

The other thing of note with this is timing as yesterday an ex attorney testified against the ex security chief for the 2016 breach cover up. And the next day there is this breach. So based on the damaging nature of the testimony where further discovery could be needed it seems a bit too convenient to have a breach the next day. So is it possible this is a fake breach in order to scrub further damaging evidence of ot…

> So is it possible this is a fake breach in order to scrub further damaging evidence of others involved in the original 2016 cover up? Can you elaborate what scrub means in this context? In what ways would this breach cover up the 2016 breach? Would the prosecutors suddenly lose their memory of the 2016 breach? Would evidence suddenly go missing?

By locking out your company and chat mediums you can search and purge evidence or artifacts in hopes to not expose further corruption or others involved in the past one. While treating it as a real threat to feds and public. In the org cover up they hired the attackers as employees with modified NDAs as per the testimony given on the 14th. So with that info I wouldn't put it past them as will as the ftc passing gig worker protections which would also financially impact uber on top of the lawsuits that will come out of the 2016 breach cover up. So with those factors and their history this could be used as a cost savings measure in a way to limit the money they are going to pay out in both areas. So with the testimony it would in theory open discovery for new evidence which this could prevent if used as a clean up job for lack of a better term.

Re: Uber investigating breach of its computer systems

#280
post #246
post #162

Earlier quoted context omitted.

The powershell script is a minor part of the screw up. The real issues are multitude... 1) hardcoding actual production credentials in a script at all. Seriously what the fuck. 2) Thycotic not enforcing MFA for the keys to the kingdom admin account. Even my cellphone provider has better security. The root cause is likely the assumption that the VPN is sacred. This needs to die asap - your internal network should assu…

So, on that, it is surprisingly difficult to get rid of hard coded credentials and funnily vendors like tychotic and hashicorp are supposed to prevent that by having some api thing that integrates with scripts. That said, tychotic,cyberark and pals that manage credentials almost always need domain admin. I think just moving to full AAD and azure key vault might be better but realistically this is the nature of the be…

the cute answer to all this is always: how do people think your service accesses the secret vault? its anlther credential.

the real issues are tougher, like why does this one cred have access to all these other creds, and how or if they were auditing usage of that cred from authorized client devices.. but all of these problems take a lot of effort and care to solve. and as history has shown, you only have to mess up once.

Post reply on HN