Transcription

Tom

Hi, there. I'm Tom Field, I'm Senior Vice President of Editorial with Information Security Media Group. I am delighted to welcome you to today's session entitled, "Why You Have an MFA emergency on Your Hands and What To Do About It." We got a trio of panelists for you today. They include Jasson Casey, Chief Technology Officer with Beyond Identity, Roger Grimes, Data-Driven Defense Evangelist with KnowBe4, and Patrick McBride, Chief Marketing Officer with Beyond Identity. 

Before I bring this trio onto the stage, I'll give you a little bit of background on our conversation today. MFA blocks 99% of attacks until it doesn't. An outdated MFA is a clear and present danger. In this session, we're going to enumerate the multiple vulnerabilities with existing phishable MFA and the TTPs that hackers are employing to bypass the MFA that nearly all organizations are using today. 

So, we're going to explore three common types of MFA bypass attacks, we'll define key technical requirements from modern phishing-resistant MFA, talk about NIST standards to focus on MFA deployment. First, a little bit about my organization, Information Security Media Group. We're a global education and intelligence firm. 

We're based in the U.S. in Princeton, New Jersey. You may know us, of course, by one or more of our media properties, we've got 34 of them. They include "Bank Info Security," "Gov Info Security," and "Data Breach Today." In all, we reach an audience of over 1 million security leaders globally and we give them a daily diet of news, analysis, research, events, and educational programs just like this one. 

As always, a few notes of housekeeping. One, if you have any questions for our panelists, you can submit them any time by the chat window on your screen. Now, I may not be able to get to every question over the course of this session. But for those questions we don't answer today, we'll get responses back to you via email. Important, should you encounter any technical issues while viewing today's webinar, take down that email address you see on your screen. 

If you write to webinars@ismg.io, we've got support staff standing by to help. As always, a reminder, today's webinar is copyrighted material. That means is meant for today's session in individual study purposes only. If you'd like to use any of the information presented today or if you're looking for customized training materials, please contact us. 

I'm delighted to introduce our sponsors today beginning with Beyond Identity. Beyond Identity is fundamentally changing how the world logs in with a groundbreaking invisible phishing-resistant MFA platform that provides the most secure and frictionless authentication on the planet. They stop ransomware and account takeover attacks in their tracks and dramatically improve the user experience. 

Beyond Identity's state-of-the-art platform eliminates passwords and other phishable factors, enabling organizations to confidently validate users' identities. This solution ensures users log in from authorized devices and that every device meets the security policy requirements during login and continuously after that. The revolutionary approach empowers zero trust by cryptographically binding the user's identity to their devices and analyzing hundreds of risk signals on an ongoing basis. 

The company's advanced risk policy engine enables organizations to implement foundationally secure authentication and utilize risk signals for protection rather than just for detection and response. To learn more, please visit beyondidentity.com. KnowBe4 is the world's most popular integrated platform for security awareness training combined with simulated phishing attacks. 

They help thousands of organizations to manage the continuing problem of social engineering. Their mission, train your employees to make smarter security decisions. Quickly, let's meet our panel. Jasson Casey, Chief Technology Officer for Beyond Identity has served as CTO of SecurityScorecard, VP of Engineering at IronNet Cybersecurity, Founder and Executive Director of Flowgrammable as well as Compiled Networks, VP of VoIP Product Development at CenturyTel, among other technical and executive roles. 

Roger Grimes, KnowBe4's Data-Driven Defense Evangelist is a 30-year computer security consultant, instructor, holder of dozens of computer certifications, and award-winning author of more than 13 books and more than 1,000 magazine articles on computer security. And Patrick McBride, Chief Marketing Officer of Beyond Identity has served as CMO of ZeroFOX and Claroty, as VP of Marketing at iSIGHT Partners and Xceedium, VP of Compliance at Scalable Software, Co-Founder and CEO of META Security Group, and Senior Vice President at META group. 

With that, I will turn you over now to our very able trio of experts. Gentlemen, the virtual stage is yours. 

Patrick

Thanks so much, Tom. Let me get our presentation up here. Well, we thought we'd start this off talking with Roger and giving a little bit of perspective on this. We're delighted to have Roger on this call, not only because he's just great to talk to, but he literally wrote the book on hacking MFA and we'll have a little bit more on that in a second. 

But these are the topics that we're going to go through. We'll start, like I said, with Roger try to answer some of these questions as we go through, but let's just jump right into it. So, we started off in the intro, Roger, with the idea that MFA blocks 99% of attacks. Do you want to want to give us a little color on that? 

I know that's a favorite topic of yours. 

Roger

I like to start with saying that MFA does not block 99% of attacks. What happened is that a couple of vendors, Google and Microsoft being the primary ones, did some limited studies with using multi-factor authentication and in those limited studies, they said...they came back and said, "Hey, in these limited studies, proof-of-concept studies, it stops 99% of attacks or 99% of log-on attacks." 

Microsoft went further and collected some data saying, "Of phishing attacks that tried to break into people's accounts to log in to their account, MFA stops 99% of attacks." The problem is they're essentially saying that of the attacks that ask for your password when you use MFA, it stops 99% of those. 

And that makes sense because you're using MFA, you don't have a password, you can't be phished out of your password. The problem is, is that it doesn't stop probably half of the phishing attacks. Half of phishing attacks try to install some sort of Trojan horse program. It doesn't stop unpatched software, it doesn't stop what we're going to talk a lot about today, Man-in-the-Middle attacks. 

