Root Causes 247: Uber Breach Unpacked

Hosted by

Tim Callan

Chief Compliance Officer

Jason Soroko

Fellow

Original broadcast date

October 13, 2022

A recent high-profile breach of Uber's systems led to widespread data loss. Join our experts as we unpack the specifics of how this attack came about.

Podcast Transcript

Lightly edited for flow and brevity.

Tim CallanSo we want to talk about a recently broken news story. It actually comes from I think it was September 14 or September 15, something in that ballpark and this has to do with a breach that occurred at Uber. So, there appears to be a pretty widespread and deep compromise of Uber systems and sometimes with these breaches we know very little but, in this case, the community seems to know a pretty good amount.

Jason SorokoThis is surprising. A lot of times when we are asked to review, hey, what was the root causes here? What happened? A lot of times we just don’t know and we’ve got to wait for lengthy reports. This kind of came out quickly and some pretty good journalism by New York Times and others. Tim, we were very recently just talking about some of the root causes to this and we were reminiscing about just how common this is and, in fact, we did podcasts on some of these topics very recently. Let’s call them out, Tim.

I’ll read them out and maybe you can give some color here but, obviously, there is a chain of attacks. Well, I shouldn’t say there’s no such thing but it’s quite rare for an attacker just to do one thing and there’s a hack. This isn’t Hollywood movies. There’s typically several steps that an attacker needs to make and the initial move, the initial move, was probably some reconnaissance but really the initial move in and the initial thing that caused a stealing of a credential was social engineering.

Tim CallanThe initial ingress was social engineering. It appears that somebody was tricked through repeated contacts. A user was tricked through repeated contacts into believing that they were dealing with I think it was the internal IT team inside of Uber and their MFA was defeated by a relay page. So, they actually thought they were doing the right thing. They actually used their one-time passcode and it didn’t matter because they were giving it to somebody who wasn’t the real somebody.

Jason SorokoWe talked about that not that long ago. So, we’ve been talking about the weaknesses of username and password almost since day one of this podcast and we have increasingly become sour on weak MFA. And, in fact, I think it wasn’t that long ago that you and I talked about a Brian Krebs story that actually called weaker MFA actually a liability in enterprises.

Tim CallanWe did. Very recently.

Jason SorokoAnd so here is a perfect example of weak MFA being a liability to Uber and, once again, let’s just spend the moment explaining it that if you are presented with a malicious page, web page, for example - it’s a page that shows up in your web browser, and you get to it because you’ve been shown a link or you were sent a text message with a URL – whatever it happens to be. Wherever that comes from the social engineering. If you think that that’s your internal IT department and they’ve asked you to log into a page with credentials that if they were shared outside could lead to somebody inside that shouldn’t be, most people are thinking, well, I’m entering my user name; I’m entering my password and I’m taught to enter my one-time passcode that’s given to me through my multifactor authentication system of choice.

Tim CallanI think that’s a great point, Jay. Like, on one hand when these social engineering attacks occur you always think, well, ok, a human got duped. But, on the other hand, let’s give this poor person some credit. Like they thought they were doing all the right things. They were following the process they normally need to follow and they believed that they were using MFA to ensure that it wasn’t a phishing attack. And so within the limits of non-security professionals you could argue this person did the right thing.

Jason SorokoThey’ve been trained to do exactly what they did and that training and that extra step, it naturally gives you some sense of well, I’m doing the right thing and therefore I must be safer because I’m being asked to do the right thing. And I’m doing the right thing. I’m doing exactly what I was trained to do and what I have to say to you all is whenever you enter a username and you enter a password and then you are challenged for a one-time passcode and then you type that one-time passcode into whatever system that you are using, you have just given away that information to something. You’ve got to cross your fingers that you gave it away to the legit system that is challenging you to log in because any notion that that one-time passcode is time-limited and therefore it is difficult to use by the bad guy, I think now we’ve seen enough examples of this that this problem of fake relay pages or whatever you want to call them credential harvesting pages which are always associated with some form of social engineering, you’ve given away the keys to the kingdom. You’ve given away sufficient information of the credential in order that you have handed over privileges and it should make you a little bit paranoid to realize not everybody is safe and that’s why Brian Krebs used that word. It’s a liability because you’ve now trained people to think that they’re safe and they are not and that ultimately has led you to a lesser situation in terms of security and we need to address that as an industry.

