The Uber Breach 2022. What Happened in the Uber Breach?

Uber recently notified authorities that they suffered a “cybersecurity incident.”  Meanwhile, the hacker behind the incident has publicly shared some startling details with news outlets, and also let Uber employees know – using their own corporate Slack – of the attack.

Uber security and privacy woes started in 2011 with reports of parties treating guest to the Uber’s “God View”. Apparently there were two versions of the “God View”. The anonymized version, which as OK, and the “Creepy Stalker version”, showing whereabouts and movements of specific Uber users in real time. Entrepreneur Peter Sims was featured in the creepy version, found out, was upset about it, and wrote a Medium post (Can We Trust Uber?) which went viral. The news reports eventually gave way to regulatory investigations.

Then came the breaches.

Two breaches to be precise.

The first breach occurred in or about May 2014 when an intruder gained access to personal information about Uber drivers. Uber suffered a second, larger breach of drivers’ and riders’ data in October-November 2016. Uber failed to disclose the 2016 breach to consumers or regulators despite the fact that it took place while the company was under investigation for the first breach plus the “God View” incidents.

Surprisingly, regulators did not like that and Uber ended up paying out a record 148 Million penalty.

To top it all, on August 20, 2020, a criminal complaint was filed charging Joseph Sullivan, Uber’s former chief security officer, with obstruction of justice and misprision of a felony in connection with an alleged attempted cover-up of a 2016 data breach. The outcome of the criminal case will have serious implications for all companies, executives, and cybersecurity professionals.

Mr. Sullivan should be presumed innocent until proven otherwise but, if you are involved in decision making during security incidents, don’t wait to find-out the outcome of the case to start learning the lessons. The business’s duty to disclose a data breach is not always clear, and there are often a myriad of laws, regulatory practices and consumer expectations when navigating an incident response situation.

 

On Thursday, September 15th, Uber confirmed reports of an organization-wide cybersecurity breach. This is an evolving situation, but we will bring you here the latest information and commentary as we get it.

 

Update 9/20/22: Uber confirmed in a security update that the named attacker "Tea Pot" was affiliated with the Lapsus$ hacking group, famous for breaching NVIDIA, Samsung, and Microsoft earlier this year. According to their early investigations, it is likely that the attacker targeted an external contractor whose credentials were bought on the dark web.

 

What happened

Here’s what we know so far, pending investigation and confirmation from Uber’s security teams.

1.    The attack started with a social engineering campaign on Uber employees, which yielded access to a VPN, in turn granting access to Uber's internal network *.corp.uber.com.

2.    Once on the network, the attacker found some PowerShell scripts, one of which contained hardcoded credentials for a domain admin account for Thycotic, Uber’s Privileged Access Management (PAM) solution.

3.    Using admin access, the attacker was able to log in and take over multiple services and internal tools used at Uber: AWS, GCP, Google Drive, Slack workspace, SentinelOne, HackerOne admin console, Uber’s internal employee dashboards, and a few code repositories.

Screenshot from a private message with the hacker on Telegram

The critical vulnerability that granted the attacker such high levels of access was hardcoded credentials in a PowerShell script. These credentials gave admin access to a Privileged Access Management (PAM) system: Thycotic. This tool carries huge amounts of privilege, making it a single point of failure; it stores both end-user credentials for employee access to internal services and third-party apps as well as DevOps secrets used in the context of software development. This is a worst-case scenario. The PAM system controls access to multiple systems, and having admin access means you can give yourself or extract secrets to all connected systems. This has appeared to give the attacker complete access to all of Uber's internal systems.

This isn't the first time we've seen an Uber data breach: in 2014 hackers gained access to an AWS S3 bucket after developers leaked secrets to a public git repository. Two years later, a similar incident happened when attackers exploited poor password hygiene by some developers to gain access to private repositories which contained multiple access credentials. Now we appear to have the final episode in the trilogy, and it appears to be the most serious situation yet.

How bad is it?

Critically, Uber’s Privileged Access Management (PAM) platform was compromised through the exposure of its admin credentials. Privileged access management (PAM) is the combination of tools and technology used to secure, control, and monitor employee access to an organization's critical information and resources. With that in mind, the attacker may have gained access to nearly all the internal systems of Uber. Let’s go through the ones we know of based on preliminary information and evidence to understand the severity of this incident.

Thycotic – Severity = Critical

