On Thursday 15th of September, news started circling online about another potential security breach and this time the victim is Uber. Now, although Uber is yet to confirm that they have in fact been breached, initial indications from the information shared on the Internet suggest that they have and from what I’ve seen to date, the breach could’ve been prevented.

Let’s take a look at some of the information that has been shared before and then based on what we know, we will take a look at how the breach could’ve been prevented.

• Uber has confirmed that they are now aware of a ‘potential breach ‘cybersecurity incident’

• It is said that the breach occurred using compromised credentials as a result of a successful social engineering attack on an employee. Although multi-factor authentication may have been enabled on at least one of the compromised accounts, the threat actor used tactics rising in popularity to gain access. It was reported across social media that the threat actor managed to trick the employee into accepting a push request after a period of spamming them by calling the victim and posing as an employee from Uber IT; this tactic is known as push phishing, an increasingly popular method that threat actors are now using to bypass two-factor authentication controls.

• As you can see from the screenshots above, the multi-factor authentication (MFA) solution in place allowed the threat actor to add their own device once access was granted. Although it has not yet been confirmed which multi-factor authentication solution Uber is using, the ability to allow users to add their own devices is a feature MFA security companies such as Okta and Duo offer. When enabled, once a user has successfully authenticated, they can choose to add additional devices; a feature designed to help reduce friction for end users and reduce support requests.
• Once the threat actor had gained access to Uber’s environment, they likely spent time exfiltrating data and other valuable information. In fact, we know from information shared online that the threat actor had apparently accessed key systems which included Uber’s Amazon Web Services (AWS) tenant. The following images were circulated online which apparently show proof of what the threat actor could access.

• The threat actor also posted on Uber’s slack channel to notify them that they have been hacked but apparently, employees saw this as a joke. It is assumed by this point that the threat actor had already exfiltrated valuable information which could have included Uber’s source code and modified/created other accounts to maintain access to Uber’s systems.

This is very much still a live and ongoing story and information is continuously being shared across social media platforms. We suspect that Uber will also release further updates in due course.

This is not Uber’s first run-in with a security breach as Uber was last breached in 2016 and hackers back then managed to gain access to approximately 57 million personal Uber accounts. So it’s no surprise that if this breach turns out to be true and the extent of the damage is as bad as initially thought, this could be very bad for Uber as a business.

Just three ways this breach could have been prevented?

Credential theft through a combination of social engineering and push phishing appears to be the root of this breach and it’s no surprise given that weak and/or stolen credentials have been the number one cause of breaches for some time now. Although security technology companies have been working for years to solve this issue, there still appears to be a long way to go, so how do breaches like this stop? One could argue that the possible solutions are endless but here are just three ways this breach could’ve been prevented.

• End-user training: Security is everyone’s responsibility and therefore it is important to regularly provide competency training for all employees. Employees that have better cyber security awareness are less likely to fall victim to common attacks such as social engineering and phishing.
• Internal systems & processes: Unfortunately, even where an employee may be able to thwart an attack, the threat actor may eventually find a way in and therefore it is important that companies have processes and procedures in place for reporting suspicious/anomalous behaviour. Whether reported by an employee or picked up automatically by a system, the business should have the right systems and teams in place that allow them to investigate each report. Moreover, processes that require regular password changes should be enforced or better yet, companies should start to explore how passwordless can be used to get rid of passwords.
• Multi-factor authentication: While multi-factor authentication attempts to address the issue with weak and/or stolen credentials, unfortunately, threat actors are now using methods to get past these controls. In particular, with this breach, the attacker used push phishing which is an attack method that threat actors use when they have access to compromised credentials (username and password). When the threat actor accesses a system that requires additional authentication (MFA) with those compromised credentials, the MFA request will often be sent to a mobile device as a push notification. The problem for the threat actor is that they don’t have access to the device as it’s likely owned by the person who has had their credentials compromised. Therefore, the threat actor relies on the victim simply accepting the push request or they employ social engineering techniques to get them to accept the push request. In the case of this breach, the threat actor posed as an employee from Uber’s IT department and called the employee, tricking them to accept the push notification. Once the push notification had been accepted, the threat actor had the ability to add their own device so that they wouldn’t need to rely on the employee accepting further push notifications.
  
  As you can see, the issue is not the MFA solution, it’s the end user who has fallen victim to social engineering. Furthermore, Uber had enabled a feature in the MFA solution that allowed end users to add their own devices once successfully authenticated, again this is a result of the social engineering attack being successful.
  
  So when we look at MFA, although it does hinder unauthorised access attempts with compromised credentials, end-user training is still crucial. Furthermore, it’s not wise to solely rely on the end-user cyber security awareness; other security controls should be considered and regularly reviewed, including the configuration of any existing MFA solution. Duo has some good recommendations on how to prevent push phishing attacks here.