top of page
  • Alex Vaystikh

Uber Hack: self-service identity is hard

The recent Uber hack is a stark reminder that you can still get hacked even with identity and access management, secure login policies, multi-factor authentication, and the scale and expertise of a company like Uber.

Bleeping Computer has a write-up on the incident that I thought was good, so let’s look at a few of their observations.

“MFA Fatigue attacks are when a threat actor has access to corporate login credentials but is blocked from access to the account by multi-factor authentication. They then issue repeated MFA requests to the target until the victims become tired of seeing them and finally accept the notification.”

So, we know the attacker had the username and password. And we know username/password is weak, so we have 2FA. Is 2FA enough? No. And Uber (and the rest of us) now know it.

Most 2FA submission forms can be brute-forced on the cheap. How? Most 2FA fields are 6 digits long with unprotected forms (no rate limit), allowing multiple requests. Six digits means means a million combinations: a lot for a human, nothing for automation. $40 is enough to rent enough machines to brute force a million combinations in a few minutes. Check this out for more ways to bypass 2FA.

Luckily, Uber’s 2FA seem to have been secure as the attacker was not able to crack it. Plus, Uber had another layer of defense!

And well, he accepted and I added my device”

-- screenshot, in the article, of a conversation with the hacker.

The simple phrase “added my device” tells a lot.

Uber’s website says they manage devices which y means unauthorized and unmanaged devices are not allowed on the uberinternal.com network. Requiring a trusted device adds another layer of security, and another variable to the MFA: username+password, some token, and(!) come from a known trusted device.

So where’s the failure?

Did MFA fail? No. The attacker knew the username and password but needed to social engineer the victim to give it to him.

Did MDM fail? No. The attacker presumably needed to allow Uber to manage their device before logging in.

The failure seems to be in the policy for adding trusted devices. Uber allows employees to add/remove devices themselves to make work easier, reduce IT tickets, and save time. The policy mostly makes sense: to add a device in Uber, one needs to be on a trusted device already and successfully log in with 2FA. But the devil, and the hacker, are in the details.

Please let me know if you want me to discuss how to improve this policy and maybe share what you would do?


-- av



bottom of page