The attacker gained admin access to the Thycotic PAM system. PAM systems can be a single full-featured software console or a collection of multiple tools; in the case of Thycotic, it is a single tool with many features. It can control access to different services and also has a secrets manager where credentials and passwords are stored. It appears the hacker was able to access secrets inside the secure storage, granting the worst possible scenario for Uber.

AWS instance – Severity = Critical

The AWS instance controls the cloud infrastructure of Uber's applications. Depending on configuration, privileges, and architecture, the attacker can potentially shut down services, abuse computing resources, access sensitive user data, delete or ransom data, change user access, and many more things.

VMware vSphere – Severity = Critical

VMware vSphere is a cloud computing virtualization platform. This is a critical platform as it interfaces with both cloud computing and on-premise servers which can give attack access to controlled on-premise servers as well as many administrative functions that would help an attacker move deeper into systems.

SentinelOne – Severity = High

SentinelOne is an XDR (eXtended Detection and Response) platform. Simply put, this platform connects to your mission-critical systems and lets you know if there are security issues. Any attacker that can obtain privileged access to this system can obfuscate their activity and prolong their attacks. XDRs can bake in "backdoors" for Incident Response (IR) teams, such as allowing IR teams to "shell into" employee machines and potentially widening the attacker's access.

 

Slack workspace – Severity = Medium

The internal messaging system of Slack can be used to great effect as an attacker to launch phishing campaigns. As the attacker has the instant trust of other users, they can send malicious links, try and get admins to elevate their privilege, and access sensitive information. As the attacker has made themselves known, this is likely a smaller threat.

 

GSuite Admin – Severity = Medium

GSuite is a tool used by many companies to manage their users, store data, and many other administrative tasks. With admin access, the attacker can create and delete accounts, but would also likely have access to employee data and other sensitive company data.

 

HackerOne – Severity = Medium

HackerOne is the platform used to pay and communicate with security researchers that find vulnerabilities within systems for rewards. Given the level of detail bounty hunters usually provide, anyone with access to the HackerOne tenant has detailed how-tos on how to exploit (likely unpatched) vulnerabilities in other areas of their IT systems. This means persistence is highly likely.

 

The hacking group apparently gained access to several internal Uber systems after stealing a third-party contractor's credentials and then convincing the contractor to approve a two-factor authentication request.

The security breach that hit Uber last week was the work of Lapsus$, Uber said in a blog post Monday. The South American hacking group has attacked a number of technology giants in the past year, including Microsoft, Samsung, and Okta.  

While the attackers accessed several internal systems, Uber said it does not appear they infiltrated any public-facing systems, user accounts, or databases that store sensitive user information like credit card numbers. Additionally, Uber said it doesn't appear that the attackers accessed any customer or user data stored by its cloud providers.

Uber Breach 2022 Analysis

Based on news reports regarding the breach of Uber’s systems, the attacker manipulated one of the company’s employees into sharing their password, which allowed for the initial access of the target. The criminal hacker then proceeded with launching MFA fatigue attacks and compromising a worker’s Slack account to send out a message announcing to other employees that their company had suffered a data breach. In response, Uber has restricted access to Slack for internal communication. Among other compromised services are Google Cloud Platform, OneLogin, SentinelOne incident response portal, and AWS.

Several security researchers have already claimed the breach to be a “total security compromise” that might also result in the attacker posting the company’s source code online despite the tech giant’s representatives trying to “put out the fire” that started across media channels. The San Francisco-based ride-hailing company’s stance on the matter is different from the narrative voiced by non-Uber security analysts, mainly claiming that there is no evidence suggesting that the threat actor accessed sensitive data.

Prior to the incident, logs gathered from infostealers were put up for sale in the underground market. The infostealers that were used in these attacks against Uber employees were Raccoon and Vidar. The evidence suggests that the attacker used the acquired data to move laterally inside Uber’s network.

The motives of the threat actor are yet to be revealed, but his message shared in a channel on Uber’s Slack includes a demand for better pay for drivers. Uber representatives have not released any more updates publicly, claiming that the incident is currently under investigation.

Social engineering techniques are on the rise. This attack only mirrors the recent trend toward criminal hackers’ accumulating more sophisticated approaches to leveraging the human factor in their attacks. Drastic times call for drastic measures! Join forces with SOC Prime to enhance your threat detection capabilities and security posture with the power of a global community of cybersecurity experts. You can also enrich the collaborative expertise by contributing to SOC Prime’s crowdsourcing initiative. Develop and submit your Sigma and YARA rules, get them published to a platform, and receive recurring rewards for your input.