20 September, 2022
Uber’s Recent Breach
A Hacker’s Perspective
When it comes to any major security breach, it is important to take a moment to understand the ins and outs of how it was executed to prevent your organization from experiencing a similar incident in the future. It’s easy to have a “that could never happen to me” mindset, but the truth is, if it can happen to Uber, it can happen to anyone.
An experienced security expert at BreachLock has broken Uber’s recent hack down into an easy-to-understand format to aid fellow security leaders and all professionals in understanding how easily this could happen to anyone and exactly how a hack of this scale was executed
On September 15th, Uber suffered a breach. A hacker managed to gain unrestricted access to Uber’s network. Uber released two statements saying that they are “responding to an incident” and that No sensitive user data had been obtained.
The Uber team was notified by the hacker, directly on their internal Slack application as shown by @ColstonSeal.
The hacker managed to obtain a “Golden Ticket“, meaning administrator level access to everything. The popular malware research site (@vxunderground) obtained screenshots from the hacker.
Through the administrator account, the hacker had access to the Slack Administration panel, the Sentinel One dashboard, an AWS account and likely more.
Slack is a new way to communicate with your team. It’s faster, better organized, and more secure than email. – https://slack.com/
Endpoint security software that defends every endpoint against every type of attack, at every stage in the threat lifecycle. – https://sentinelone.com/
Amazon Web Services offers reliable, scalable, and inexpensive cloud computing services. Free to join, pay only for what you use. – https://aws.amazon.com/
Reconstructing the Hack
Despite the high impact, the attack that took place was not complex. We often test for these types of attacks in Red Team engagements. To keep things simple we’ve broken down the attack in an attack chart all the major phases of which are broken down below.
1. Obtaining User Credentials
The hacker managed to obtain a phone number of an employee and used that to send phishing links. Through that, he managed to obtain user credentials. This is where the first defensive layer came into play, two-factor-authentication (2FA).
2. Connecting to the VPN
Without the 2FA code the hacker could not log in to Uber’s VPN service. The phishing attack was not (or did not have to be) refined enough to bypass 2FA protection. 2FA verification comes in two forms:
- Push-based: You’ll get a notification send to your phone that you have to approve.
- Poll-based: You’ll have to supply a token to the platform you are authorizing to.According to the hacker himself, Uber used push based 2FA allowing too harass the victim with 2FA notifications until he approved. This is known as 2FA fatigue and hackers will often perform this late at night to increase chances of success.
Since the VPN was configured to allow (simultaneous) connections from anywhere in the world the hacker added his own device so he could now freely connect to the VPN.
3. Scanning the Internal Network
While connected to the VPN the hacker had access to the internal network and started scanning the internal network for network shares. One of the shares hosted PowerShell scripts that contained credentials for an administrator account.
The hacker himself again, openly talked about this.
How Could This Have Been Prevented?
It’s wise to operate under the assumption that at a point in time your organization will be hacked. Other than striking pre-emptively by performing regular penetration Testing we should learn from the Uber breach. For this we’ll look at the attack chart again and identify the weak points.
1. When possible, use POLL-based 2FA
In this case, two-factor-authentication (2FA) was in place on the VPN, however, the push-based system makes people susceptible to 2FA fatigue. By adopting a poll-based 2FA, the device holder will not get notifications that can be approved at the click of a button.
If a PUSH-based 2FA is in place this can in some cases, come with a GEO map indicating the origin of the login attempt. This extra information will help the user determine if a login request is valid.
2. Disabling Simultaneous User Logins
In the ideal world, only known IP addresses would get access to the VPN, but in the real world this is likely not a realistic scenario. However, you should identify if a user ever needs to be logged in more than once simultaneously. If this is not needed, we recommend you disable this.
3. Only Open Up Network Shares
if Needed Network shares as in this case can contain sensitive information. In this case the administrator credentials were the crown jewels, but any manner of sensitive information might be exposed on your network. We recommend that you frequently look at which shares are available to which user groups on your network.
4. Avoid Hard Coded Credentials
As a general rule, always avoid directly coding credentials into programming code. For this, environment variables or application tokens are often used. Application tokens only hold a limited set of privileges, required for the task at hand.
Incidents like these are 100% avoidable, but the best we can do as cybersecurity professionals is learn from them and help educate your colleagues and peers of the signs of being targeted or victimized by a threat actor before it’s too late. It is not always safe to assume that all members of an organization, especially those with privileged access, would recognize suspicious behavior if something similar were to happen to them.
If you’d like to connect with a security expert today for advice on preventing a cyberattack in your organization, contact us here.