Risky Business - Risky Biz Soap Box: Preventing MFA reset attacks

Episode Date: October 12, 2023

Patrick Gray speaks to Yubico’s Jerrod Chong about how organisations can better verify the identities of users when performing MFA resets. In other words, how to not get MGM’d. He also talks about the chain-of-trust issues inherent to synchronisable passkey implementations.

Hey everyone and welcome to this Risky Biz Soapbox edition. My name's Patrick Gray and just so you know these Soapbox editions of the show are wholly sponsored and that means everyone you hear in one of these podcasts paid to be here. And today's Soapbox is with the President and COO of Yubico, Jared Chong. Yubico, as you know, makes hardware authenticators, Yubikeys. So if you want robust FIDO2 authentication, you know, real phishing resistant multi-factor auth, get yourself some Yubikeys.

We absolutely 100% endorse Yubikeys here at Risky Biz HQ. You should use them, at least for your highly privileged accounts, at a bare minimum. But, but, multi-factor authentication didn't help MGM Resorts, did it? In that case, you know, a teenager from the Scattered Spider group was able to socially engineer a help desk and trick the help desk into resetting MFA on an Okta super admin account. Ouch. And from there, they got ransomwared, you know, they're looking at a hundred million dollars worth of losses. So how can we stop that sort of thing from happening? You know, how can we sort of tie the identity piece to the multi-factor authentication

piece so that things like that don't happen? Here's Jared Chong to tell us how. The reset is really part of the entire life cycle of the user. So if you don't look holistically of how you onboard the user, how you recover slash reset, and then how you offboard the user, you're going to run into some major issues. First off, MFA is not there to solve identifying the user. That's not what it's built for. In fact, if you think that is, then we have a big issue, which we do have sort of today in industry, where nobody wants to talk about how you got the MFA enabled. Oh, I've got the best MFA. Yes, I'm super strong now. My front door is super, super, super strong. And then, well, what happens if you come in from the side door or the back door

of the house? Well, okay, well well then that's someone else's problem. So I think the first thing to acknowledge is that as industry, we haven't done a great job thinking holistically, how do you enable the MFA process? You can have the best MFA today, which is FIDO2, passwordless, but how are you going to enable that when you have new users coming in

or users that get locked out for whatever reason if the answer is well let's just send them a new sms code to turn it on all over again or here's a temporary passcode and start the whole journey again which in all fairness is pretty usable right like you can get back in pretty quickly yeah but then what's the point what's the point of 502 when everything hinges on an sms reset right like exactly yeah and if it's easy for you to reset for those users or even super admin users it's super easy to be attacked as well and i think that's where i think many organizations fail to realize if it's so usable to just get back mfa strong mfa it's super easy to target the same account because you can do it at scale remotely.

Yeah. I mean, our joke, our running joke recently on the show is that in order for Okta to, in order for you to remove MFA from a super admin account in an Okta tenant, you know, you should have to send the administrator to an Okta office for DNA sequencing. But what is the realistic way that you can start chipping away at this problem? I think acknowledging that we need to strengthen the entire recovery process and even the step-up process is really critical. So one of the things actually we're pretty excited to talk about, we are launching in at Octane, which is the Okta yearly conference, is a new way to onboard a user for strong MFA. We're calling it FIDO pre-registration because essentially what we're doing is to pre-provision a FIDO credential for the user and actually send it to the user's physical home address. Now you could say, well, that seems like I can just go stand in front of the mailbox

and try to get that YubiKey. Sure. But if you can think about the scale of this thing, then every attack has to be a physical attack, which really inhibits how attackers think about it. It definitely makes it harder when you actually have to have an attacker staking out the house waiting for the delivery driver. Yeah, that makes it somewhat harder. Somewhat harder. And also we have the notion that you can also separate the pin.

So even if you've got the device and if you don't have the pin, so it's a different form of communication to get the pin. Then even if you've got the pin, you don't have the device. If you've got the device, you don't have the pin. You can't actually use the authenticator. So we have many ways that we can improve the current state. What we want to move away from is to enable onboarding or reset with a password. That's what we want to avoid. How would you distribute the PIN?

