Informal security chat with Beyond Identity's CTO Jasson Casey, Head of Global Sales Engineering HB, Founding Engineering Nelson, and our host Reece Guida on why push notifications as a factor need to be eliminated.

Transcription

Reece

Hey, everybody. Welcome to another episode of "Cybersecurity Hot Takes." It's me, your host, Reece Guida, coming at you live from the office in Manhattan. And I'm joined by...

Jasson

I'm Jasson Casey, I'm prerecorded, and I'm the CTO.

HB

Nice to meet you, Jasson Prerecorded.

Jasson

I'm Jasson Casey, I'm prerecorded, and I'm the CTO.

HB

I'm HB and I run Global Sales Engineering.

Nelson

And I'm Nelson. I'm a founding engineer.

Reece:

Excellent. So I think that today we are gonna talk about push notifications, and it's in the news because of what happened over at Uber with the prompt notification bombing. An employee got about a hundred or so of those and then just said, "enough" and clicked on it. And this is something that we've heard a lot of customers be concerned about. So, the hot take around that is that push notifications as a factor, have got to go. It is just way too easy to socially engineer somebody, right?

Jasson

You know, I've never really thought about it this way before, but somehow the way you just described that almost made me feel like a hostage scenario, right? Like, it's not that it's a terribly sophisticated attack, and we've known about this for a while, but, like, the essence of the push fatigue attack really just boils down to, "Hey, Mr. Victim, I'm just gonna keep blowing up your inbox or your notification tray until you allow me in. Why don't you just allow me in?"

Reece

Yeah. It's so insistent.

HB

It's like one of those really annoying wait or closed notifications on a window when you're in a browser with a bunch of tabs and you can't quite get out of it. It's definitely a denial of service attack, right? Like, it's a really elegant kind of denial of service attack that kind of targets an individual. And I think it's pretty reasonable. Like, if someone builds a push verification system that sends you hundreds of verifications without getting a single accept, I mean, it feels ripe to be exploited.

Nelson

You know, that old Windows 95 little dialogue that you used to drag around and it would repaint itself thousands of times, and people would fill the screen with it?

Jasson

Yes. It's not that, isn't it? Or the one where you go to hit Okay, and it jumps. Is that what you meant?

HB

That's what it reminds me of.

Jasson

I mean, it really is, like, it's a clever attack in terms of, like the subtleness and the lack of energy necessary to carry it out and the maximal frustration on the victim.

Reece

Yeah.

HB

But what's amazing is that it's been around for a really long time, and it's been a big problem for a long time. Like, when you go and, I mean, no attempt to victim shame, but if you go look for push fatigue attacks and go back even several years, you'll find that the dominant providers of MFA tooling that does push notifications, provide you with guides on how to run queries on your Splunk to detect an alert on these fatigue attacks.

Reece

So, it's kind of like an admittance that, "Hey, like, this thing, happens. You should be looking out for it." It's kind of like self-deprecating almost.

HB

It's absolutely shown and acknowledged. But the way that it's described, it's not accessible to most people that, you know, to be an identity provider, to be an MFA provider, and to tell your staff that they need to, you know, engage their SIM platforms or their central logging systems to extract events. That's a solution that doesn't serve the vast majority of the world. Now, arguably, it should have served some of the actors that we hear about the most, but even still, I think, you know, there was a huge absence of whole product thinking and just a reinforcement of the fact that even MFA products, they're seen as identity tools and not true security products.

Nelson

What percentage of security executives do you think get this and what percentage should get this?

Jasson

So remember, security executives come from different parts of the world, right? Or maybe not parts of the world is the right phrase of speech, different walks of life. There's different routes to become a CISO. There's technical-based CISOs, right, who are engineers. There is risk-based CISOs who are basically accountants, finance people, and lawyers. So, there is an element to push fatigue attacks that I think is a lot easier to understand for a technical route to CISO than a non-technical route to CISO. With that said, remember, CISOs have teams, right? It's not all on the CISO to figure all things out. And their teams generally do have a mix of tech-based talent versus risk-based talent versus just kind of logical account-based talent. So, you know, it's an interesting question. The relevancy, I don't know. I think you could make a strong argument in either way. Like, I would rephrase it as "What percentage of security organizations know about this?" I think that's a more interesting question.

Reece

Do you have an interesting answer to that?

Jasson

No. I mean, it should be all of them, right? But clearly, I mean, we have firsthand accounts where that's not true, just based on our interaction with prospects and whatnot.

HB

