3 Tips for Mitigating the Uber Hack

Rideshare giant Uber found themselves in the headlines yet again last week when news leaked out that they had been hacked. 

This is not the first time for the company finding themselves in the headlines for being hacked or controversy. 

Based on reporting — much of it coming from the claims of the person taking credit for the hack so a few grains of skeptical salt need to be taken — the hacker annoyed their victim whose credentials they had acquired into accepting the MFA challenge by spamming them with a deluge of requests. 

They then used their initial access to access Uber’s VPN, allowing them to find PowerShell scripts where they picked up the credentials for Uber’s privileged access management (PAM) service. From that point, the hacker was like a kid in a candy shop, extracting secrets to give them access to all of Uber’s crown jewels. 

Apparently there was an internal network share that contained powershell scripts…

“One of the powershell scripts contained the username and password for a admin user in Thycotic (PAM) Using this i was able to extract secrets for all services, DA, DUO, Onelogin, AWS, GSuite” pic.twitter.com/FhszpxxUEW

— Corben Leo (@hacker_) September 16, 2022

From what we know, this included privileged access into their AWS, G Suite, VMware, Duo, and their OneLogin Identity Provider (IdP), which one security researcher referred to as “the golden ticket jackpot” because of all the additional access it gave them to all of Uber’s resources.   

It is still early days in terms of Uber’s incident response and it is not totally clear what data this hacker has accessed. 

That said, there are a number of conclusions that we can draw from this incident about what went wrong and how organizations can reduce their risk of experiencing such an extensive breach.

Initial Takeaways

For starters, we need to remember that we are not here to blame victims of breaches. Not only is it bad form, it is also bad karma. 

Hacks happen and everyone is hackable. The question is not about being unhackable as much as it is about how to mitigate the impact.

Human errors and failure to follow best practices are always going to be a constant. Errare est humanum. Find me the organization that doesn’t have someone that will just hit “Approve” when they are getting spammed at one in the morning just to get back to sleep. Security people need to remember that most people in the organization are not nearly as paranoid as they are just want their technology to work and leave them alone. 

As for why the creds to their PAM were coded into their PowerShell, I’ll just leave that point here for them to reflect on. Sure it makes the workflow more efficient, but no security story ever went well when it starts with PowerShell.   

What stands out here is not that the hacker was able to gain access to Uber’s network, but the extent of their access to apparently everything in the company. 

The question we should be asking is why did one single account have the ability to access so many different apps, services, and data?

A Clear Case of Over Privilege

Privileged access management (PAM) tools play an important role in helping us to securely manage our secrets and privileged access to our sensitive assets. 

But even when PAM is used correctly, it is still up to ensure that we are securing our identities and access layer by managing privileges. It may seem like an efficient choice to grant an identity wide reaching access privileges over multiple apps and services, but over provisioning of access exposes us to exponentially more risk.

Try to think of every access privilege as an opening in your perimeter. Necessity of work means that we have to allow enough access for our organization members to do their jobs. But each privilege granted is also an opportunity for a malicious actor to use in attacking your valuable assets. 

The widely accepted best practice of Least Privilege calls for us to limit privileges to only those that are really necessary. No more, no less. 

By limiting privileges, and thereby an attacker’s access, we can mitigate the damage that they can achieve once an identity is compromised. This helps to harden our defenses, removing identity and access risks before they can be exploited by being left open.

While this sounds relatively straightforward, common sense approach, implementing it is often difficult. This due to:

• The scale of identities, assets, and access privileges
• The different identity and access management (IAM) structures used by each app and service
• Lack of visibility over effective access paths throughout different cloud environments 

Authomize’s Cloud Identity and Access Security Platform enables organizations to overcome these challenges and mitigate their risks of data theft or compromise in the cloud.

3 Steps for Cloud Identity and Access Risk Mitigation

The approach to our risk of compromise needs to be one of mitigation, and not necessarily one that focuses just on prevention.