I think many organizations have different methodologies to share confidential information just like how you share HR information you validate you know certain parts of the organization's employees personal items maybe it's a date of birth and you have all these systems you can either do it through the HR system you can do it over email you can do it for many different forms you can even call up your manager and say what's my pin So we don't want to dictate how people get the second form of that phase to do authentication. We should leave it up to the organization. But the point is that it's going to be out of band and it's not going to be the complete thing because you've got now multiple factors for your multiple factor, right? Which is your PIN and your actual device. device correct and industry has already solved this with credit cards right you have your credit card and they say i want

my pin to use it as some atm device it says well we got to wait for the mail to get the other envelope with the pin on it so today we've already solved you can obviously solve it with another physical delivery or you can solve it with an electronic delivery or even a phone call yeah now the issue with social engineering around all of this stuff too is that what you've described seems like a great idea, right? So, an attacker rings a help desk posing as Sally Smith and says, hey, I need my MFA reset. And they say, okay, Sally, we've sent a request to reprovision you with MFA the problem with social engineering though is that this pretend Sally is going to jump up and down and say no no no you

don't understand it's absolutely critical that I get back into my accounts and whatever so so I guess what I'm saying is like this service is only as useful as still only as useful as companies procedures around actually adhering to it. Do you think the message is getting through to executives that they need to actually have quite strict controls on this stuff, at least for admin level accounts? I don't think every executive knows this problem statement well. I think we've been talking about it for a while. You've been talking on your show. I don't think this is quite obvious to the organization. A lot of organizations are like, what's the problem? I've already turned on MFA. Why am I getting breached? So I don't think this is quite obvious to the organization. A lot of organizations are like, what's the problem? I've already turned on MFA.

Why am I getting breached? So I think the message has to start wider, which is, yes, you have turned on MFA, but how did you turn on the MFA? And most of the time, I would say that even security folks are quite surprised on how they turn on MFA. Yeah, exactly right. Because it's, I mean, it's really ad hoc, isn't it? It's like magic. It's like magic, Patrick. Like I've got MFA is magic. Someone just turned it

on for me and I, and it worked or they remember, and they remembered it really painfully. Right. Like I got like three SMS, I couldn't receive it. I keep clicking resend code 10 times. And then I finally got onboarded and then, then I finally turned MSMS. And I said, why do I even want to do that? So I think people either have a poor experience turning on MFA or they don't even know how it was turned on. They don't know what the process is, right? Yeah, exactly. So, I mean, how do you handle address changes when it comes to sending these devices out? Like what if someone rings up and tries to socially engineer the help desk and says, well, you can't tell Yubico

to send me a YubiKey to my address because that's an old address. It's changed. My new address is XYZ. Like how do you prevent that vector? Yeah, I think that's common for any delivery system, any delivery situation. I think people will have changed address.

So we need to have policies around that. A lot of the guidance are going to be what does the organization want to do if a caller says, I'm a super admin, I've changed my addresses, I've changed my email, like all the reflection come up, right? So even if you change the address in this scenario here, this attack scenario, you kind of still need to get to the out-of-band pin. And so the system needs to say, hey, this person changed the address,

also changed the email, and also changed whatever, right? The phone number. And everything is being reset. So we're back to this reset situation again. But you have to solve all three things. You've got to change not just the physical address, you've got to change where the pin is going to be delivered.

You maybe have to know the manager and trick the manager. Then you're also going to have to change your phone number. There's a bunch of things you've got to change. The problem is attackers are doing this level of stuff, right? So if they get malware onto a device and they steal some sort of session token, bam, they're in the email. At that point, they know the phone number. And then they're just a trip to a T-Mobile store in some mall in the burbs.

And they've got that OTP as well. So, you know, I guess what, you know, we're kind of back to that problem, right? Which is how do you then make these procedures completely robust, right? And it's not easy. I mean, you're gonna- Not easy, not easy at all. Just a question, right?

Like if you want to change the address for a user, is that something your customer does or they have to go to you? I'm guessing that's something the customer does, right? That's the customer does. So one of the things that we work with with organizations is that there needs to be a source of truth. It needs to be in the HR system. So if you change your address, it needs to be documented.