I think basically that, that's a good point. So, like, for more than a year, some of the major push vendors, like even Microsoft's authenticator associated to Azure has been promoting the idea of number match MFA. And number match MFA is a really interesting kind of mitigation to some of this attack, but you can see even in their own materials, when you look at the materials from the push MFA providers describing number match MFA.

Reece

Hey, HB could you just quickly describe number match MFA?

HB

It's the idea that on the authenticating applications login page, you would present a number. And in the client's authenticator, you know, usually a mobile device for most push MFA-type of solutions, it'll present you with three or four numbers, and it'll ask you to inform it which one is the correct number. So, you're essentially forced to make a little bit more of a cognitively present decision.

Reece

It's like a capture almost. It's like, "All right, tell me where the traffic light is." Like, "Tell me where number seven is?"

HB

Yeah. And the challenge with approaches like that is that they quickly start to resemble security theater. And the people who create these technologies, they do it very hesitantly. Like, when you look at the recommendations from Okta and Microsoft related to number match MFA, on one hand, they describe it as super important to implement the number match MFA.

On the other hand, they indicate that higher assurance authenticators are the genuine solution. So that's kind of this, like, "I want phishing resistance. I don't want phishing resistance. Maybe phishing resistance could be described differently. What's the definition of is?" Like, you know, it becomes very sort of strange and strained when you start getting people into these buckets. That said, I think that we've also seen a lot of number match MFA emerging because of the recommendations from the FBI and other government agencies that attackers have been going after these credential-based MFA, push MFA attacks pretty strongly over the past few years, and especially in the past 12 months. There was a recommendation earlier this year to colleges and universities to switch back from push MFA to OTP MFA, so that you would have to essentially create a pin on the mobile device and enter that six-digit pin into the authenticator on the IT.

Reece

Yeah, just adding friction to slow down the decision there.

Jasson

Here's the reality, right? Like phishing, whether it's man in the middle or phishing through an asymmetric attack is a class of vulnerability. And there are many instances in that class that are all uniquely different from each other in how they get executed, but they still fundamentally exploit a similar structure. And, you know, push is one of the easiest to defeat, right? Which is why we see a lot of it, but TOTP or number match are trivially defeatable if it's a man-in-the-middle attack, right?

So you can take a small, like, the easiest mitigation, if you have push supported right now is to disable it. Now this and turn on TOTP, which almost all push-based product support. You're not making the class of vulnerability go away, you're making an instance go away. There are a lot of other instances the adversary is gonna immediately move to, they're a little bit more involved. They give you a little bit more opportunity to detect, but not much more. And they are easy to carry out, right? As we've discovered with a lot of our demonstrations, like, "You need to focus on eliminating the class." And I think the government has recognized that, right, with both the thing put out by the White House at the beginning of the year, the FBI recently. I think the industry is recognizing that when they start using the term "phish resistance" and "anti-phishing" and there's some real technical meaning behind what that is, right? It's not a Marchitecture label. Like, there is a technical specification of how you achieve phish resistance to close that class of vulnerability. And that's really what people need to be focused on.

Reece

Well, let's get into that a little bit, right? Because I think a lot of people here, okay, phish resistant MFA and the factors and methods that most people know, like OTP, email links, SMS push, those are all phishable. So where does that leave us?

Jasson

So, yes and no, right? There, there are things that are not phishable, right? The problem is the channels themselves, right? So by definition, a man-in-the-middle attack is you give the adversary visibility into the factors that you're proving, right? Like, "I'm proving I am in this position." Well, the adversary then gets that information and they replay it as themselves. You're providing a knowledge factor. The adversary gets that and replays it in themselves. You are providing a possession factor that's proxied via a knowledge factor. So, again, if I have visibility of the communication channel, I can proxy that knowledge, I can use that proxy possession factor of a knowledge factor and hand it off to myself, right? So when you really start studying that structure, what does it actually tell you? It tells you a couple of things. Number one, there is literally an adversary in the middle of my communication channel, right? So how do I have bidirectional authentication on that communication channel, right? Now that doesn't technically make things go away, right? But, it gives us the first point of leverage.