Tim CallanNow, the next point is – and I don’t know if zero trust is quite fair but there definitely was a zero trust-ish situation going inside there where the person whose credentials were harvested did not really have the privileges they needed to create the widespread damage that occurred.

So, this isn’t like the old days. I don’t know if you remember once upon a time there were these breaches and someone would get through the perimeter and it was just an open field. Free and they could go wherever they want. That’s not the case. Like they had the right sort of access control in place. The problem was once the user got inside or once the attacker, I should say, got inside they then found additional credentials that were available for harvesting that were stronger than the original credentials that they had.

Jason SorokoYes. And let’s call it out because, again, it’s surprising for this amount of information to have been made public so quickly but it was published and we can talk about it. For those of you who know about it, PowerShell is a system especially within Microsoft but PowerShell can be implemented in a number of places but it ultimately points to a Microsoft stack of technology and typically used by internal IT people in order to do all kinds of IT maintenance and manipulation. You can make Windows sing and dance with PowerShell. It’s an amazing system. And so, PowerShell requires scripts in order to run. Forms of code, if you will. And, unfortunately, there are best practices with respect to how you use PowerShell because PowerShell obviously can log into other systems. That’s part of its power. The problem is that the credentials were hardcoded into this PowerShell script and I think, Tim, to go beyond that there is some debate as to whether or not they were following best practices but those best practices need to be improved. I will stop short of going into that conversation. But the fact remains that we still hear about hardcoded credentials or weak or not best practices being used as part of keeping your secrets secret. I’m gonna throw this to you now, Tim, by wrapping up those two big root causes and say to you, usernames and passwords, and even include MFA, could this have been done better? Could this be avoided with different authentication schemes? That’s the question.

Tim CallanAnd I’ll go a step further. I think there is a strong argument to be made that as long as you are basing this on the kind of access on username and password or some kind of other similar shared secret, regardless of what sort of MFA systems you are putting in place, you never entirely eliminate the vulnerability for what you saw here in this attack. Like you just can’t take that level of exposure down to zero. It’s built into the authentication system.

Jason SorokoSo, think about what you just said, Tim. I’m reflecting on it. If I’m CISO, Director of IT type of person and, I’m not as big as Uber in terms of operations but I’m thinking about this and I want to avoid this, you probably as a professional have thought about I know username and passwords are a problem but I’m gonna implement a control – MFA. I know that it’s a very bad idea to give everybody in my organization administrative rights so I’m gonna start creating GPOs. Policies. And I’m gonna create network boundaries and I’m gonna do a bunch of things and maybe you’ve done all of those things and who knows because it wasn’t that long ago where those things were still new ideas.

And here, Tim, this is why we are calling this out – none of that was enough.

Tim CallanThat’s my point. Thank you, Jay, for articulating that so well and so clearly that they did all of these things that you would look down a list and say these are the right things to do and to your point, the basic exposure, the basic vulnerability not only was still there but it was exploited and it was exploited pretty badly.

Jason SorokoThat’s right, Tim. I think that, obviously code reviews even of your PowerShell scripts, there are now tools out there, Tim, that are just quick and dirty looking for credentials in scripts. Maybe in your organization maybe that’s sufficient to defeat this but the wider point we are making is at the heart of the matter here is weak authentication.

And I think that, yes, there’s a number of things you could do. You could go off and scrub review code but are you ever gonna find everything? Well, question mark. But if you completely rethink how you do authentication – obviously, for legacy systems, you gotta think about those things about maybe isolating them more or monitoring them in a different way. But for any kind of systems, especially modern systems that Uber might have been using or that you are using, hey, using client certificates for authentication goes a long way to defeating. You can’t share that credential, Tim.

Look, I’ve been in this industry a long time. So have you. Tim, do you feel completely immune to social engineering? I don’t.

Tim CallanI do not. I agree. Like I said, that person who fell for that, I think many people would have.

Jason SorokoAnd so, therefore, I think you almost have to use human-proof, process-proof methods that don’t rely on layers of controls. I’m a big believer in layered security. Redundancy is important. And layers are great because it make life difficult for the attacker. But if you really want to make life difficult for the attacker, maybe we should really start rethinking about the kinds of locks we put on our doors because right now they’re very pickable.

Stay informed with expert insights

Subscribe to Root Causes for engaging discussions on PKI, digital security, and best practices for protecting your organization's critical assets. Don’t miss an episode!