It needs to be validated, right? So we're not in the business of policing people's addresses. Certainly not. So whatever the source of truth from the HR system is going to be, and you have to make some decisions based on that, right? We can't say everybody, for example, if the payroll information changes the addresses and also change the email and so on and so forth, it's not just that the attack is going gonna happen for the individual with MFA, like they may lose their paycheck. So at some point you gotta say,

if the payroll system is correct, then you have to trust the payroll system. And for most people, that's pretty guarded. That's pretty tight in general, right? So people can't just say, oh, just change the bank accounts of my payroll because I'm working in this other place and I want a new bank account. The level of scrutiny for changing the bank wires and all these things are much higher.

But it's not for address, right? And I guess where you're going with this is that maybe they need to, is that HR departments are used to applying scrutiny to certain changes. So maybe they need to start treating address information the same way that they treat banking information. Exactly. Yeah. So would you suggest that's like they have to present themselves at a physical location, get sign off from their immediate manager, show some ID, that sort of thing? Whatever the process is that the organization feels comfortable. And again, for super admins, I would think that you need to come to the office

to some level, right? I mean, like if the kings to the kingdom is like one person or two or three people if they want to reset mfa it got to be really hard because if it's easy again then obviously the attackers are going to go the easy path yeah i mean what you just told me about like you know plumbing this through to the hr systems and making that ground truth that is how you would do this is anyone actually doing that though yet or is this just you're in the very early stages of selling this as a way to do it we are in the early stages of stitching together everything this is not a new idea by any means i think being able to execute it at scale that's what we're talking about obviously we're working with octa we're working with others to say how can we bring this to light and the big thing for us is like you said if we don't solve this, MFA adoption will actually stall.

We will literally stall. I would think we'll go backwards. So to solve the adoption problem... Why? Because people will become apathetic and say, what's the point? Yeah, what's the point? If I turn on the best MFA and I still get breached, then why am I doing this thing? So we really need to take a serious look about account lifecycle account life cycle which is what we this is about and by the way in very highly regulated environments or restricted environments or highly sensitive

government environments this is the way it is if you want to get back on the army base because you lost your badge you're showing up at the army base you're not getting some remote badge hey i'm here yeah it's not some teenager ringing them up and saying can you send a new one to this uh to this post office box, please? Exactly. So at some level, if you want the best scrutiny, it's in-person verification and obviously a hardware-bound authenticator, right?

It's really like two physical things. As you know, I think one of the big threats, we didn't talk about it previously, is deepfakes are going to be like a real thing right now and so when we depend on remote idv as the baseline to say oh we can you're saying don't even trust zoom oh my god like you tell me yeah it's over time let's just talk about it in two three years from now and i could be someone else i don't know but you could be someone else i mean this these are real attacks happening, right?

So to do remote IDV with defects is not that far away. Yeah. Yeah, that's interesting now Look earlier. I mentioned that you know B2C is a completely kind of different ballgame Because you know, I mean I learned this by knowing Alex Damos who was see CISO for Facebook for a while. And you start talking to him about like the types of devices that people log into Facebook from. And you look at that on a global scale and just the number of weird, old, insecure devices and places with unreliable telco infrastructure, like just absolutely insane at scale, right? But where I think there's some hope for the B2C side of things is with passkeys. Now, you and I, when we first spoke about passkeys, and of course, passkeys, for those who are not OFA,

is a FIDO2 web auth and implementation that is supported by Android and iOS, and it works brilliantly, and it's fantastic. It's like a virtual YubiKey kind of tied to the trusted platform module on your mobile device. I probably just butchered that explanation, but that's basically what it is, right? And yeah, it works brilliantly.

Now, when we first spoke about that, I'm like, oh, you know, you must be worried that it's competition. It's not really. I mean, like everything that you said at the time is kind of right, which is like, oh, you know, you must be worried that it's competition. It's not really. I mean, like everything that you said at the time is kind of right, which is like they have a role, but, you know, for that high assurance enterprise use case, that's not really what it is. And, you know, you were absolutely right on that. But we are seeing it starting to get a bit of traction in the consumer space. Now that it's been a little while, is that how you see it? Which is that YubiKeys are your enterprise thing

