In the days following the September 15 Uber breach disclosure, much has been written about how one, allegedly 18-year-old attacker was able to successfully infiltrate the ridesharing giant’s IT infrastructure and gain access to sensitive user data. The human element of this story is getting lots of traction, with many zeroing in on multi-factor authentication (MFA) meltdowns and other Identity Security hygiene issues.
Uber’s September 19 security update answered some questions, while sparking new ones by naming Lapsus$ as a potential attacker group of interest.
As we continue to follow the story, we can’t help but ask, “Does it really matter who the attacker was, or how they got inside?” If you “assume breach,” then what makes this attack noteworthy (beyond the victim organization itself) is what happened after that.
Based on CyberArk Red Team’s analysis and available reports, we’re deconstructing the Uber breach with a focus on hard-coded credentials — the real flash point of this attack — which were reportedly used to gain administrative access to the organization’s privileged access management (PAM) solution (provided by another vendor), unlocking more high-risk access. We’ll also show how layered defenses can work together to help slow down or block similar attacks.
“Much of the Uber cyber attack analysis has focused on social engineering and multiple MFA attack vectors, but the real turning point for the attack happened post initial access. The presence of embedded credentials, in a misconfigured network share is critical to deconstructing this attack. It was the harvesting credentials for a PAM solution embedded in PowerShell script that allowed the attacker to gain high-level access, escalate privileges and set off on a veritable field day inside Uber’s IT environment. Proactive protection relies on implementing multiple security layers but most importantly, as this attack reinforces, the biggest takeaway is assume breach.”
– Shay Nahari, Vice President, Red Team Services, CyberArk
Deconstructing the Uber Attack: What We Reportedly Know
Phase 1: Initial Access. The attacker got inside Uber’s IT environment by gaining access to credentials to Uber’s VPN infrastructure.
Phase 2: Discovery. Most likely, this contractor did not have special or elevated privileges to sensitive resources but did have access to a network share, as did other Uber workers. This network share was either open or misconfigured to allow broad read ACL. Within the network share, the attacker discovered a PowerShell script containing hard-coded privileged credentials to Uber’s PAM solution.
A brief aside: Both IT teams and developers often automate tasks by creating scripts that need some form of credentials to perform authentication (e.g., manual backup or generating custom reports by pulling data from databases). These credentials could be anything from SSH keys and API tokens to other types of passwords and privileged tokens. To save time and help ensure automation, it’s common for developers to embed (or hard code) these credentials into the code. This leaves the credentials exposed to everyone with access to the code and makes them difficult to manage and rotate. In the Uber breach, hard-coded credentials granted administrative access to a privileged access management solution. These credentials appear not to have been rotated in some time — making them much easier to exploit.
Phase 3: Privilege Escalation, Access PAM System. By harvesting the hard-coded admin credentials for the privileged access management solution, the attacker was able to further escalate privileges.
Phase 4: Access Secrets from PAM System, Reach Critical Company Systems. According to Uber’s latest update, the attacker ultimately gained “elevated permissions to a number of tools.” By accessing secrets from the privileged access management solution, the potential for damage was significant: The attacker reportedly compromised access to the SSO and consoles as well as to the cloud management console where Uber stores sensitive customer and financial data.
Phase 5: Data Exfiltration. While Uber is still investigating the incident, the company confirmed that 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.”
Tips for Tackling Embedded Credentials as Part of a Defense-in-Depth Strategy
From our point of view, proactive protection requires defense-in-depth — a mix of complementary security layers — supporting a Zero Trust strategy that utilizes strong least privilege controls. Perhaps most important in this case is to not have embedded credentials in the first place.
To reduce cyber risk in your own organization, we recommend focusing on eliminating this practice, and taking inventory of your environment to find and remove hard-coded credentials that exist in code, PaaS configurations, DevOps tools and internally developed applications. We know this is easier said than done, so focus on your organization’s most critical and powerful credentials and secrets first and then expand these secrets management best practices to measurably reduce risk over time.
After you’ve made a plan for tackling hard-coded credentials, consider these additional steps to harden your defenses:
- Credential theft remains the No. 1 area of risk. And as seen recently, attackers are getting better at bypassing MFA using a variety of vectors and techniques — there were multiple MFA compromises in this story. Your employees are your gatekeepers — train them regularly to spot and report phishing to help prevent identity compromise. Expect vigilance, but not perfection, as attacks keep evolving.
- Consistently enforce the principle of least privilege, starting at the endpoint, to help ensure employees and external contractors have the lowest level of permissions possible to do their jobs. Configure privileged access management solutions with least privilege in place. Admins should only have access to privileged accounts that are absolutely necessary for their jobs. All access using privileged accounts should be isolated and authenticated.
- This attack emphasized the “secret zero” problem that security practitioners have long grappled with: What happens if someone gains access to the ultimate credential that protects all other credentials? This is why strong proactive and reactive defense-in-depth controls are equally critical. So even if MFA falls down, there are additional mechanisms in place to identify and block threats before they reach this point.
- Minimize standing privileged access. Removing standing access to sensitive infrastructure and web or cloud consoles can help organizations limit lateral movement from compromise to a powerful security solution. Especially combined with strong authentication, just-in-time elevation of privileges can greatly reduce the access of any compromised identity, limiting the blast radius of an attacker.
This was not a breach for which a single individual or vendor was at fault, nor was it a breach that a single technology solution could have prevented. That’s why defense-in-depth is so important: It makes it harder for attackers to work, move and, ultimately, accomplish their goals.
