Meaningful Learnings from the Uber Breach

Written by

The cybersecurity industry is predictably abuzz following the Uber security incident first reported on September 15. This concerns how an (allegedly) 17-year-old attacker was apparently able to hack the ridesharing giant’s IT infrastructure and acquire access to user data, as well as access vulnerabilities reported to Uber’s HackerOne account. It’s important to note that this was not a breach that could have been avoided by a single technology solution. Nor is it one in which a single person, company or provider was to blame.

Concerning the attack itself, there are a number of interesting elements that cybersecurity professionals can learn from. Much of the analysis has focused on the human element: social engineering and multi-factor authentication fatigue – but the real turning point for the attack happened post-initial access. Uber’s September 19 security update answered some questions (whilst sparking new ones) by naming Lapsus$ as a potential attacker group of interest.  

“Does it really matter who the assailant was, or how they got inside?” is the question that begs to be asked. If you as a security professional have an ‘assume breach,’ mindset, what happened after the initial foothold makes this attack not just newsworthy but actionable.

Based on CyberArk Red Team and Labs’ analysis, let’s dissect the Uber hack more, focusing on the hard-coded credentials that were reportedly used to gain administrative access. We’ll also demonstrate how stacked defences can work together to impede related attacks.

What We Already Know About the Attack

  • Step 1 – Initial access: By obtaining access to credentials for Uber’s VPN infrastructure, the attacker was able to enter Uber’s IT environment.
  • Step 2 – Discovery: The contractor whose account was hacked probably did not have elevated or unique access rights to critical resources, but they did have access to a network share, much like other Uber employees. Either this network share was accessible or misconfigured to allow a broad read of the Access Control List. The hacker then located a PowerShell script with hard-coded privileged credentials for Uber’s Privileged Access Management (PAM) solution within the network share.

Side note: Both IT staff and developers frequently automate processes by writing scripts that require some kind of authentication credential (e.g., manual backup or generating custom reports by pulling data from databases). These credentials could be anything from privileged tokens and SSH keys to API tokens and other kinds of passwords. It’s typical for developers to embed (or hard code) these credentials into the code to save time and assure automation. This makes it difficult to manage and rotate the credentials because they are left open to everyone with access to the code. Hard-coded credentials used in the Uber breach allowed administrative access to a privileged access management program. These credentials looked to have not been rotated in a while, making them considerably simpler to exploit.

  • Step 3 – Access PAM system and privilege escalation: The attacker was able to further elevate privileges by stealing the privileged access management solution’s hard-coded admin credentials.
  • Step 4 – Access PAM system secrets and get to critical company systems: The attacker ultimately obtained “elevated permissions to a number of tools,” according to an Uber update. The potential for harm was high by accessing privileged access management solution secrets. According to reports, the hacker gained access to the SSO, consoles and the cloud management console, which Uber uses to store confidential customer and financial information.
  • Step 5 – Data exfiltration: While Uber is still investigating the incident, the company confirmed the attacker “downloaded some internal Slack messages, as well as accessed or downloaded information from an internal tool our finance team uses to manage some invoices.”

How to Mitigate a Similar Attack? Tips for Securing Embedded Credentials 

The first step to avoiding a similar attack would be to get rid of any embedded credentials. We advise stopping this practice in addition to performing an environment inventory to identify and delete any hard-coded credentials that may be present in code, PaaS configurations, DevOps tools and in-house developed applications. This is easier said than done. Therefore, concentrate first on your organization’s most vital and potent credentials and secrets before extending these best practices over time to gradually reduce risk.

Consider taking the following extra measures to strengthen your defenses after you’ve developed a strategy for dealing with hard-coded credentials:      

The biggest risk still stems from credential theft. As we’ve recently observed, attackers are becoming more adept at getting around MFA by utilizing a wide range of vectors and methods. In fact, the Uber story features multiple MFA compromises. Your staff members are your gatekeepers, so routinely teach them to recognize and report phishing to help avoid identity theft. As attacks continue to change, expect alertness but not absolute precision.

Additionally, it’s important to ensure workers and outside contractors have the least number of permissions necessary to perform their responsibilities. Consistently apply the principle of least privilege, beginning at the endpoint. Set up privileged access management programs with the utmost care. Access to privileged accounts for administrators should only be granted when it is absolutely necessary. All privileged account access needs to be separated and validated.

The ‘zero secret’ issue, with which security professionals have long struggled, was again highlighted by this attack: what happens if someone manages to get hold of the key that safeguards all other keys? Strong defense-in-depth controls that are both proactive and reactive are essential for this reason. They ensure other systems are in place to detect and stop threats even if MFA is compromised.

Limiting lateral movement can also be of enormous help. This can be done by removing standing access to sensitive infrastructure and online or cloud interfaces. Just-in-time elevation of privileges can significantly minimize the access of any compromised identity, reducing the blast radius of an attacker – especially when combined with robust authentication.

Final Thoughts

It’s worth re-stating that there’s no silver bullet solution to stopping cyber-attacks, and certainly not in Uber’s case, just as the tools and people it has in place are not at fault. No one believes attacks can be flat-out stopped anymore. But we can be in control of how bad they become. Attacks such as the Uber breach can be mitigated by robust, layered cybersecurity defenses, bolstered by constant and repeated staff education to help recognize potential sources of danger. Having these measures in place makes it more difficult for attackers to gain a foothold, move, discover and achieve their objectives. Just as importantly, they allow us to minimize the success and impact of attacks and get back to normal operations as quickly as possible. This is the meaningful learning we should take and apply to our own organizations.

What’s hot on Infosecurity Magazine?