and PassKeys are more for sort of B2C services that have millions of users? I think it's both. I do don't think that PassKeys come to use in enterprise. I think in certain scenarios you can be. But I also don't think that PassKeys is only limited to just syncable passkeys so maybe to clarify the definition for your audience passkeys is a new way that the fido alliance has renamed a passwordless credential of web.en so it's just a passwordless credential fido essentially, essentially. Password slash passkeys, get it? Like passkeys is like not using passwords.

So that's a simple way to think about it. So if you want to use a passwordless credential, you can certainly use it on a mobile phone, sync to the cloud like Google or Apple, or you can use a passkey credential on a YubiKey, which then you are bound to the hardware. So in terms of passkeys itself, the technology is independent of where it's stored on. Okay, yeah, right. credential on a YubiKey, which then you are bound to the hardware. So in terms of pass keys itself,

the technology is independent of where it's stored on. Okay. Yeah. Right. So you can actually, like all of the pass key plumbing, you can use that with a YubiKey as well. Correct. I think the main difference is the user's journey. How do you envision yourself using the technology? If you're constantly going to be cross, I guess, platform, cross cloud provider, it may not be the best option to constantly change passkey provider. That's what they call it, passkey provider being, you know, Apple or Google or Microsoft or whoever. You want to route your baseline to something that you can trust. And so a lot of users, independent whether they are enterprise or for consumers, if they want to route it around a YubiKey and then they can port the YubiKey and enable other passkey providers, that's one way to look at it. Or you can say, well,

in this scenario, I absolutely cannot have syncable credentials. I can only have hardware bound credentials. And then you limit it to, you know, maybe a set of services that you use your hardware bound YubiKeys to. So I don't think it's clear whether everyone can use passkey single ball. Everyone has to use hardware bound. I think the evolution is continuing. There are some still generally challenges.

So you don't think passkeys is just going to own B2C. You think there's still going to be some hardware keys in B2C applications as well?c you think there's still going to be some hardware keys in b2c applications as well absolutely and yeah there's some there's one simple reason you just mentioned to yourself a lot of the pass key syncable implementation requires you to have the latest phones and os yeah this is not really fair to an you know to an organizational user this is you know what my iphone still works just because i can't get the latest os i can't use this technology seems like a little bit off so is everything else i think if you have to

think about an entire population they're going to be users that may want to use phones or may not want to use phones they have different types of phones so just because you have pass keys that work on later doesn't mean everyone can use it which is a general problem equity problem that we in the western world think everybody will gravitate and have the latest ios 15 i mean this is this is what i was getting at with my conversations with uh starmos you know is he's like come on man like most of the world is on ancient tech you know yeah and so that's it takes a while it takes probably a decade for everyone to get something that can support it. And so we have to look for multiple ways to solve the same problem now and not wait 10 years before everybody has the latest phone or something like that. And I think that's where we need to work together with industry to say, how can this

better together story work rather than, you know, hardware versus non-hardware. There's another issue though with passkeys that's a big one. So if I'm using a YubiKey, you know, to validate myself to a service, yes, someone may socially engineer that service, especially if it's a B2C service. Someone may socially engineer that service to remove my MFA and my protection is undermined. That is something that can happen. The problem with passkeys is they are syncable. You can synchronize them through your cloud-based account. So, you know, I'm an Apple user. So in my iCloud account, if someone gets my iCloud account, they get my passkeys. And that doesn't mean that they've just

got one of my services. That means they get all of them. Now, obviously, there's going to be some protections and whatnot. Apple's pretty good at thinking about these things holistically, but there is still a risk with any sort of syncable service that you're going to have an issue like that. We did actually just see a case in the wild where a threat actor obtained access to a gmail account and used that to obtain all of the uh seed phrases sorry all of the seed values

for the um google authenticator for that user and then went off and owned absolutely everything and that's because you know google made authenticator syncable which i think is actually the right call because for anyone who's ever had to um migrate authenticated from one phone to another like it was a it was a nightmare so you know that had to happen uh but it was a nightmare but you know again we're kind of going back to that same problem which is pass keys are only as good as the reset procedures around them for when you lose your phone you lose your password to the account or whatever you need to get back in by talking to a help desk there you go you you come rinse and repeat and we're back to the beginning of the

