The Uber 2022 Hack: Some quick thoughts
So for those who are unaware, Uber got hacked pretty badly last week. On Friday the 16th at 0125 UTC, Uber Comms announced they were responding to a cybersecurity incident via tweet. What followed was a lot of rumours and speculations before Uber released an official update today (the 20th of September) at 1430 UTC. I will give a quick summary of what that statement contained then some thoughts on the days in between.
The Official Investigations Findings
So according to the report, the initial access point was via a social engineering attack on an external contractor who Uber believes had their login credentials bought on the dark web. From there the contractor was either tricked into via social engineering, accidentally accepted or out of frustration accepted a MFA push notification. The attacker then access multiple other employee accounts and gained access to some internal tools. The attacker then posted in the company wide Uber Slack channel which alerted Uber to the hack.
Other Information
With Twitter being a pedestal for people to share the latest news before an investigation has concluded, there was some other information leaked, where possible I will include the source.
- Hacker posted a message to bug bounty researchers via HackerOne - source
- Hacker gained access to AWS instances, SentinelOne and Slack Admin - source
- Hacker disclosed some financial data for Uber - source
- Hacker disclosed data from vSphere, Google Workspace and more from AWS - source
- The hacker claims to have found some PowerShell scripts with admin credentials - source
- The hacker claimed to be from Uber IT via WhatsApp to get the contractor to accept the push MFA notification - source
The Combined Findings
I am going to take a guess here and post what, from what I currently have seen with screenshots, the timeline could be.
- Hacker gains login credentials for an external contractor, Uber believes that it was via a dark web marketplace - source
- Hacker then start spamming the contractor with MFA push notifications, then when it does not work they contacted the victim pretending to be Uber IT to trick the contractor into accepting the MFA push notification - source
- The hacker then logged into a VPN - source
- The hacker then gained access to some PowerShell scripts in a shared drive, one of these scripts contained admin user credentials to Ubers Privileged Access Management provider Thycotic - source
- Hacker gained the equivalent of domain admin from the above and gain access to a number of services used by Uber - source, source
- Hacker then after having their fun, posted in the Slack channel to all employees that Uber was hacked, which many employees initially thought was a joke - source
Some Thoughts from Myself
I wanted to jot down some thoughts that I have had regarding the incident.
One of the thoughts I have is that push notification based MFA is significantly less then secure than other methods. The best method is FIDO U2F key such as YubiKey, this is more secure than apps such as Google or Microsoft Authenticators. I think that those are the best options, however I think that push MFA is worse then SMS or phone call based MFA. The latter is considered a weak option due to the fact that sim swapping attacks however with telecom providers recently making it harder for this to happen, I think that it has become less of a risk compared to push notification MFA. For example, Google has push notification which asks you to accept or deny the request, however there is no warning which means you can easily accidentally click accept, especially if you are typing when the notification takes over the screen.
The second thought is around training staff, now do not want to cast all blame on the initial contractor, I think that it falls onto the shoulders of the security team equally. The security team is responsible for training the organisation as a whole, including on socially engineering. Now unfortunately this contractor was socially engineered, they attacker posed as the IT team via WhatsApp. The thought that comes to mind is the contractor should of asked themself the question, “why is this being requested?” they may have not fallen victim to the line “the only way to stop this is to accept it”. I think that security teams should have a decent amount of time (say 10-20%) focused on teaching staff to question why they are being prompted for MFA, why are they being sent this email, who is sending this email. I think that from a place of physical security, where we feel safe in our neighbourhoods, we have relaxed and taken that relaxation to cybersecurity, where we are not dealing with our neighbours, but with anyone around the world with an internet connect.
Finally for tonight, I have come to the conclusion that those who try and use the Uber hack as a platform for their security solution without waiting for the full picture to come out are extremely scummy. There is a Twitter thread from MalwareJake where even Uber Security engineers were being messaged by vendors once the news broke. Vendors claiming they would catch anything that went amiss or was misconfigured are lying through their teeth. I personally have an axe to grind here, there have been times when I was having great conversations with my new peers when I transition to security at a local security meet up. We then were interrupted to be asked “what vendors do you use” by a sales person, I know they are trying to do their job but a) I am new, I do not make decisions, b) I don’t make budget related decisions and c) the sales person in this moment took on the physical form of a YouTube ad that interrupts your video.
So there is some of my thoughts, I am still getting used to putting out what I think. Because I do know that there is a lot I do not know I have be hesitant to do something like this in the past, but the only way I can improve is by making a start and training to be better. Hopefully for the sake of security engineers around the world, I do not have the opportunity to summarise a hack like this for a while.