In September, ridesharing company Uber disclosed that hackers had stolen the personal information of about 57 million customers and drivers.
The days following the attack were full of speculation around how the attacker – allegedly a 17 year old – was able to gain access to the systems.
As we continue to follow the story of the Uber breach, 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 organisation itself) is what happened after that.
In this article, we’re dissecting the Uber hack with a focus on hard-coded credentials, which were reportedly used to gain administrative access to the company’s privileged access management (PAM) solution (provided by another vendor), opening up more high-risk access. This is based on CyberArk Red Team’s analysis and the reports publicly available. We’ll also demonstrate how stacked defences can cooperate to impede or stop related attacks.
Unpacking the Uber security breach
Phase 1: Initial Access. By obtaining access to login information for Uber’s VPN infrastructure, the attacker was able to enter its IT environment.
Phase 2: Discovery. This contractor most certainly did not have elevated or unique access rights to critical resources, but he or she did have access to a network share, much like other Uber employees. Either this network share was accessible or the broad read ACL setting was set incorrectly. As a result, the hacker located a PowerShell script with hard-coded privileged credentials for Uber’s PAM solution within the network share.
A quick aside: IT teams and developers frequently automate processes by building scripts that require some type of credentials to carry out authentication (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 to 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 for administrative access to a privileged access management programme. These credentials seem to have not been rotated in a while, which makes them considerably simpler to exploit.
Phase 3: Privilege Escalation, Access PAM System. The attacker was able to further elevate privileges by harvesting the hard-coded admin credentials for the privileged access management system.
Phase 4: Access Secrets from PAM System, Reach Critical Company Systems. The attacker ultimately obtained “elevated permissions to a number of tools,” according to Uber’s most recent 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 cloud management console, which Uber uses to store confidential customer and financial information.
Phase 5: Data Exfiltration. The attacker “downloaded some internal Slack communications, as well as accessing or downloaded information from an internal application our finance team uses to track some bills,” according to Uber, which is still looking into the matter.
Advice for Dealing with Embedded Credentials by taking a Defence-in-Depth Approach
Proactive security demands defence-in-depth, or a combination of complementary security layers that are in support of a zero-trust strategy. The absence of embedded credentials in the first place may be of importance in this situation.
We advise concentrating on 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. We are aware this is easier said than done, therefore concentrate first on your organisation’s most vital and potent credentials and secrets before extending these best practises for managing secrets to gradually reduce risk.
After you’ve made a plan for tackling hard-coded credentials, consider these additional steps to harden your defences:
The biggest threat still comes from credential theft. As we’ve lately observed, attackers are becoming more adept at getting around MFA utilising a wide range of routes and approaches. In fact, this story featured multiple MFA compromises. Your staff members are your gatekeepers, so routinely teach them to recognise and report phishing to help avoid identity theft. Due to the dynamic nature of attacks, expect vigilance but not perfection.
To guarantee that workers and outside contractors have the least amount of permissions necessary to perform their responsibilities, consistently use the principle of least privilege, beginning at the endpoint. Set up privileged access management programmes with the utmost care. Access to privileged accounts for administrators should only be granted when it is absolutely necessary. All privileged account access must be segregated and authenticated.
This assault highlighted the “zero secret” issue that security experts have long debated: What would happen if someone managed to access the key that serves as the ultimate safeguard for all other credentials? Strong defence-in-depth controls that are both proactive and reactive are essential for this reason. Therefore, even if MFA fails, there are backup systems in place to find and stop threats before they get to this stage.
Limiting lateral movement from compromise to a strong security solution can aid enterprises. This can be done by removing standing access to sensitive infrastructure and online or cloud interfaces. 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 that could have been avoided by a single technology solution or for which a single person, company, or provider was to blame. Defence-in-depth is crucial because it makes it more difficult for attackers to move, work, and eventually succeed in their objectives.
About the Author
Rich Turner is SVP EMEA at CyberArk. CyberArk is the global leader in Identity Security. Centered on privileged access management, CyberArk provides the most comprehensive security offering for any identity – human or machine – across business applications, distributed workforces, hybrid cloud workloads and throughout the DevOps lifecycle. The world’s leading organizations trust CyberArk to help secure their most critical assets.
