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

Uber investigating breach of its computer systems

nytimes.com

Post reply on HN
Print view View original

281–290 of 327 posts

Re: Uber investigating breach of its computer systems

#281

Post by traceroute66 »

happyopossum wrote: post #212
traceroute66 wrote: post #196

Earlier quoted context omitted.

> Will a million dollar sales call fail and/or have to be rescheduled because you didn't have 2FA access? You should accept the responsibility, apologise with whoever it is that you let down and move on. Spoken as someone who has clearly never had any tech duties in the financial sector. You don't understand what time critical means until a dealer's access stops working / computer freezes 10 minutes before market clo…

The answer there, clearly, is to not have an individual be a potential SPOF. If failure of that kind of support costs millions of dollars, you absolutely need to have the ‘walked in front of a bus’ scenarios worked out.

> The answer there, clearly, is to not have an individual be a potential SPOF. If failure of that kind of support costs millions of dollars, you absolutely need to have the ‘walked in front of a bus’ scenarios worked out.

I'm not going to post details in public, but suffice to say, you are over-simplistic and don't understand the context.

Sticking with my example of dealers, let's just say people like dealers are not employed in great numbers in all but the largest financial organisation. Let's also say that there are certain events and certain times of day when the entire dealing desk is, shall we say, "busy and stressed out". There is little scope for a colleague to step in at those times, because everyone is franticly busy on the phones with their own workload.

In terms of 2FA therefore, the "walked infront of a bus" scenario is to (after correct security protocol, which includes, but not limited to, senior board-level management and compliance being told and approving) temporarily bypass 2FA for that dealer. Telling the dealer to pass his work to a colleague is just not going to work.

Of course financial organisations have "walked infront of a bus" plans. But they equally have levels of escalation of plans. Sometimes doing stuff at lower level with the help of the IT department is more than sufficient.

I'm not going to elaborate further.

Re: Uber investigating breach of its computer systems

#282

Post by trollied »

mcstempel wrote: post #276
sullivanmatt wrote: post #7

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

I’ve not read up about webauthn yet. How does it work & what makes it unphishable?

Re: Uber investigating breach of its computer systems

#283

Post by WirelessGigabit »

Our security just send around an email that they're disabling Google Chrome's password manager.

While I understand not wanting those passwords in Google's hands, the reality is that they do have the $$$ for security.

But instead of being able to leverage that functionality, and the Generate Password functionality we now have to resort back to name_of_application_my_name or something like that.

Do not ban things just because it has an issue. Provide a better alternative.

Re: Uber investigating breach of its computer systems

#284

Post by staticassertion »

raesene9 wrote: post #136
staticassertion wrote: post #95

Earlier quoted context omitted.

People who call ZTN a meme are usually just ignorant. It's a very simple and effective solution. Mutual authentication, explicit authorization, attestation, and auditing. Not exactly buzz word soup.

It shouldn't be buzzword soup, that does not mean that companies and vendors don't use it that way. Pretty much any time a new security concept comes up vendors race to say that they implement it, whether they do or not. With Zero trust, it's hardly a new idea (e.g the Jericho forum de-perimeterization) but it's hard to implement well across all systems.

If you're stupid enough to fall for vendor buzzword garbage that's kind of on you though, right? It says nothing about ZTN.

Re: Uber investigating breach of its computer systems

#285

Post by jjav »

Semaphor wrote: post #211
protomyth wrote: post #202

Earlier quoted context omitted.

Any 2FA is better than no 2FA That's simply false because of the poor customer service of the providers and fates of many phones.

How is that false? Name a single example where SMS 2FA is worse than none. And just because it will always come up: 2FA, not treating the second factor as only factor.

> Name a single example where SMS 2FA is worse than none.

SMS is terrible because it is so easy to lose account access.

Phone broken/stolen? Completely locked out.

Or, I have this one financial institution that insists on sending SMS 2FA to the phone number on file, which is a 20+ year old landline which obviously can't receive SMS. Completely locked out. Someday I'll have to find out some way to get my money out of there (they have no local branches).