And so, the statement that MFA blocks 99% of attacks that ask for your password is really...you know, it's a very limited scope statement. It does not stop 99% of attacks. I don't even know what percentage of attacks MFA just generally would stop. I mean, it's a lot, I think it might be 30%, maybe 50%. 

It's a lot. But the real problem becomes is that when an attacker knows that you're using MFA, they can bypass or hack like 90%-95% of the stuff that's out there. So, if you're telling people that MFA stops 99% of attacks or even 99% of log-on attacks, you're not telling them, "Hey, if they know you have MFA, they can probably easily bypass you or hack you." 

You're certainly not sharing that with them, so these customers were then shocked. They switched and they went to MFA and then they're shocked that they still got hacked. That's the problem. 

Patrick

Right, exactly. Okay, so let's hit these next two combine just kind of a little bit of a summary on, you know, whether these things...because we're going to talk a little bit more about this, a little bit of summary on whether these things are real, you know, is it just theory stuff? You know, we got some really, you know, black hat presentations and experiments where you're actually seeing this. And then, you know, if we're seeing it, what kinds of...at a general level, you know, what kinds of TTPs are the attackers using to bypass MFA as you were just talking about? 

Roger

You know, there for sure, real-world attacks. I think, you know, at least a handful of the most popular attacks that have happened over the last year involve the adversary getting around MFA. I've been writing about attacks that bypass MFA since 1989. So, they are the opposite. 

There are literally been millions of people compromised that were using MFA that still got compromised, there are going to be thousands of people today using MFA that get compromised. There are email phishing kits designed to bypass or compromised MFA, there are malware, password-stealing malware that is designed specifically to take into account that you're using MFA to protect your bank account, and they still get into your bank account. 

So, these are not theoretical at all, they've been around forever. I think when I talk to a lot of crowds and show them how easy it is to bypass a lot of forms of MFA and then I tell them, "Hey, it's been done millions of times," they're shocked, right? Because they've been told again by these people that, "Hey, if I use, you know, MFA, I have some special type of magic protection and I don't need to worry about things," when that's far from the truth. 

There are MFA...there are forms of MFA that are significantly harder to hack like Beyond Identity, but most of the stuff that's out there is really no better than a password. 

Patrick

Yeah, it's interesting, you know, the usual scenario when we're talking with folks is, "I've got a password problem, therefore, you know, I should just use any old MFA," and obviously...so we'll dig into that. Where do you see this going in 2023, next year, and even beyond? 

Roger

Well, I think more and more people, because we're seeing all these successful attacks against MFA, are finally starting to realize that not all MFA is created equal. And, you know, people and agencies and government agencies are now starting to say, "Hey, you need to get more resilient forms of MFA." 

You know, it used to be, "Get MFA, get MFA." I think what you're going to see in 2023 is more people going to be saying, "You need to get a less-hackable MFA." 

Patrick

Got it. All right, so I put this last bullet out here on purpose. Roger, he keeps all the vendors in order, us included and others, and there's this thing cropping up and we've used it. You know, I'm the marketing guy, so I own this one. We've used this concept of, you know, "unphishable MFA," and Roger has been polite to just subtweet us about it and not ding us on the nose but we got the message. 

You know, do you want to give us a couple of words on, you know, why you were seeing that as an issue? 

Roger

Yeah, you know, so I think I've seen a couple of MFA vendors or more than a couple say that because they're phishing-resistant, they turn that into, "We're unphishable," which, you know, it just one of those things that kind of got...you know, when you're phishing-resistant, that means that you're trying to be more resilient against the most common types of phishing attacks, but anything is hackable. 

If you were to bring the most secure...if you could invent the most secure MFA method or authentication thing, it can be hacked, everything can be hacked. There's all kinds of weird social engineering edge cases that might work against particular types of solutions. So, I just started telling vendors, "When you say you're phishing-resistant, it doesn't mean the same as being unphishable." There's always some way that somebody can socially engineer a human being in a way to get around. 

You know, your best protections that you tried to implement in technology can be bypassed by a human being if they just, you know, are silly enough or dumb enough to follow through doing something like... You know, if I can convince somebody to and you can have the best MFA option in the world but if I can convince you on clicking on a Trojan horse program, well, you're compromised, right? 

You know, and that's really because the MFA solution wasn't designed to stop that sort of attack. So, there still are methods of social engineering that might work even if you have really resilient phishing-resistant MFA. 

Patrick

Got it. And our challenge on the vendor side is to iron out what actually is and isn't phishing-resistant because what we'd struggle with is even if you do a good one, there's going to be other lesser platforms out there kind of claiming it. But we took the advice, you know, we took Roger's advice to heart, and we're going to continue to use it. 

By the way, the one thing that, the one threat model that none of us in authentication or security can block is this one. You know, you hold the gun to the head and it's just going to happen, right? You know, you're going to get compromised because that's a threat model that none of us want to protect against. All right, let's move on. You know, you talked about, you know, some social engineering attacks and we're going to go through summarizing, you know, some of the attacks and then jump in and have Jasson take us through how some of the more sophisticated ones actually work. 

Do you want to give us a couple of words on some of these things that we're seeing kind of routinely? 

Roger

Yeah, sure. The first one, MFA push-based prompt bombing or they call it MFA fatigue. Some of the MFA options will send a code to your phone and say, "Is this you logging in, yes or no?" And let me say in my "Hacking Multifactor Authentication" book, I like that one, "Oh, that's pretty good." 

