Thread by @BillDemirkapi

The Uber hack is quite severe and wide ranging. Wishing their blue teams the best of luck and love during this understandably difficult period. Some thoughts & observations based on what we've seen so far 👉 1/N

Let's talk about how they were compromised. The attacker has been quite upfront about how they compromised Uber's corporate infrastructure. Uber appears to use push notification MFA (Duo) for their employees. How can an attacker get around MFA? 2/N

An extremely common misconception people have with standard forms of MFA (push/touch/mobile) is that it prevents social engineering. Although MFA can protect against an attacker who only has the victim's credentials, it is commonly still vulnerable to MiTM attacks. 3/N

An attacker can setup a fake domain that relays Uber's real login page with tooling such as Evilginx. The only difference is the domain they are visiting, which is easy to miss. For most MFA, nothing stops the attacker from relaying the authentication process. 4/N

How does an organization even protect themselves against such an attack? For starters, using "phishing-resistant" forms of MFA, such as FIDO2, is an extremely effective measure against these social engineering attacks. 5/N fidoalliance.org/specs/u2f-spec…

Back to Uber, once the attacker compromised an employee, they appear to have used that victim's existing VPN access to pivot to the internal network. Internal infrastructure is often significantly less audited and evaluated compared to external infrastructure. 6/N

In this case, the attacker appears to have found an internal network share that contained scripts with privileged credentials, giving them the keys to the kingdom. They claim to have compromised Uber's Duo, OneLogin, AWS, and GSuite environments. 7/N

This story is still developing and these are some extreme claims, but there does appear to be evidence to support it. The attacker shared several screenshots of Uber's internal environment, including their GDrive, VCenter, sales metrics, Slack, and even their EDR portal. 8/N

Uber's AWS environment appears to be compromised as well. This screenshot of their IAM portal appears to show that the attacker has administrative access. If true, cloud access could not only include Uber's websites, but other critical internal services as well. 9/N

The fact that the attackers appear to have compromised an IR team member's account is worrisome. EDRs can bake in "backdoors" for IR, such as allowing IR teams to "shell into" employee machines (if enabled), potentially widening the attacker's access. 10/N sentinelone.com/blog/full-remo…

Some of these operations would require MFA again, which poses a problem. Attackers can create backdoor users with their own MFA or simply reset a victim's MFA- *if they have the appropriate access*. 11/N

The scope of this attack demonstrates another problem with centralizing authentication. It can often be a single point of failure that can give attackers a wide variety of access, as we've seen in this example. USE PHISHING RESISTANT MFA!! Stop making it easy for attackers. 12/N

This is not an Uber problem. The practices that led to their compromise are shockingly common. Vulnerable MFA is used everywhere, >60% of sites don't even support hardware tokens (src below). Internal infrastructure is often ripe with sensitive info. 13/N
elie.net/blog/security/…

This is an industry problem, Uber is only a symptom. We need to be working together to do better moving forward, rather than pointing fingers. Let the dust settle before we make any final conclusions. Interested to see what Uber shares to the public. 14/N

https://twitter.com/Uber_Comms/status/1570584747071639552

Some new information since last night. The attacker claims that they were able to gain persistent MFA access to their compromised accounts by social engineering the victims into accepting a prompt that allowed the attacker to register their own device for MFA. 15/N

MFA providers should *by default* automatically lock accounts out temporarily when too many prompts are sent in a short period of time. It's unclear whether that was used here, as Duo does claim that 10 failed attempts is the default for a lockout. 16/N help.duo.com/s/article/6726

A bad take I've seen is how wrong it was for there to be sensitive credentials unprotected in Uber's internal environment. This is not only very common, but I would put money on the fact that most Fortune 500 companies have the same problem in their corporate/dev networks. 17/N

A good way to combat this risk is to centralize key management and rotate them regularly. Require owners for every single access key to your org's environment. Limit the scope of these keys to the greatest extent possible. Require justification for privileged access. 18/N

We've gotten an update from Uber Comms. According to them, there is "no evidence" that the attackers got access to "sensitive" user data. Still only limited information, but I appreciate that they're trying to keep the public up-to-date. 19/N

https://twitter.com/Uber_Comms/status/1570829232246509569

That first sentence is sketchy, because "no evidence" could mean the attacker did have access, Uber just hasn't found evidence that the attacker *used* that access for "sensitive" user data. Explicitly saying "sensitive" user data rather than user data overall is also weird. 20/N

Uber has released a decent amount of details about the breach. Let's break it down. 21/N

https://twitter.com/Uber_Comms/status/1571920736167817220

Uber says that they were able to attribute the attack to the LAPSUS$ group. LAPSUS$ has been behind some notable breaches against orgs. like Nvidia and Okta. I posted some coverage of those breaches back in March when they occurred. 22/N

https://twitter.com/BillDemirkapi/status/1508527487655067660

Interestingly, Uber provides a slightly different story on how the breach occurred. Similar to the Okta breach in January, the attackers appear to have compromised the credentials of an *external* contractor. The attackers spammed MFA notifications until one was accepted. 23/N

Soon after compromising the contractor's account, Uber says that the attacker was able to pivot to several other employee accounts. The big question they don't seem to answer is how did these other employees get compromised in the first place? 24/N

It's also very interesting that the attacker compromised Uber's OpenDNS service. If the attackers were able to display a "graphic image" internally, I wonder if they could hijack the destination of any domain for those employees as well. 25/N

Uber discusses a high level overview of their response, including locking down compromised accounts and sensitive infrastructure. They additionally rotated several keys that the attacker may have compromised. 26/N

Uber again uses careful language to discuss what the attacker may have gotten access to. For example, they say that they have "not seen" the attacker accessing production infra., but do not clarify whether the attacker *could* access them in the first place. 27/N

Although Uber says the attacker did not gain access to any "customer or user data", they were careful to scope their statement to only include "cloud" data. They do verify the legitimacy of the previous screenshots around Slack and their finance tools however. 28/N

Although security reports were compromised, Uber claims that all of these vulnerabilities have been addressed. This does not mean that the vulnerabilities were fixed when the attacker accessed them- only at the time of publication. 29/N

Unlike Okta, another organization breached by LAPSUS$ who waited 2 months to tell the public, I commend Uber for providing these details so soon after the breach. I'm interested to see if Uber walks back any statements they've made once their investigation is completed. 30/N