session again and as good as apple's procedures might be for someone like me who has multiple apple products right they can build some procedures around that to make sure it's not someone just trying to steal my account but if you are a sole you know if you're if you're an iphone user with an apple icloud account that's only bound to one device and then you you know, if you're an iPhone user with an Apple iCloud account that's only bound to one device, and then you, you know, someone says, oh, well, I lost my device. I need to get back into my iCloud account. And obviously I can't remember my password. Like that's a hard problem for Apple to solve. It's a hard problem to solve. And I think the goal is that they want to sell you a lot of devices. So then you won't have this problem. But, you know, there's going

to be a lot of people out there where that's the scenario, right? Where the iCloud account is just bound to one device and then that's, you know. Yeah, I mean, also to be fair, with this iCloud accounts, if you look at it, I mean, it's pretty common for a business user to have an iPhone, a Windows machine, and then a tablet, you know, a Samsung tablet.

This is a very common scenario. So this doesn't solve the Apple ecosystem problem, or the Apple ecosystem doesn't solve this problem. And so no one cloud provider can say, I've controlled all your devices, and therefore I make it so easy to make it secure. Because the way that you have to solve this, you have to own all devices of the same type from one company, and then go to the same cloud scenario for recovery, then it's fairly robust, I would say. But once you have a mixed mode,

like all bets are off. Yeah, yeah. So, I mean, you've talked about how companies can, to a degree, have some policies around this that largely solve the problem. I mean, they're difficult policies to implement, right? Like if you're going to go, the CISO going to talk to the HR director

and saying, you need to do this. HR director is not really going to like it. You know, let's be honest, right? Like, so there's going to be a lot of infighting and a lot of drama to make, you know, so I'm not saying they're easy, but they are some solutions, right? That will get you a long way,

that will protect you uh from these things but when it comes to stuff like the b2c's whether that's facebook in the case of you know a single credential or whether that's google or apple in the case of managing people's passkey synchronization you know where's the solution for this at scale going to be you know where's the equivalent of the HR department where you can go and you know reset an account you know what's the future of that going to look like I mean there's a lot of talk of future things I'm not going to speculate I mean obviously everybody wants to gravitate to some type of decentralized identity I think that's really far away I think the short-term scenario is education.

I think we need as users to be informed, whether ourselves, our peers, our parents, and so on and so forth, our schools, the risk profile. What are you getting yourself into? It's back to the first conversation that you asked me. So how do we get executives at a company to take action? I think at some point, users need to take some ownership of their digital life, so to

speak. You do a lot of things to enhance your physical being as a human being. I think you kind of need to do your digital education and clean it up yourself as well. And I think we're still missing a lot of baseline education in schools and universities and all the places that you can actually educate properly what it means to do a certain type of digital action. And MFA is one of those things. How do you turn it on? Why should you turn it on? What are the risks involved? Why should you turn on MFA for certain accounts? These are very basic things that I don't think it's well understood by the masses.

I mean, you know, we used to talk even 20 years ago, we used to talk about this future of federated identity and that we would have consumer facing identity providers. I mean, for a while in Australia, I think the post office was, you know, because it has points of presence everywhere. It was looking at becoming one of these identity providers. And it's great. Like, but as I say, we've been talking about it for 20 years. I mean, I do kind of wonder now that that sort of plumbing is easier. I do wonder like why my bank doesn't offer to offer some sort of identity attestation service for me. But, you know, am I going to pay for that?

Who's going to pay for that, right? Like, I think that's kind of where it falls down, this whole old idea of federated identity providers. You know, where it falls down is like, who's going to pay for it? Do you think that's why it hasn't quite got there? Or do you think there's another reason? I think there's a number of reasons. So one area that we've been investing in, actually, there's actually quite a lot of development in the EU space. We're actually working on, together with several partners in the EU ID wallet space, which is a little bit

tangential, but similar, which essentially says, you know what, I want to work with a service, I need proper attestation, and then I'm only going to allow the service to get whatever the attribute is going to be, and you need to do it securely. So there's a number of these things that can be done. But to answer your question at scale, I think before we have the whole world doing it, I think several regions or governments should take some lead to say this can be done at a national level first. And then we can say, can this apply to all nations, most nations or