Because the user is getting...they get an IP address and it says, "Is it coming from your computer and, you know, is this you logging in?" And I thought, "That's really good." Well, what I and others didn't realize is that people that have that option would...a non-minor percentage of people with push-based MFA will approve a login prompt that they did not initiate. Like, that was where, like, the designers and the human...it's just turned out the reality of human beings is that they will sometimes approve prompts that they were not involved in. 

And the MFA fatigue in particular or the prompt bombing is the attacker will try to log on like 100 times, so the person with this phone is just getting 100 prompts and they're saying, "No, no, no." And eventually, they're like, "Oh, let me just try to yes," or somebody calls pretending to be from IT going, "Hey, Roger, we're trying to install this new patch on your system and it keeps prompting us and if you don't say yes, you're going to keep getting those prompts and you won't be patched." 

And so, they're socially engineered into saying hello. And really, they just want to go back to sleep, you know, because the attackers are nice enough to do it at, you know, 1:00, 2:00, 3:00 in the morning. So, push-based MFA has really come under great attack because it's really difficult...apparently, it's really difficult to tell human beings, "If you're not involved in the login, don't say yes." You know, the second one, phishing, smishing, vishing, you know, we're certainly seeing a huge uptake in phishing via SMS messages or voice calls and, you know, it can really be... 

it's a really easy thing to do. Like, I actually has an example with a vishing of voice call. I had somebody call me and say, "Hey, Roger, this is your bank, did you buy two tickets from Dallas, Texas to Nigeria this morning?" And I was like, "No." They're like, "Well, Mr. Grimes, we think you've been compromised. You're a valued customer, don't worry, we're FedExpressing you a new credit card overnight but we see that there's $50,000 of transactions on your account and we need to verify which ones are the real ones and which ones aren't." 

You know? And I was like, "Oh, this is great, I think I'm being protected." They said, "What's your login name?" I told them, and they went, "What's your password?" I went, "Wait a second, I'm not going to give you this." "Mr. Grimes, thank you so much for being safe, we understand that. We're going to send you a PIN code to verify that you are who you say you are." And then all of a sudden, a PIN code popped up on my phone and it's like, "Just tell us the PIN code and we'll be able to verify that you're Roger Grimes and we'll continue." 

I'm like, "What?" You know? And I hung up, logged into my bank account, there were no $50,000 rogue charges. What they'd done is put my account in reset recovery mode and had I told them that PIN, they would have used it to then create $50,000 of rogue transactions. So, you know, part of it is...you know, and that's part of kind of in the pretexting type thing is, you know, I can even send you like with SMS messaging, if I know you use...most big logon accounts, even if you're using MFA, will allow that account to be put in recovery mode to reset the password to bypass the MFA by sending this SMS code to your phone. 

And, you know, if I know you use something like...you know, if you use a Gmail account, I can send you a text message going, "Hi, we're from Google tech support and we've detected a rogue sign-in to your account. In order to determine whether you're the legitimate login, we're going to send you a code, you know, that you need to tell us," and then that attacker just logs on to Gmail with your login name, your email address, and says, "Oh, I lost my password," or, "My MFA is not working." 

That will put Gmail in account recovery mode and they can then send that PIN code via SMS, shows up on the victim's phone, and if they type it back in response to the other message, again game over, the attacker uses that PIN, logs and takes over the account. A lot of times, the attacker will enable MFA. And let me say, I've never seen a Gmail, Instagram, Facebook account where the attacker then enabled MFA that the victim ever got control of the account back. 

Patrick

Yeah, so Roger, these are not necessarily sophisticated attacks but they're certainly ingenious, they're not hard to pull off. I mean, that's actually one of the things that we run into. You know, you hear all the time these attacks are getting more "sophisticated," and the ability that...you know, our former president talked about the large guy in the basement, in his mom's basement pulling off attacks and this is one you don't need a high IQ to do. 

You know, you can watch a couple of YouTube videos and do them yourself. 

Roger

Yeah, I do, I kind of shudder whenever someone says, "Oh, it's an advanced, you know, attack or something," I'm like, "No, this is kind of the opposite of that." 

Patrick

Exactly, exactly. All right, let's talk about some of the other ones. These are going to look a little sophisticated but as we'll see in a little while, they're not really that hard to pull off either. So, Jasson, you know, let's start with Roger introduce the idea of the Man-in-the-Middle attack, let's talk about that a little bit and how that works. 

Jasson

Sure. So, what we have here is a sequence diagram, so it's just a timing diagram showing us what's actually happening in the background. And in a minute, we'll actually illustrate the impact on the end user with an actual video demonstration. This is just to kind of ground you. So, the hallmark of a Man-in-the-Middle attack is the purpose of the phish or the lure is to get the victim to come to a site under the control of the adversary. 

And then the adversary, essentially, can either fake a destination site and collect credentials, or in the case that we're going to show you, they're going to proxy all of the internals of the web requests, essentially, from the victim to the legitimate destination site. And this actually isn't that hard to do, right? 

Because at the end of the day, it's easy to get a victim to arbitrarily click a link, whether it's through fear or through social engineering, right? There's a lot of psychological factors that do it, we just kind of have to accept that there is an error rate and people will click links. And what you're seeing in this picture, the adversary delivers a lure, the victim clicks on that lure, the adversary then initiates a login, and they initiate a login with an SSO that has a two-factor setup. 

When that result of the login comes back, it's proxied back to the victim, and so the victim thinks they're logging into legitimate infrastructure, so they continue the process and they provide their credentials, their primary credentials, their first factor. The adversary proxies this information to the SSO, which then triggers the 2FA, ostensibly the first factor was correct. 