Following these steps, organizations can shrink their threat surface significantly and even detect threats before they have a significant impact.   

1. Reduce Privileges 

The first step starts with limiting access privileges down to the absolute minimum. 

This means first detecting all of the access privileges between identities and assets. Gaining this understanding means having visibility not just over the declared access privileges that have been provisioned to the identities, but also knowing which identities have access from the asset’s side of the equation. 

By integrating with all the elements in your cloud environments, from your IdP (Okta, Ping, Azure AD, and more) to your assets (AWS, Azure, Salesforce, GitHub, G Suite, and many many more) to your IAM tools like leading PAM provider Delinea, Authomize provides granular visibility down to the file level for the most effective mapping and control. 

Our SmartGroup Machine Learning engine collects all of the identity and access data from all of the connected systems, normalizing the data into a single “language” that can be processed to glean data-driven insights over access privileges and their usage. 

By understanding not just who has access, but how it is being used, it allows us to understand which access privileges can be revoked. Think of it as a “you don’t use it, you lose it” approach that considers that if an access privilege has not been used in say 30, 60, or 90 days, then it can probably be taken away without negatively impacting productivity. 

We then operationalize these data to offer contextual recommendations for right-sizing the access privileges in line with Least Privilege. These insights enable organizations to run smoother, more effective User Access Reviews that help them to reach the secure baseline they need for both security and compliance.   

2. Identify and Eliminate Privilege Escalation Paths

Along with achieving a state of Least Privilege, organizations face challenges from privilege escalation paths that allow an attacker to reach more sensitive data than their starting point would nominally permit them.

Scenarios include an identity who is not an admin being in a position to grant themself higher privileges. Maybe they are a Shadow Adim, cobbling together a combination of supposedly non-admin privileges to allow them to reach something higher. Or perhaps they created an EC2 within the target environment and became an admin there, thus becoming an admin that can impact other VMs if precautions are not taken.

Authomize identifies all of the effective access paths, meaning the ways that an identity can access their target asset, regardless of how many jumps it makes through various environments. Sometimes these privilege escalation paths are hidden in IAM groups or roles.  

Utilizing our granular visibility and SmartGroups ML, we are able to detect these risks for escalation and alert security teams on how to eliminate them. This is an important step in helping to reduce the risk of lateral movement that can expand the damage of an attack.

3. Monitor for Access Changes in Downstream Apps and Accounts

Integrating into all of the elements of the cloud environment with native connectors, REST APIs, and other methods for connectivity enables Authomize to detect changes to access privileges everywhere. 

This capability is important for helping keep critical IAM infrastructure like IdPs and PAM tools secure, alerting teams to ongoing threats. As such, Authomize acts as a protective layer on top of the PAM or other IAM tools, detecting changes from say a compromised AWS or G Suite account that may indicate that someone may be attempting to undermine the infrastructure. 

Gartner has described the ability to detect threats to the IAM infrastructure as Identity Threat Detection and Response (ITDR). You can read more about Authomize’s ITDR capabilities and uses in this explainer.

Stop Blaming the Humans

As we discussed above, hacks happen and humans will continue to make mistakes as we always will. 

Instead of placing blame or trying to explain how one solution would have prevented the whole thing from happening, we need to take a more mature approach that understands that getting identity and access right is a difficult game. 

I know it’s hard, but have a little empathy for the security team who must have had an absolutely terrible weekend. Chances are that their Monday wasn’t any better.

The main takeaway here is that bad days can happen to anyone. So when that day arrives, have we taken the proper steps to make sure that a bad day doesn’t turn into a terrible month.

For more information about how Authomize can help your organization to reduce your Identity and Access risks, contact us for a free assessment and demo.

The post 3 Tips for Mitigating the Uber Hack appeared first on Authomize.

*** This is a Security Bloggers Network syndicated blog from Authomize authored by Gabriel Avner. Read the original post at: https://www.authomize.com/blog/3-tips-for-mitigating-the-uber-hack/