Security lessons from the Uber breach

Rich Turner at CyberArk analyses the causes of the Uber breach and outlines the most important learnings

 

As with any large-scale cyber attack on a well-known company, the cyber security industry is busy speculating about the Uber incident, which was first reported on 15^th of September.

 

Questions are still being raised around how an allegedly 18-year-old attacker was able to gain access into the ridesharing giant’s IT infrastructure, and gather user data and access to Uber’s HackerOne account.

 

While it is inevitable questions will be raised, it’s important to reiterate this breach could not have been avoided by a single technology solution. Nor is it one in which a single person, company, or provider was to blame. Saying that, there is a lot which can be learned from the breach, with it having a number of interesting elements for cyber security professionals to delve into.

 

To date, much of the analysis has focused on the human element of the attack – social engineering and multi-factor authentication fatigue – but the real turning point was post-initial access. This came when, on September 19^th, Uber released a security update naming Lapsus$ as a potential attacker group of interest.

 

It begs the question though, “does it really matter who the assailant was, or how they got inside?” Security professionals need to ‘assume breach’ to prevent any activity after the initial foothold.

 

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

 

What do we know?

The attack, as we know it, happened in five stages. These include:

 

Stage 1 – Initial access: The attacker was able to enter Uber’s IT environment by obtaining access to credentials for Uber’s VPN infrastructure.

 

Stage 2 – Discovery: The contractor whose account was hacked probably did not have elevated or unique access rights to critical resources. They did however, have access to a network share, as with other Uber employees. Either this network share was accessible or misconfigured to allow 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 which require some kind of authentication credential (e.g. manual backup or generating custom reports by pulling data from databases). These credentials could be anything. 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 credentials because they are open to everyone with access to the code. The hard-coded credentials used in the Uber breach look to have not been rotated in a while, which makes them considerably easier to exploit.

 

Stage 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.

 

Stage 4 – Access PAM system secrets and get to critical company systems: According to Uber, the attacker ultimately obtained "elevated permissions to a number of tools". 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 to the cloud management console, which Uber uses to store confidential customer and financial information.

 

Stage 5 – Data exfiltration: 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.”

 

Tips to mitigate similar attacks and secure embedded credentials

Again, it’s important to note this attack wasn’t one which could be stopped by one particular person, or a specific technology. So, when looking to mitigate against a similar attack, organisations need to understand a layered approach to security it key.

 

The first step is getting rid of any embedded credentials. It’s advised to stop this practice while also performing an environment inventory to identify and delete any hard-coded credentials which may be present in code, PaaS configurations, DevOps tools, and in-house developed applications. This is easier said than done, so an organisation’s most vital and potent credentials and secrets should be prioritised before extending these best practices over time.

 

Alongside this, the following extra measures should be enforced to strengthen defences after a strategy for dealing with hard-coded credentials has been developed:           

• The biggest risk still stems from credential theft. Attackers are becoming more adept at getting around MFA by utilising a wide range of vectors and methods. In fact, the Uber story features multiple MFA compromises. Staff are gatekeepers, so need to recognise and report phishing attempts to help avoid identity theft. As attacks continue to change, expect alertness not precision.
• Additionally, workers and outside contractors must have the least number of permissions necessary to perform their responsibilities. Organisations should apply the principle of least privilege, beginning at the endpoint, and 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, and all privileged account access needs to be separated and validated.
• The "zero secret" issue was highlighted by this attack. What happens if someone manages to get hold of the key that safeguards all other keys? Strong defence-in-depth controls which are 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 is key. This can be done by removing standing access to sensitive infrastructure and online or cloud interfaces. Just-in-time elevation of privileges can also significantly minimise the access of any compromised identity, reducing the blast radius of an attacker, especially when combined with robust authentication.

Attacks are inevitable

Again, there is no silver bullet solution to stopping cyber attacks. And this is exactly the case for Uber. No tools and people are at fault.

 

No one believes attacks can be fully stopped anymore, but we can be in control of how bad they become, and how quickly we recover from them. Attacks like this breach can’t be mitigated against fully, but robust, layered cyber security defences, bolstered by constant and repeated education of staff to help recognise potential sources of danger makes it more difficult for attackers to gain a foothold, move, discover, and achieve their objectives.

 

With the right approach, we can limit an attack’s success and make it easier and quicker to recover from.

 

---

 

Rich Turner is SVP EMEA at CyberArk

 

Main image courtesy of iStockPhoto.com