And because 2FA, in this particular case, is push, it is a secondary channel, it is a secondary device, right? And we've kind of been taught...or I shouldn't say we've been taught but we kind of come to accept as a group that second channels inherently make things more secure, second devices kind of inherently make things more secure. 

And again, the victim thinks they're doing legitimate things, so they get the push notification on a secondary device that doesn't have anything to do with the adversary and they click "Approve" because again, they still think they're doing a legitimate thing. As the 2FA system gets the authorization, it releases an affirmation back to the SSO and the SSO releases what's called an access token, you know, as a session cookie back to the adversary. And, you know, the adversary at this point can either botch the connection, generate an error message, or let the victim continue about their day because what the adversary has actually done here is they've captured not just the credentials, but they've also captured something much more important, which is an authenticated access token for the session of the victim. 

That for most services, they can then drop into a browser and essentially hijack the session, enroll new 2FA devices, reset the password, and, you know, go off about the business that they actually care about, right? Phishing the victim is kind of more of a means to an end, it's not the end. But this is the classic Man-in-the-Middle, there's a couple of different ways of going about doing it but we'll show you a demonstration of this exact thing. 

The one thing I would point out here is whether this is 2FA push, whether it's TOTP, whether it's magic link, whether it's an SMS link, or whether it's Microsoft number match, it's equally susceptible to the exact same attack, which we'll show you here in a minute. 

Roger

Yeah, by the way, just one quick note is that, for whatever reason, Microsoft decided to start calling this Man-in-the-Middle attack the adversary-in-the-middle. I'm not sure why they decided to take something that's been used for 30 years and give it a different name. But if you ever see Microsoft say adversary-in-the-middle, this is the type of attack they're talking about as well. 

Patrick

It's abbreviated now to AITM as well. So, yeah, it's a whole new...like we didn't have enough abbreviations in cybersecurity, right? 

Jasson

So, sometimes if your conversation or arguments not advancing, you just change the name, right? 

Patrick

Exactly. So, before we do the demos, you know, Jasson, there's a variation on this theme that I'd like to have you talk through. It's an attack that, you know, a lot of folks haven't really heard of, you know, Man-in-the-Browser kind of an attack. Why don't you, you know, kind of highlight that? 

Jasson

So, it's a clever variation on the same scheme that we just described. Fundamentally, it's still a Man-in-the-Middle attack. The way the Man-in-the-Middle attack is carried out is subtly different. And I think the first time I learned of this was through a Twitter handle, Mr. Docs. He pulled together or she pulled together a fairly nice demo of how this actually works. 

I think there was an Italian research group that also did something similar recently. But the gist of how this works, again, it starts by getting the victim a lure into a psychological state that they need to go do something and they need to do it right now and they come to infrastructure that's under the control of the adversary. 

But rather than just proxying all of the HTTP from the legitimate site and legitimate SSO back and forth to the victim's browser, what happens is the adversary drops JavaScript on the victim's browser that actually emulates VNC. And so, the adversary infrastructure is actually running a browser in kiosk mode. 

And so, essentially, it's like the victim is driving the adversary's browser over VNC but VNC is really just driving almost like a remote terminal just inside the browser, inside the JavaScript. So, fundamentally, it's the same, which is why you don't really see the sequence diagram change. 

But what's highlighted here in this teal color is the method or mechanism of the proxy connection to the adversary infrastructure. It really is kind of a clever take. It's just JavaScript executing the VNC program to infrastructure that's hosting a VNC service with, I think, Firefox in...in the demonstration we'll do, it's like Firefox in kiosk mode. So, essentially, you can share the desktop but the desktop is the browser because it's in kiosk mode, so it's pretty fun. 

Let's move on to the demo, Man-in-the-Middle, Man-in-the-Browser, yeah, I categorically rejected the new acronym and will continue to use the old one. So, this is the first demo. And in this demo, what we're actually going to show is an SSO. And in this case, we're using Okta as the SSO and then we're going to show...2FA really set up as Duo Push. 

Basically, I'm going to show you the exact scenario that I showed the sequence diagram a minute ago, but I'm going to show you in real life. The victim, in this case, is Alice, the adversary is Bob because always go alphabetically. Again, old school, sorry. And, you know, we just engineered Alice to click a link, doesn't really matter how, "Hey, Alice, it's your boss, I need you to log in and approve a bill on BillPay," or something like that. 

Again, doesn't really matter. Alice follows this link to the adversary's infrastructure, Alice puts in her name and puts in her password. Alice gets the standard screen she normally gets, which is, "Oh, yeah, send me a Duo Push." So now Alice's phone is going to get the Duo Push, so she opens up her phone, "Is that you?" Of course, it's her. 

She, in fact, is trying to log in right now to respond to whatever her crazy boss is asking. And now she's in the infrastructure and she's going to dig around and try and attempt to do whatever her boss was actually asking her to do. So, now let's look under the hood. So, how we actually set this architecture up? Again, Okta was the SSO, Duo was the two-factor, I think we're just using Chrome as the browser, and the adversary infrastructure is essentially a reverse proxy. 

So, we use a pretty common toolkit, evilginx2, been around for a bit. There's alternative solutions that you can use, this pretty much works off the shelf. And as you can see, Bob the adversary captured Alice's credentials. But more important than the credentials, she captured information about the session, she captured the access token. 

And so, we're going to dig in there and you can actually see the unencoded access token right there at the bottom. So, that's the demo of Man-in-the-Middle where I'm actually...that's the demo Man-in-the-Middle where we're essentially defeating a push notification and a password through adversarial infrastructure, it's running a legitimate certificate, it's running a legitimate domain name. 