I will always use TOTP if at all possible, because it's not a single point of failure. I store the seed values securely and they are backed up, so can't be lost.

Re: Uber investigating breach of its computer systems

#286

Post by breser »

acdha wrote: post #278
marcosdumay wrote: post #265

Earlier quoted context omitted.

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

You do not have to even talk to AWS to remove the MFA from the root account. You simply need access to the phone number on the account (though there are ways around the phone number, see below) and the email address for the root account.

It's been a little over a year since I've done it but as I recall this is how it goes. You receive an email with a link that takes you to a site that starts a verification process via the phone. You get a number from the site that you are prompted to enter when they call you on the phone. Once that's done you can log into the account with the MFA device and then even remove the MFA device entirely.

The email address I believe can only be changed by AWS (and at least the last time this was an issue for me can't ever be reused for a new AWS account).

The phone number can be changed by anyone with aws-portal:ModifyAccount, which probably means someone with admin access. It is NOT restricted to being modified by the root account.

So if you have a working access to an account with that permission and access to the email you can change the phone number to one you have access to and go through the whole process. Meaning if you have the above permission you really only need access to the email.

Link to the documentation for this flow: https://aws.amazon.com/blogs/security/reset-your-aws-root-ac...

Re: Uber investigating breach of its computer systems

#287

Post by mrsalt »

zmgsabst wrote: post #54
bombcar wrote: post #24

Earlier quoted context omitted.

In the old days you’d have physical restrictions on access to the datacenter - in a major breach you’d get there physically and shut it down and disconnect it. With everything cloud now, how do you recover your cloud account of the master got compromised?

For someone Uber’s size, you call your AWS rep and co-ordinate with AWS security.

Could the CTO or some other employee go to Amazon's office to do something like this? I genuinely wonder.

Re: Uber investigating breach of its computer systems

#288

Post by halz »

WirelessGigabit wrote: post #283

Our security just send around an email that they're disabling Google Chrome's password manager. While I understand not wanting those passwords in Google's hands, the reality is that they do have the $$$ for security. But instead of being able to leverage that functionality, and the Generate Password functionality we now have to resort back to name_of_application_my_name or something like that. Do not ban things just…

When browser managed credentials are synchronized across devices, an attacker may be able to move laterally into an enterprise by compromising the personally managed device or personally managed account (since it may be without 2FA, or may use a shared/guessable/weak password thats shared across dozens of compromised websites, or be far behind on app/OS patches, etc..)

Re: Uber investigating breach of its computer systems

#289

Post by mcstempel »

trollied wrote: post #282
mcstempel wrote: post #276

Earlier quoted context omitted.

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

I’ve not read up about webauthn yet. How does it work & what makes it unphishable?

Here's a bit more background on WebAuthn: https://stytch.com/blog/an-introduction-to-webauthn/

What makes it unphishable is that the authentication is not based upon something that a user can be deceived into sharing with an attacker. Passwords and one-time passcodes (OTPs) can both be remotely acquired from users when attackers convince users to share these text-based verifications with them.

Because WebAuthn validates possession of a primary device that was previously enrolled (either the computer/phone the user is leveraging for the biometric check or the user's YubiKey), it's device-bound and cannot be phished.

Re: Uber investigating breach of its computer systems

#290

Post by kccqzy »

WirelessGigabit wrote: post #283

Our security just send around an email that they're disabling Google Chrome's password manager. While I understand not wanting those passwords in Google's hands, the reality is that they do have the $$$ for security. But instead of being able to leverage that functionality, and the Generate Password functionality we now have to resort back to name_of_application_my_name or something like that. Do not ban things just…

Disabling a password manager that's built into a browser? That's simply madness. What do they expect people to use? Their brain to remember all their passwords rather than a password manager? And rely on their brain to know they are on a site whose domain doesn't match the domain in the password manager despite looking very similar?

Also this has nothing to do with passwords in Google's hands. They could turn off syncing in Chrome and have a completely local password manager. I personally do exactly that.

Your org will suffer many data breaches due to this policy.

Post reply on HN