The second point of leverage is the challenge and challenge response that's actually happening on top of that channel has to also be authenticated, and it has to be authenticated in a way where it pins the session layer that it's running over at a bidirectional. You can't solve those two things orthogonally. You actually have to sign them as a conjunction or solve them as a conjunction. And only when you solve them as a conjunction, do you actually remove the vulnerability, right? And the reason why I'm saying one is not enough is every architecture in the world of any sort of importance from a business perspective uses companies like Cloudflare and Amazon to proxy out their connections, guaranteeing that maybe not an adversary, but at least a business partner has private channel communications, right? So, how do we guarantee? And I'm just pointing at one thing, but, like, clearly architectures are complex. So there's multiple business partners that are gonna end up having visibility on that. Now, do we assume they never have an insider threat? Do we assume they're never penetrated? Like clearly those aren't good assumptions to take if I'm worried about securing my system.

So, I have to secure the challenge and the response. Securing it, meaning how do I know from an integrity perspective it hasn't been modified? And how do I know from an authenticity perspective, it's coming from who I expect it to come from? The way you man in the middle these other more advanced systems is you literally get in the middle of the connection and you just start relaying the factors that are presented. The factors are ignorant of who they're coming from and who they're going to. The machines that provide them are ignorant of trying to supply that context because the machines are this guy and you, they're humans, right?

Authentication isn't automatic. It's a human-driven process today. We type in the passwords from our brain. We pick up a phone, look at the code, and move a thing around, right? So, of course, I'm not going to understand and really recognize, am I going to the right domain name that is also properly signed by something in the CA root chain that is also related to this off-service? "Oh, is that actually the SSO provider? Is that actually the MFA provider?" Number one, the redirect happened so far, you're not even gonna look. Number two, these providers don't use their common domain names for a lot of the services they distribute. How am I gonna watch all of that, right? So, like, the identity and access market has set up a problem that is a class of vulnerabilities, and you're just playing Whac-A-Mole if you're chasing the small things. And I'm not saying you can't chase the small things, I am saying you have to pay attention to the class.

Reece

Mic drop.

HB

And Jasson, just to be clear, you're saying the big thing is to do proper cryptographic authentication of the foundation and then attend to the small things as they emerge in a much smaller surface than the typical way of, of going small things, small things, small things with a weak factor.

Jasson

If you're an operator, turn off push and turn on TOTP. That's the first thing you need to do. The second thing you need to do is realize all you've done is solved an immediate easy thing. You haven't solved a slightly harder thing, and you need to immediately think about the class of vulnerability and figure out how are you gonna deploy a proper phish-resistant solution. Now technically, maybe you're unfamiliar with this area and this maybe is another talk, but what is phish resistance and how do you actually establish it? And I would argue it's actually pretty simple. Number one, you move from symmetric-based knowledge, i.e. passwords to asymmetric cryptography. That way the private key doesn't have to move, it doesn't have to end up in that proxy server. It doesn't have to end up in the web server. It doesn't have to end up in someone else's caca cloud. You make sure that key is created and anchored in a secure enclave.

So, now I don't have to worry about protecting all of these spots of memory in the file system when a process crashes, sometimes the memory can get written to the file system, right? My apps for the most part aren't written with a security mindset. So, when they leave, the memory is not actually clear. It's not securely erased, right? Like, so there's this huge footprint that exists on an in-computing user device that's never managed, right? So, the easiest way of managing it is create the asymmetric key in the processor. So the key never moves. I send data down to the processor to get signed, right? So that's number two. Number three is I take the human out of the process of verifying the things that need to be verified. I establish a platform authenticator on that machine that's managing that credential, that's actually looking at the challenge and saying, "Is the challenge actually coming from something that's signed by a CA that I know to be my authenticator at the TLS layer and at the authentication layer? And only when both of those things are true, do I provide the appropriate evidence, and then sign the payload to return things." So that's the technical how, and there's clearly more details than I just kind of quickly went through. But if you're not doing that, you're pushing rope uphill.

Reece

Playing Whac-A-Mole.

HB

So that was a yes, but that's a cryptographic authenticator.

Reece

A shout-out to Nelson for designing that well.

Nelson

Oh, not even close.

Reece

Trying to give you all the credit, Nelson. All right. So you heard Jasson, everybody please turn off push notifications and at least move to OTP. And Jasson wants to say something, he's pointing.

Jasson

I just wanna make it clear. Change out TOTP for push immediately. Don't just hear the part, turn off push and go home.

Reece

Yeah, that's not good. Good point of clarification. All right, have a fun weekend guys. Thanks for talking about this urgent matter today. Maybe next week we can get into phishing-resistant MFA some more. What is it? Why does it matter now? Thanks for the time, everybody. Hope you enjoyed listening. Like and subscribe. Smash that button and have a good life. Bye-bye.

‍