There's lots of ways of getting around all the mitigations you might think of around the name has to be real, the name can't be new, that sort of thing. But these are all problems that, for the most part, there's workarounds to. And then also, when we think about mitigations, we always have to remember, mitigation is not solving a fundamental problem, it's trying to mitigate a problem, it's trying to lower the error rate, it's not trying to eliminate it. 

And it turns out, when we start getting into the phish-resistance discussion later on, we actually are talking about eliminating the root cause of phishing-related MFA exploits. And we can get in and talk exactly what that root cause is and how you make it go away and then it gives you more time to focus on the other problems that happen. But let's move on to our next demo. 

Okay, now, we are going to show the second demonstration. And it's not going to look that different than the first demonstration because as we already said, Man-in-the-Browser and Man-in-the-Middle, they really are the same thing. It's just a different delivery mechanism of how I'm actually interacting with the victim's browser. In this particular scenario, we did change the architecture a little bit. 

So, in this particular setup, we are actually logging into Azure AD and we've enabled Microsoft number match in the back end. And we have partitioned the view that you can see here, so we have the victim's browser is on the top left and the adversary's browser is on the bottom, and you can see the victim's Microsoft authenticator off on the right. 

So, we've sent a lure off to the victim. Well, actually, you'll see a little bit of setup. So, the first thing that we're going to do on the attacker side is we're going to go ahead and set up the kiosk mode, right? Because remember, we want to take charge of the entire display because essentially, the whole way this works is we're going to drop some JavaScript on the victim. And as you can see, we just did that. 

So, we got the victim to click the link. The victim is now...you know, she has been told, "Hey, your boss needs you to log in and do some stuff," right? So, she clicked the link and she's in the very typical Microsoft home screen. Now, this isn't a fake site. This is a real Microsoft login screen, and it's being delivered to her via proxy. The proxy is at a different layer in the OSI model, right? 

We're no longer proxying HTTP, now we're proxying the payload at the payload layer of HTTP specifically through JavaScript. So, you'll see as we type the name in the victim's browser, you see it shows up in the attacker's browser. So, I go ahead, and now I get my number match, so I'll go ahead and do that. Again, the victim thinks they're doing a legitimate thing, so why not? 

And we are now logged in. So, again, the attacker...I'm going to go ahead and stop it there. So, again, the victims logged in, they're in a legitimate infrastructure, they're just being tunneled in a way that they don't realize. Are there mitigations for this sort of thing? Sure, you can mitigate a little bit here, you can mitigate a little bit there. 

But again, I do think it's important for us to kind of drive at the fundamentals. And here, what the attacker has achieved in all of this is not only did they get the username and the credentials and whatnot, but they're also getting access to the access token. So, if they want to register new devices, to deregister the existing authenticator, to enroll a new password, there's nothing stopping them. 

Roger

And attackers are doing this in the real world, this is not a theoretical thing. Attackers are doing it. 

Patrick

Jasson, I know I'm probably jumping ahead a little bit with this question. So, we're claiming a level of phishing resistance, of course, not unphishable as Roger would have to say, but what would happen using our scenario? I know we can come back and talk about how that might work or how it works, but do you have any demos that would show that? 

Jasson

Sure. So, let's go back and look at Okta. Okta is set up as a demo environment. We're back to our victim, Alice, Bob has phished Alice to log in. Octa is set up with the Beyond Identity platform authenticator and authentication service, and you're going to basically experience something that's a little bit different. 

So, let me go ahead and show you what that looks like. So, again, it starts off the same, Alex has been phished. Technically, the phish is really like the delivery mechanism, it's like getting the person on the endpoint to do a thing, right? And the reality is you don't stop that, that's not really what you're trying to stop. What you're trying to stop is the damage that causes an authentication. So, Alice gets the link, Alice clicks the link, we're still in Man-in-the-Middle, you don't stop the Man-in-the-Middle. 

So, Alice is on legitimate infrastructure but through this Man-in-the-Middle. She puts in her username but she sees something a little bit different and this has to do with kind of how a phish-resistant authenticator works. But you'll see it goes into an authentication mode and it experiences a failure, right? You did not verify your identity. 

I'll give you a little bit now but then we'll talk about a lot more later. The gist of it is, in all the previous examples, all of your authenticators, whether they're TOTP, whether they're push, whether they're number match, they're like these little discrete values that know nothing about the world other than themselves, right? So, how in the world can they be linked from the client's perspective or the server's perspective? The reality is they can't, right? 

The password doesn't know what device it's being used on, a TOTP doesn't know what person and what device it's being used on. Neither of these things know is the transaction that started the authentication the same transaction that finishes the authentication. And so, you know, at a high level, the spirit here is don't ask a human to solve a computer's problem. If you have a piece of software on the client that's acting the role of an authenticator, it should only respond to challenges that are valid. 

So, how do we know what challenges are valid? Well, it turns out we have a vast PKI system that already exists and we have a new trusted computing system that has existed for the last five years or so that we can take advantage of that and where this platform authenticator can verify the origin of the challenge and just not move forward. And so, what you see here is we didn't stop the phish and we didn't even stop the Man-in-the-Middle, but the Man-in-the-Middle gain nothing, right? 

The transaction didn't proceed, the authentication never happened, they never got to the stage of an access token, so there was nothing to steal, right? Again, you're not going to stop people from clicking bad links, you're going to reduce the occurrence of it. You're not going to stop being Man-in-the-Middle, right? You're going to reduce the occurrences of it. But what you can stop is you can stop your authenticator from progressing and that is really what this is all about. 

