Since Uber announced their cybersecurity incident on the 15th of September, there has been numerous articles as the details of the breach were revealed.
As is always the case, some information is speculative and changes as time progresses. Without structured consistent forensics it is often hard to find the true detail. We have reviewed this information and have deemed the below to be consistently reported from multiple sources. In addition, we highlight “what we can learn from this” and “why we ALL need to lose the scapegoat mentality”.
- It is believed that the attacker gained the targets credentials by purchasing them from the dark web – these credentials were siphoned from a personal device via malware infection.
- Multi-factor (Duo) is believed to have been in place, and when the attacker repeatedly attempted to login, sending a two-factor login approval request to the target, which prevented access.
- The attacker used social-engineering techniques to coerce the target into accepting a login request. Some sources suggest the attacker contacted the target, claiming to be Uber IT, suggesting to the target that they needed to accept a request to stop the ‘glitch’ that was causing the high-volume of requests.
- This enabled the attacker to use the targets VPN to access the internal network.
- The attacker was able to find a network share of scripts (inc. PowerShell) that contained privileged credentials, giving them the keys to the kingdom.
- It has been suggested that these credentials allowed the attacker to access Thycotic, a Privileged Access Management (PAM) solution. If true, this would have been a rich source of privileges for the companies’ systems.
- Evidence shared online suggests that the attacker managed to compromise Uber’s Dup, OneLogin, AWS and GSuite environments. Several screenshots released by the attacker showed they had accessed GDrive, VCenter, sales metrics, Slack and their Endpoint Detection and Response (EDR) admin portal.
- The attacker sent a companywide Slack message to inform users of the breach and reconfigured Uber’s OpenDNS to redirect users to a page with X-rated content.
- The attacker was an affiliate of Lapsus$.
- On the evening of the 22nd of September, City of London police confirmed they had arrested a 17-year-old in Oxfordshire on suspicion of hacking.
- Given that there was no attempt to collect ransom or release company information it is believed that the attacker did this for ‘fun’.
Uber has stressed that the hacker didn’t access public-facing systems or customer user accounts and that their codebase remains untouched.
In response, Uber said it has contained the incident by identifying and blocking compromised and potentially compromised employee accounts. They have disabled affected internal tools, rotated access keys to several cloud services, locked down its codebase, and took steps in "further strengthening" its multi-factor authentication policies.
While the damage to Uber appears to be limited, it does indicate that those associated with Lapsus$ are still targeting high-profile targets, despite arrests for past activities.
So, what can we learn from this?
Our industry has a terrible habit of reacting too early to incidents, making assumptions from unvalidated information, and providing speculative assessments. We suffer from a lack of structured forensic investigations following incidents, coupled with inconsistent sharing of detailed information, can make it very hard to learn meaningful lessons.
We should always be cautious of the numerous vendors who will always come out in the heat of a new incident offering their mythical silver bullet. That one solution that will safeguard you from these attacks. When in reality, the best way to protect ourselves is by getting the basics right and layering our protection through people, processes and technologies.
It’s time to lose the scapegoat mentality
“Humans are the weakest link” - a phrase we hear a lot in cyber-security. Although this saying is true, it is also somewhat unfair. We are very quick to blame weaknesses in security tools or indeed point fingers at users. Where it is often business processes that should also be reinforced. We cannot expect all business users to be cyber experts. We should be layering protections around our users, not blaming them. Through the use of smart security technology choices with security awareness training and robust business processes.
Assuming the attacker knew the target was a contractor, it’s possible they exploited a potential weakness in the target’s knowledge of internal processes and people. Would the contractor have known where the support team is? How would they make contact? Who to reach out to when they had unexpected MFA login requests?
I think we all know using the same credentials for private accounts and business accounts is bad practice, but it happens. Did the contractor’s induction cover this advice? Do all staff, including contractors, receive the same security awareness training.
MFA is not infallible
Multi-factor or two-factor solutions are nothing new. They have been used to mitigate the risk of vulnerable username/password authentication since the 90’s, specifically with password reuse being such a huge problem. The push to MFA is ever growing, with Cyber Essentials increasing their focus on it with the new standard released earlier this year. This growth has also been aided by the growth of remote working, BYOD and cloud services.
While it remains a valid option, and rightly so, it isn’t perfect. As we have seen in this case, it is susceptible to social-engineering methods, as well as Man-in-the-middle (MitM) phishing, SMS hijacking and email hijacking.
Businesses could investigate switching to a more MitM resistant solution, such as FIDO2. However, this comes with additional costs and isn’t an overnight roll out. So, it may still make sense to stick with existing MFA solutions. For example, Microsoft Authenticator for MFA can layer in Conditional Access policies requiring usage of an organizational device to mitigate external phishing scenarios.
This can also be addressed through security awareness training. Helping users avoid common phishing methods and ensuring they know what to do if they receive unexpected authentication prompts.
Protect your privileged accounts.
In this breach, we saw the harvesting of privileged accounts which were then used to access multiple systems. It has been suggested these credentials were collected from scripts, including Powershell, that the attacker was able to locate. It is not clear if these credentials were stored in clear text within these scripts, but it feels like a safe assumption they were. Quite often these scripts are developed by system admins rather than developers, who may not be aware of secure coding practices, and are often making scripts to simplify and automate sysadmin activities. It is worth making sure your admins are aware of best practices when it comes to authenticating scripts.
Utilising A Privileged Access Management (PAM) system help to protect against cyberthreats by monitoring, detecting, and preventing unauthorised privileged access to critical resources. PAM works through a combination of people, processes, and technology and gives you visibility into who is using privileged accounts and what they are doing while they are logged in. Limiting the number of users who have access to administrative functions increases your security and helps mitigate breaches.
Reduce your Mean time to detect (MTTD)
We don’t currently know for sure how long the attacker was in Ubers network. Being able to detect breaches quickly is vital to being able to swiftly respond and recover from the breach.
Ensuring you have a well-managed SIEM solution will greatly improve your ability to detect breaches swiftly. Utilising features like User and Entity Behaviour Analytics (UEBA) will help you to detect users behaving in unusual ways.
Bolstering your detection capability further with deception technology is also a great idea. Utilising solutions such as the Thinkst Canary and Canary tokens allows you to place a series of tripwires across your network, both in terms of mimicking physical/virtual infrastructure and using small digital artefacts (like files or images).
At Flow, we have a consultative approach at the heart of what we do. Our team of experts will have an open and honest conversation with you to understand your strategic goals and specific organisational pain points.
Rely on us as your trusted advisor and make use of our expertise through our smart and agile advice.
