Skip to content

The Uber Hack of 2022

It's been a wild year for Uber which has suffered through another security breach. The reactions to the hack have been mixed, and I've been contemplating how to respond. Here's my take...

What happened?

I'm seeing some conflicting reports of what happened, but at a high level, here's what I've been able to determine.

  • User credentials were compromised, possibly from a piece of malware that may have been present on the user's computer.
  • The attacker flooded the user with MFA requests until the user got so fed up with it, that they simply clicked the link to see if they could make it go away.
  • The attacker was able to enter the network and found a Powershell script with hardcoded credentials that had admin access to a bunch of systems, including Slack, and AWS.
  • On top of all of it, the attacker is claimed to be an 18-year-old kid.

What was the impact?

The guys at Uber are probably not having a great time right about now. Until Uber has completed their Post Incident Review, we can only speculate on its security posture and the true impact this breach has had.

It reminded me of this picture. An organization may have its security program in place, lock and gate, and be quite happy, yet forget to build a fence.


My reaction to all of this

Security Awareness

"Give the user more training!". Yeah, that did happen. I'm not convinced that more training would have helped. We rely on users to be smarter than the attacker, yet the user is only one part of the security process. There are a lot of things going on, and you can't expect one individual to be across everything.

MFA (Multi-Factor Authentication)

I am a firm believer in having multi-factor authentication. This breach has certainly highlighted a scenario I never considered - the attacker is simply trying, trying and trying even more until the user gets so fed up with the MFA requests, that they simply accept it just to get the notifications to stop.

More security tooling

I'm not convinced yet that more security tooling could have prevented this attack from happening. There are several vendors now jumping on the bandwagon to ride the wave of fear to sell their products in the wake of this attack. If you're one of those vendors: STOP! As a community, we should support and learn from each other, not try to sell more products.

Internal skills

Yes, we did say the attacker was an 18-year-old kid. The entry-level requirements for information security professionals require degrees, years of experience, and a bunch of certifications, yet an 18-year-old kid (probably without any certifications) was able to circumvent a highly complex environment.

We need to change the way we view Information Security within our organizations. Frameworks and certifications are important, but they should not be the ultimate defining criteria used to build our internal security teams.

Blaming the victim

Let's talk about the person who got hacked. That poor guy (or lady) is having a very bad day, and I feel for them. It's easy for a company to blame the individual for the hack, but let's be realistic. We're all human. All of us have our weak spots, where under pressure, we may also be susceptible to an attack like this.

Instead of blaming the person who clicked on the link, let's work with them, give them the support they need, and determine the real root cause of the issue.

Hard-coded credentials

Ok, this one is the one big smoking gun... Why did Uber have a PowerShell script, on a file share, with admin credentials to their core systems? This simply highlights that poor development practices can be a major contributor to any attack.

Escalation process

When the user received multiple MFA requests, did they reach out to their service desk for support?

  • If they did, what was the Service Desk's response?
  • If not, why not?

Lessons Learnt

  • Build use cases on your SIEM to detect multiple authentication attempts (even successful ones!), including multiple MFA requests.
  • Do not EVER hardcode credentials in scripts, or text files. Find a better engineering alternative.
  • Establish an escalation process through your internal service desk where users can escalate suspected hacking attempts, and can get support to identify issues like these quickly before it becomes a problem.