none? Then we're going to make progress. I think we've done a lot of work with the US government, but that's still very slow. The technology is, this is not a technology problem at the end of the day. Like you said, process and procedures are very controversial sometimes. But governments can step up and say, this is the way that we want to work for citizens and then start to expand. Some countries have done that because every time I say,

oh, why don't we have this? I always get someone writing in from, I don't know, Estonia. I can't remember if it was Estonia. But we have this. I'm just wondering, when we, you know, I do understand that some countries do have trusted identity providers, sometimes administered by the government, but when does this become standardized?

When does this become uniform? When can I OAuth from my government provided ID or my bank provided ID into my consumer services, right? Because then everything's going to get a lot easier. And I mean, this even goes a long way towards solving the enterprise use cases as well, right? The enterprise challenges. Yeah, I think there's a lot of people work on it, to be fair.

I think getting it to something that can be adopted quite uniformly is always challenging. There's always politics in the middle there. There are no shortage of technologists that wants to solve this problem. We are part of, you know, in different working groups. Ultimately, it takes more than one country

to solve this. It takes several countries and even the whole EU or something like that to really make a huge movement because then you represent a larger swath of the population. Because if it's just one set of users,

then people say, you can do it there, but we can't do it here. That's sort of that argument. And you know that if the US government tried to implement this, people would start calling it the mark of the beast or something and rail against it. Yeah. And I think there are some merits to that. Privacy is a big issue. Over time, I think we do need to think about privacy, which is the baseline with how we operate. So I do agree that it needs to be larger than one country and some countries are certainly much harder than other countries so it needs to be opt-in as well right because you know the i think that's what you're getting at

is that objections to like a giant national database are not entirely would not entirely be unfounded right i mean the government needs to police it. Like you can't just have anyone use any credential and ask for anything. You know, like if you want to buy like candy from a candy store, I shouldn't like know your driver's license. I should just know you are over the age of X to get this product, right?

So there's a lot that needs to be done to actually provide the proper level of service to not disclose too much, which is where we are right now. Like everything is collected, like you have no choice. Like once you sign up to one of the cloud providers, like you're giving everything, everything recorded, sent, whatever. And that is generally a problem. So the data collection to evaluate later in time is a big problem for the whole world. Yeah. I mean, this is why I wonder if it can't be something, you know, more tied to banks, right?

Who are already doing a high level of identity checking. That's why I just feel like it's the right place for it to go. You know, just like the HR case in enterprise that you were talking about. Yeah, but not all banks are created equal too, so. Yeah, well, that's true, right? Because I say this based in a country where we basically have four large banks

that are very good at what they do. And in certain other countries, there's a million little credit unions run by, in some cases, families, right? Yeah, exactly. That's a different sort of scenario. Now, look, just quickly, Yubico is now publicly traded.

Did you IPO? How did that happen? Because I didn't hear anything about a Ubico IPO, but apparently now you're publicly traded. We are publicly traded. We are listed in the NASDAQ, first NASDAQ Stockholm exchange. And the main reason for that is our key investors are in Sweden.

So we actually listed there. We didn't have a big listing in the US for a number of reasons. But we did actually have a billboard in New York Times Square, which is pretty exciting. When did you... So this was actually an IPO? Three weeks ago, it was actually a SPAC listing. But the SPAC...

Okay, that's what I was wondering. Yeah, the SP spec listing was our core investors so for all intents and purposes it's actually operating the same it's just that they decide to okay now let's bring the company public we've invested in a company for like almost six years now so why not make this longer term so that was what we did and it really sets the charter for us to be able to scale better i would say and do the things that we want to do being an independent organization let's wrap it up there now jared um look it's always great to check in with you uh every year and find out you know what what's on

your mind what the latest thing is over at ubico uh fascinating chat as always and uh we'll do it again next year thank you you very much, Patrick. That was Gerard Chong of Yubico there and you can find them at yubico.com. Big thanks to them for that. And again, we absolutely 100% happily hand on heart endorse Yubikeys. I personally use one and I love it. But that is it for this edition of the Soapbox podcast. I do hope you enjoyed it. I'll be back with some more security news and analysis soon. But until then, I've been Patrick Gray. Thanks for listening.