Five Lessons Every Cybersecurity Team Can Learn from the Uber Incident

Upon hearing of a cybersecurity incident, alleged or factual, the most productive thing to do is learn what you can from its main lessons.

If you haven’t spent the recent week under a rock, you probably heard of the cybersecurity incident involving Uber.

Let’s start with an important disclaimer: Never believe anything without proper evidence (such as actual privileged data exfiltrated from hacked networks) and/or acknowledgment of the incident by the affected company. Anything that doesn’t meet either criterion is, in my book, cyber folklore; that is, not news.

The Uber incident story has been initially based mostly on a telegram chat, with the alleged attacker making claims and sharing screenshots. This kind of information should be taken with a grain of salt.

Judging by their media response, Uber seems to be taking the incident seriously and with a healthy corporate approach. This includes making statements — even as the investigation is still ongoing — about what the public would care about, such as:

First and foremost, we’ve not seen that the attacker accessed the production (i.e. public-facing) systems that power our apps; any user accounts; or the databases we use to store sensitive user information, like credit card numbers, user bank account info, or trip history.

Note that, since the investigation is still in process, the phrasing “we’ve not seen” doesn’t necessarily mean we can be confident it didn’t happen. It does mean, however, that their focus is definitely in the right place.

Uber has also shared information about effective measures they’ve taken to mitigate the risk from the exposure, the incident’s potential impact and the availability of their services. In general, from what we’re currently seeing, Uber should be commended for how they’re responding to the event. I’d like to take this opportunity to tell anyone using this incident to dump on Uber while they’re down to ease off.

This doesn’t help us as a community.

Patronizing Uber for their alleged mistakes is not only bad collegiality, it’s dangerous. Rather than analyzing the story for its takeaways, such critics are acting with hubris — and implying that they and their organization are above making such mistakes. I’ll save you the suspense — they’re not.

While other than what Uber themselves confirmed, we do not claim or assume the story to be true, we see several interesting takeaways from the story told, even if the details themselves don't reflect what exactly happened. Any organization looking to up its security game should take note.

In short, the attackers stated that they were able to social engineer their way to authenticating as one of Uber’s employees and access their VPN (which required MFA). They say they then scanned the network and found a powershell script containing a username and password for their privileged access management (PAM) solution which in turn allowed them access to a lot of very sensitive platforms.

For more information I recommend this X thread on the Uber incident by Bill Demirkapi.

So… what are the lessons that may be learned from this story?

1. MFA is not a security boundary

Many people tend to think that having multi-factor authentication (MFA) is hermetically effective against phishing and other types of social engineering attacks; this is not the case. MFA is simply a hardening practice. Its effectiveness depends on the kind of MFA you use and how well it’s implemented, and the security awareness of your users.

Of course, enforcing MFA is a highly recommended practice and makes the attacker’s job much more difficult. But MFA doesn’t stop all social engineering attacks — as sophisticated attackers can work their way around it. The circumventing of MFA to compromise an external contractor’s account is actually a part of the story that Uber confirmed in their latest update (19/9/2022):

Each time, the contractor received a two-factor login approval request, which initially blocked access. Eventually, however, the contractor accepted one, and the attacker successfully logged in.

While the specific method used to make this happen is not certain, methods such as real-time phishing that allow attackers to bypass MFA (or more specifically 2FA) are not new. They are essentially man in the middle (MITM) attacks. In such attacks, the attacker doesn’t only set up a fake console for credentials input (the way traditional phishing works) but also: 1) responds in real time to the credentials that are input into the fake site; 2) relays them to the original site they seek to access; and 3) relays the input back from the site so the victim thinks s/he is responding to factor challenges from the site they’re supposedly logging into. The simplest implementation of this is to input username/password credentials in real time to the site that the attacker wants to access. This will trigger a push notification and, at the same time, make the fake site prompt the victim to respond to the push notification.

In short, MFA is not a solution for countering lack of awareness. Of course, MFA enforcement isn’t effective at all with disgruntled employees or employees who, succumbing to financial or political incentives, have been corrupted by attackers. This brings us to our next lesson…

2. Effective security must be done in layers

You need to see account authentication as just one layer of security – and part of a multi-layered security approach.

Modern cybersecurity strategy should never be made of just one layer as any single control can be compromised. For effective security, you want to make the work of an attacker as difficult as possible — and for you to be able to detect and respond to the attacker's activity at as many links as possible along the cyber “Kill Chain” of the attacker's campaign.

For example, permissions (and specifically for sensitive files such as powershell scripts) should adhere to the principle of least privilege, and network access should be restricted as much as possible. Any activity such as network scanning should be prohibited, or at least monitored and responded to.

3. Avoid using static credentials

As we noted in a previous article on IAM user access keys in AWS, static credentials of any kind are bad news.

Static credentials are usually permanent credentials given in plaintext. They are extremely prone to manual errors (such as being shared publicly or even within a large enough distribution within an organization) that can cause them to leak or be available to be found by vigilant attackers.

Whenever you can, avoid using static credentials. If indeed you’re compelled to use them, treat them as if they were a loaded gun — with extreme care, and store and use them in secure storage (see more in lesson 4). Also, make sure the supply chain to that storage is extremely safe, rotate the keys regularly and track their usage as closely as possible.

4. Don’t hold sensitive information in plaintext

Any kind of sensitive information and, specifically, credentials (and, more so, credentials to privileged accounts or systems) should never be stored in plaintext.

Encryption of sensitive information is not just an important requirement of compliance standards and best practices; it functions as a security control that requires specific access — that should be given extremely carefully — to use cryptographic assets to access the data.

5. Security tools may be a double-edged sword

Some security tools, if misconfigured or misused, may actually be a single point of failure that creates serious risk.

For example, if a PAM solution that controls the access to very privileged accounts or systems is breached and allows an attacker to gain access to those systems, the solution can cause more damage than harm. Ironically, the solution will be allowing the attacker to achieve the very thing it’s meant to prevent.

Just like MFA, PAM is not a security boundary. However, PAM functions as a centralized place to store secrets (privileged credentials). If you can’t keep your secrets secure you most likely can't keep your PAM secrets secure either — and the PAM solution will become a single point of failure.

Security professionals need to be aware of the fact that, if not properly secured, security tools may bring more harm than value. Security teams must give special attention to the design and implementation of the security of controls that encapsulate such risk.

Conclusion

If you’re a cybersecurity professional or a cybersecurity vendor, your approach toward any report of a breach or incident should be as productive as possible, and you should strive to learn the most from it. In any case, and especially before a report is confirmed, try your best to avoid judging the victim as doing so may allow you to feel you have nothing to learn from their misfortune, which is usually not the case.

As trivial as the lessons we have reviewed here sound, you may be surprised to learn that many organizations actually get these things wrong.

Regardless of the folklore or facts behind the Uber incident, we hope you’ll use this post to make the most of the Uber story… and the next reported breach.

We send Uber our best wishes that this incident passes over with minimal if any damage - and that any lessons learned serve them and their platform to grow securely.