Patrick

Hey, for those of you who watch kind of closely while Jasson was going through that in our scenario too, you'll notice there weren't any weak factors, there was actually no password as part of that authentication. So, you know, that was just another piece to point out. All right, let's bring it back. So, we were talking earlier about whether these things are happening kind of in the wild, Roger pointed out that they are. 

Interestingly, some of the Logos didn't show up here but, you know, some of the notable attacks in 2022, you know, Uber, Oka, the Twilio Attack, attack on Google accounts, not Google itself, but Google accounts, and then a Microsoft breach all share the same hallmarks. 

They were using the techniques that either prompt bombing, some of the social engineering techniques, the techniques that Jasson was saying. The only one that wasn't a 2022 one was the SolarWinds attack, which happened before. And actually, Microsoft did, you know, helped all of us out a little bit. They went from, "It blocks 99% of things," or, more accurately, a lot of vendors using that statement inappropriately or not accurately, to very recently, I think it was back in May or June, they put out a blog talking about an active attack going after 10,000 organizations in which some of the successful attacks on companies went right through the MFA as well. 

Jasson showed you one of the toolkits. You know, we listed a couple here and we'll send the presentation out, so you've got links to all these. It's not like these are super secret, you know, on the dark underground. Each one of these toolkits is available on GitHub, as you said, this is the link to actually some of the different toolkits that you can get to, including the NoVNC toolkit that Jasson showed for the browser in the middle scenario that talks you through that. 

There's LAPSUS$ doing the 0ktapus attacks and APT29, which people will remember, that actually is, you know, the group that went after...you know, did the SolarWinds attack. That was actually sophisticated, right? I mean, that's one of the scenarios where sophistication actually got...the initial getting into the SolarWinds environment to pull off their attack was easy, actually putting in rogue code into the SolarWinds environment was a level of sophistication that took an actor like APT29 or also known as... 

Roger

Yeah, that one still scares me about what they did after they got access because that was definitely one of the more advanced attacks and very difficult to defend against. But the initial route compromise, not so hard to defend against. 

Patrick

Exactly, exactly. So, that was pretty interesting...oh, I guess we had it built, so the Twilio and Microsoft stuff. So, just a quick note, I'm just going to knock through this quickly what's going on and kind of we've got this, it's a real and present danger, what's going on in regulatory land? 

And so, you know, many of you are familiar with the Biden memo on Zero Trust, and then the follow on Federal Zero Trust Strategy. There's some interesting reading in there, it's actually a great document, it's absolutely well worth a full read. You know, it's not nighttime reading but, you know, it's early morning, you know, when you're awake. We dropped the link in there but there's two things, you know, regarding authentication that it calls out. 

One is they're mandating all federal agencies and that includes like, you know, contractors working with federal agencies, implement, and I'm using air quotes here, "phishing-resistant" MFA within the next two years for their workforce for the internal systems. They're also requiring as part of that for all of the agencies that have kind of constituent-facing applications, whether it's IRS or the health departments, etc., implement a phishing-resistant option, and I'm being very pedantic on that but that's exactly what they say in the regulation. 

So, they have to have a phishing-resistant option in the next two years. The assumption there that at some point, they'll turn off the...you know, they'll just go to the phishing-resistant only but hey, it takes a long time to take all 30 million...or all 300 million of us they need access to kind of go through, so they need some extra time. It also forbids the use of one-time passwords or SMS, voice, and email type...and push notifications they call it out specifically. 

Roger

You know, Patrick, I always say when I show people that particular memo, I was like, "Look at what it says, you can't use something phone-based, SMS-based, voice-based, push-based, or one-time password," I was like, "They just described 90%-95% of MFA that people are used to using." Like that, to me, should be a rocket launch of a sentence, right? Like, they're literally telling you not to use what almost everybody is using. 

Patrick

Exactly. So, there's a couple of...CISA did an alert, one that's actually interesting was Drizly, you know? So, you know, is this a thing that's required just for the federal agencies going to, you know, come in together? The answer is yes, it's going to weave its way in everything. In fact, very recent, Drizzly got a Consent Decree from the FTC that requires, and it called out by name, phishing-resistant MFA. 

The Consent Decree basically said, "Implement a real security program, put real controls in them," and one of the controls they called out by name specifically was this idea of phishing-resistant MFA. The real interesting thing of that Consent Decree that's kind of worth reading is that went against both Drizzly the company itself, but also the CEO whether he stays at Drizzly or leaves, which is that's the first time I've ever seen that. 

So, you know, they mandated that both the company do the right thing and that the CEO actually does the right thing, whether he stays at Drizzly or goes and does another company. So, that's kind of...FTC is I think pounding the table with that one. And we also know that insurance carriers are now requiring MFA, not just on a couple of applications, they're requiring it deployed everywhere, which brings into the...you know, one of the things that this brings into the equation is, you know, the idea of a frictionless MFA or something that's easy to use. 

Because if you've got it behind...you know, if you've got MFA in front of 10 or 15 applications that everybody has to get to, if that's not an easy thing to use, you're just going to get a lot of grief from your customer base. So, you know, those are some of the factors at work. Jasson, I'd have you give a couple of notes on...you know, summarize again what makes a phishing-resistant, you know, MFA, and so I'll let you hit on that again. 

Jasson

