Uber, the ride hailing giant, confirmed a major system breach that allowed a hacker access to Vsphere, google workplace, AWS, and much more, all with full admin rights. 

In what that will be remembered as one of the most embarrassing hacks in recorded history, the hacker posted screenshots to the vx-underground twitter handle, from the console of the hacked platforms as proof, and included internal financial data and screenshots of SentinelOne dashboard.

If you are going to hack a role, choose “Incident response team member” for optimal results

Before we dive into the “how”, let’s first explore the role of an Incident Response (IR) team member. When an incident (hack, production failure…) occurs, the incident response team are the company’s “first responders”, when there is a fire, they are the “firefighters”. Due to the importance of their job, IR teams get an unprecedented level of access, usually when they are on-call – making them an ideal target.   

Zero Trust vs “Uber” Trust 

The hacker, who either targeted the IR team or stumbled upon it by chance, was able to socially engineer a member of the IR team utilizing a technique known as “MFA Fatigue” – bombarding the user with 2nd factor approval requests. The hacker proceeded to contact the IR team member via WhatsApp, posing as an Uber IT support rep. He then claimed the requests will end upon approval and that the IR team member simply needs to approve the login to end the flood of requests.

Following the approval, the hacker was able to enroll his own device as a 2nd factor, giving him everything needed to login to the rest of the applications in the environment.
  

When the hacker was able to access Uber’s internal network, he located a shared folder containing a powershell script with admin credentials and used them to obtain access to the company’s Privileged Access Management (PAM) platform, thus gaining access to Uber’s entire network.

While the principals of “Zero Trust” call to reduce attack surface by segregating networks, apps and access to avoid?, Uber’s architecture provided the user with “Uber” rights. 

The hacker path:

Social Engineering  => DUO MFA => 2nd factor approval =>Added Device to 2nd factor=> VPN access => Viewed internal network => Powershell script with privileged credentials => Access to PAM => GOD_MODE

Centralized Authentication: 

The fault to this ordeal is an inherent one, and a part of every centralized authentication, lets elaborate a bit: back in the day we used to manage credentials per application or data repository, a breached identity “Attack Surface” would apply only to a single applications; a 1:1 attribution between identity and action, but we had to manage a lot of credentials. 

This method was decentralized by nature, from a scalability aspect an impossible task. 


To circumvent the scalability issue we created Identity Providers (IDP) a centralized approach that enabled us to share an identity across applications, using a single set of credentials, increasing our potential attack surface across the organization, understanding this risk we added authentication factors, each with its own flaws. 

The tradeoff between decentralized authentication and IDP led to better scalability, user experience and answered operational needs, it also led to hacks just like the Uber Hack, Centralized Authentication = Once you are in you are in, have fun! 

What can we do? 

But Uber did have a DUA MFA! And SentinelOne! So what did they do wrong? 

Nothing really, they followed industry standards, the problem is that these standards will not protect you once a hacker is in. 

Decentralized authentication is not coming back, nor should it! But what if we took a different approach and decouple authorization from authentication by using dynamic access policies, instead of just adding authentication factors, we can add authorization factors according to risk.

This model (shown above) treats authorization as a dynamic factor that correlates with the “risk circle” adding authorization factors that will provide an extra level of assurance both in verifying the user and preventing human errors caused by standing privileges. 

In Apono we solved this issue by enabling users to bundle permissions and associate them with users, creating Dynamic Access Flows that connect the risk circles above adding Multi Factor Authorization into the access policy.  

Each circle of risk is represented as a permission bundle, to each the admin can create a policy that combines different authorization factors, and a time frame for the access: 

  • User Justification – User must write a reason for needing access 
  • User + Admin Justification – When an access request is created both the requester and admin need to provide a reason to the approver.
  • Owner Approval – Access will be granted when the owner of the groups of permissions approves it 
  • IDP Owner Approval – Only when IDP owner approves the request the access will be granted 
  • Restricted Timely Access – Access is only open to a defined period of time, automatically revoked upon the end of the defined period 

With Apono you will be able to create Declarative Access Policies, defining authorization factors using our declarative access flow wizard 

Using Apono’s Declarative Access Flow Wizard you will be able to create access flows with an array of authorization factors, approver groups, two-step human authorization.