Sure. Like, phishing-resistant MFA is one of those things, right, where the most descriptive title of what it is is not a title. The phishing-resistant MFA is a type of MFA that concedes that phishing isn't going to go away and connections will be Man-in-the-Middle but the authentication should not proceed if that has actually occurred. 

And the way it does that is it takes the computational problem away from the human, right? Traditionally, we rely on humans to know if they are being Man-in-the-Middle by training them to look at the site, "Am I going to the right site? Is this the right thing?" If we take the human out of the process and we introduce a mechanized authenticator or a mechanized...a piece of software client that actually conducts the authentication on behalf of the human, figuring out whether the challenge of the authentication is actually coming from the right location can become easier. 

It turns out that it can be much, much stronger if we do a couple of other things, right? And those couple of other things are switching from shared secrets to asymmetric secrets, using enclaves to guard those private keys, to guarantee those private keys can't leave, and then leveraging that client software to verify that the challenge and the origin of the challenge is, in fact, in approved audience of the private key credential that is in the enclave itself. 

But at a high level, this is really about taking the computer problem away from the human and letting a computer solve it. 

Patrick

I'm going to leave this mostly for the presentation. NIST has a document called 800-63B. Roger said that, you know, I think that's under...they're looking to revise that further. But there's some, you know, particularly interesting points about what they call verifier impersonation resistance. 

You know, it's the same thing as phishing resistance but it goes into some of the concepts that Jasson was talking about. You know, one could argue it could even go further I think, Jasson, as you pointed out. 

Jasson

Yeah, the way to go further, right? So, number one, you want to use asymmetric crypto as opposed to shared secrets. You want to use asymmetric crypto instead of shared secrets, and the reason for that is if you're using asymmetric crypto, the private key never has to move, right? With shared secrets, the key has to move by definition. 

Maybe you're using a sophisticated MAC or HMAC protocol, it still has to move on the initial enrollment, right? So, key movement is really the whole problem of the surface area of a symmetric secret, right? You never go from your laptop to the service, you always go through proxies, you always go through load balancers, you always go through all of these devices, not even controlled by you or the company you're going to but by other parties. 

So, a symmetric secret that's distributed in that way, it's just indefensible, right? So, if I'm using an asymmetric key, the private key doesn't have to move but I still don't have a guarantee that I don't mishandle that private key, right? How many people asked the devs to create key pairs for SSH or forget and mishandled those keys or accidentally check those keys into a repo or do one of the many things that can be mishandled with that? 

So, the second step is asymmetric keys must be created inside of an enclave, right? Some form of secure enclave, but it's kind of hard to buy a device today that doesn't have this form of technology built into it. So, when I create a key in that enclave, I get a guarantee from that enclave that the key can't move and I get a little certificate with that key that's actually used in using that key in the enclave. 

And that certificate tells me about the provenance not just of the key, but of the hardware that generated that key. So, the only thing I really have to trust is do I trust Infineon as the hardware manufacturer? Do I trust the product line that actually produced this piece of hardware? The third thing that we have to do, and this is kind of what enables verifier impersonation resistance, is I have to have a piece of client software that's looking at this key, that's managing the secure enclave, that's looking at the certificate. 

And when the challenge comes back to be signed with the key, it not only verifies but it guarantees that it's not going to sign a challenge that's from an origin. And when we say origin, we really mean like the channel origin, right? So, like, think TLS server name that is not part of the audience of the certificate of the key bound in the TPM. 

And that's kind of where I think this can go further is there's ways of creating cryptographic linkage through all that context, right? One of the biggest problems that we have with MFA as it exists today is all the factors have no context of each other or the environment in which they're being used. And right now, a lot of technology exists for us to create hard context between those authenticators in a way that is cryptographically verifiable, that leaves a tamper-proof chain of evidence if things go wrong. 

And anyway, that's kind of the way this could go. 

Patrick

And I know this is going to be shocking probably to everybody listening to the webinar, but we've done some pretty interesting things to do that. You know, we rely on the TPM and that signing ceremony as one of our factors, we rely on the built-in biometric or even the PIN code, you know, of modern devices, you know, like Jasson said, nearly all devices as one of the factors. 

Both of those things are stored in the TPM, you know, they're not something that can be moved, they're not something that moves over the network, so they aren't susceptible to the kind of phishing attacks that we've talked about. And then we add, you know, device security posture too. You know, as Roger said there are other ways beyond just breaching the login, the authentication transaction, if I can deploy bad code on a device, if I don't have the basic controls in place on my endpoint device, that endpoint that I'm using to log in from. 

Now, you can't guarantee that that's perfect but you can make...you know, you can ensure all the controls that you want to have in place are there. And then, you know, one of the ways that we think about this is that gets you to phish-resistant but that doesn't take it far enough. You really want to get all the way up to Zero Trust access and add to that continuous authentication. The idea that we don't check this one...one of the foundational elements of Zero Trust is you don't have any transitive trust, you know, trust doesn't stay over time, you continuously check things. 

So, going from kind of a Zero Trust access or a Zero Trust authentication scenario is one level of protection, taking that upper level and making sure that you're rechecking that device or checking other risk signals on a regular basis and have an ability to kind of cut off the transaction or cut off the user, you know, if that device or the other risk signals go... 

If the device goes at a policy or you see some other wonky risk signals, it might indicate to you that something nefarious is going on. So, that's really...you know, the way we like to think about it is authentication is a fundamental element of Zero Trust and you can't get...you know, you can't have Zero Trust with passwords, you can't have Zero Trust with phishable MFA, it just doesn't work. 

But it's not enough, you want to keep going up the stack. We'd love to, you know, talk to you, you know, more about that and discuss that in the future, but let me turn it back over to Tom. I think it looks like we've got a couple of questions that came in that we can hit. 

Tom

Indeed we do. Gentlemen, thank you so much, appreciate your time, appreciate your insight. The first question I have for you...and again, attendees, if you have questions you've submitted and we can't get to them today, we'll get responses back to you via email. First question, everything we've talked about here, can they fix things like OTP or push notifications? 

Patrick

Why don't you hit that one, Roger? 

Roger

Yeah, I was just going to say, so I mean, I think the short answer is, yeah, they can fix it but the features and changes they have to make end up changing it so substantially that you end up really with the other solution. So, I would say that most of those options are not going to be very easy to fix and it's going to be interesting to see what they try and do. 

And again, I think the ultimate end result is that you're really going to end up with the other guy's more secure solution that he started with. 

Patrick

Don't try to retrofit something. It's the old idea of bake security in from the beginning rather than trying to bolt it on at the end. 

Roger

And I could be surprised. I mean, you know, you never know, but I think that...I think it's an inherently difficult thing to fix or else they would have fixed it by now, right? I mean, the U.S. government has been talking about this since 2017. So, we got five going on six years, and the best that they could come up with is stuff like number match. 

Jasson

Yeah, fundamentally, it's flawed if you really define the challenge as or the problem as the server needs to verify that the same machine in possession by the end user submitting factor number one is also submitting all of the other factors, right? If you want to do it in that way, then you have to establish context. 

The minute you establish context or linkage, then you have an integrity problem. How do you establish integrity? The minute you ask for integrity, you want cryptographic integrity, right, not check some style integrity. So, yeah, I mean, as Roger said, right, you end up essentially redesigning what the phish-resistant MFA products or the road they're kind of on to begin with. 

Tom

Another question, and it relates to the FIDO updates. "If I use a FIDO solution, do I need to worry about phishing resistance?" 

Patrick

Jasson, do you want to hit that one? 

Jasson

"If I use a FIDO-based solution, do I have to worry about phish resistance?" So, first and foremost, there's a good thing to remember, which is it's easy to design a protocol on paper that is secure on paper. It's a completely different thing when software engineers get their hands on that paper and go try and make it a real-life thing. 

So, just because the protocol says it supports X, Y, and Z, it doesn't mean you're off the hook for testing it. I would say number two, FIDO isn't necessarily universal across all the use cases that you're actually going to experience. So, you need a plan of action for how you're going to provide phish-resistant authentication for devices that you actually can't slum a Fido channel for. 

And then third, and this kind of ties into some of the stuff that that Patrick was talking about before, if you agree that context is the problem on authentication, right? How do I know the same machine that did Transaction 1 is the same machine that did Transactions 2, 3, and 4 and the fact that that machine is being driven by the end user that I expect? 

If you really want to solve that problem, you have to actually start talking about machine identity, not just end-user identity to correlate the two. You have to start talking about machine integrity, right, not just context integrity, to actually understand is it possible that the machine has an existing side channel. And the minute you start to do all of those things, you're arriving at something that kind of looks like what you've got with FIDO but it's a bit more than FIDO as it stands today. 

So, the way we put it is FIDO is not enough, you've got to do a bit more if you really want to close down these holes. 

Patrick

Yeah, we're super excited that FIDO came out, that they've really driven the discussion forward in a very meaningful way, and it certainly provides, you know, a lot of the capabilities that vendors like us and others can leverage. But, you know, as Jasson said, there's some more elements to it to ensure that it's totally phish-resistant. 

Do you have any more questions, Tom? 

Tom

One more. "Everything we've talked about with phishing-resistance MFA, is this achievable today?" 

Patrick

Roger, why don't you hit that one? 

Roger

Is it achievable that you get significantly less phishable phishing-resistant MFA? Yeah, yeah, there are good options out there like Beyond Identity that goes significantly toward a far less phishable option. You know, it's funny, the bare minimum...and this kind of points back to the last question, but my bare minimum is like, "Is something phishing resistant at all?" 

It kind of means that it's not susceptible to Man-in-the-Middle, right? And the reason why that's so important, it's a very popular type of attack and has been for decades and a big portion of it is. But even if you're not susceptible to that, there's still lots of other...I can, off the top of my head, think of 10 different ways to phish MFA solutions. And it's nice when we have the more sophisticated solutions that get rid of, you know, five or seven of the other ways, right? 

You're always going to be phishable in some way but if you can get rid of seven of the 10 ways, well, I got to tell you, that's a pretty stellar solution because it's becoming far more resilient than 90%-95% of the stuff that are susceptible to all 10. 

Patrick

It's all about raising the cost to the adversary and turning something that's, you know, trivial to do into something that's really hard to do. They'll either go elsewhere or, you know, have to spend a lot of time, effort, and money, which just reduces, you know, which attackers can actually come after you. So, with that, Tom, I think we'll just turn it back to you. 

Tom

Very good. Patrick, Roger, and Jasson, thank you so much, really appreciate your time and insight. Thanks for answering these questions as well. 

Patrick

Thank you. 

Tom

To our attendees, thank you so much for attending this session. We're grateful you took time out of your day to be with us and I do trust that today's discussion and today's insights have given you some valuable data points to enable you and your organization to be even better prepared to tackle the MFA challenges we've talked about here today. As always, I look forward to seeing you again at one of our upcoming sessions. And until then, for Information Security Media Group, I'm Tom Field, thank you for giving us your time and attention.