How Attackers Bypass FIDO

TL;DR

‍

Full Transcript

Hi, everyone. Welcome to another webinar with Beyond Identity. We sure do a lot of these, don't we? Anyways, my name is Jing. I lead marketing here. Our abundance of webinars is entirely my fault, or your your abundance depending on how you wanna see the world. And with me today is Sarah Caccietti, and I will let her introduce herself.

I think our abundance webinars is due to the fact that every identity and management and every identity and access management professional right now really needs a hug. Like, there's a lot going on in the world that is, hard to understand, that is dangerous for your environment. And so, like, we understand. We wanna give you all a hug, and we're here to to help and to help you, secure in the craziness that is twenty twenty five.

Indeed. Well, here's a a virtual affection. Good luck.

Godspeed. You guys do very important work.

So today, we're gonna help you parse through this very, I would say, nuanced and and slightly complicated world of Fido. Right? Like, we are part of the Fido Alliance. We are certainly aligned to the mission of stronger authentication. However, it felt imperative that we actually tease apart some of the ways in which FIDO synced pass keys especially are actually really not enough for enterprise security.

And I I just have a quick housekeeping. It's being recorded. You don't have to, you know, frantically write. We'll send you today's recording and the slides. And if you have any questions, we certainly encourage you to reach out to us, directly or, you know, via our our lovely website at beyond identity dot com.

So lot of ground to cover.

Let's get the show on the road. You should be able to see that. Okay. So Fido, enterprise security.

Why is it not enough? So the TLDR is, we have to look at the threat landscape today to kind of understand why FIDO isn't enough on its own. Right? The threat landscape is is quite sophisticated nowadays, and there are three major attack vectors that can bypass or undermine FIDO based authentication in enterprise environments.

And in enterprise environments, these threats really matter. Right? The first of which that we're going to cover today is synced pass keys. The second is downgrade attacks.

And the third was actually presented during DEFCON this year, and it was around malicious browser extensions. And each of these represent a significant vulnerability that are being actively exploited. And together, I I think they highlight why a more comprehensive approach to identity security is really important.

So let's start with synced pass keys. Can you share with us, Sarah, a little bit about what they are and why it's important to kind of think about synced pass keys in a security context?

Yeah. So pass keys were designed as a replacement for passwords, meaning that they were designed as a first factor. But in fact, what you get when you support Fido is that you can use it as a second factor. And so if you say, hey. You know what? I'm gonna upgrade my account security. I'm going to support Fido as a second factor in my in my environment.

That gets supported everywhere in your environment, which means that your employees can then use their own personal cloud accounts for for their second factor authentication.

Now you might think, well, that's not so bad, but the problem is that that shifts the boundary of security from something you control to something you do not control. And it is not something that is easy to tie down. Right? So anyone any attacker in the world can call up one of your employees, pretend to be from the IT help desk, and say, hey.

I want you to register a new MFA key. This is how we're doing MFA now. Just open up your phone. Boop.

Boop. Boop. It's three clicks, and you can add a multifactor. And then the attack part Is it all they have to do is pop that iCloud account, and you don't know how much security is on that iCloud account.

Right? Not all iCloud accounts even require multi factor authentication themselves. Some of them are protected only by passwords. Some of them you can get into with an old login from your phone if you have an old code.

And some people can just go right into an Apple Store and say, hey. You know what? I dropped my phone in the lake. Here, I've got this fake ID for you.

Give me access to my account back, and, they'll get access to that iCloud account. So you have a a whole larger attack surface than you have, with a normal MFA account. So there are really three ways that this attack surface is expanded. So the one in the middle here is the the personal account sync. So that's what we were talking about. This is where the one of your employees intentionally and, with all goodwill says, I'm going to use my phone for MFA. I'm gonna hook this up to my Apple account so that it's just easier for me, but it's with their personal account, which you don't control.

The second over here on the left is cloud takeover. So if an attacker takes over that cloud account, they can then get into your corporate environment. They can get to your corporate secrets, to your corporate tools, and escalate from there. And then the third one is help desk abuse.

So even if they can't convince the person who is working for you to add the synced passkey to their phone, or to their cloud account, or to their password manager, or wherever they keep their passkeys, they can talk to help desk into, hey. I'm so and so. I need to add a new MFA to my account. Can you help me?

Can you help me get into this account and recover it by adding a new form of MFA that that we haven't talked about before. And, again, with Fido if you support Fido, you support Fido. Right? And there are ways to, to lock down Fido and to require certain kinds of attestations, but they are very complicated.

And just default Fido will allow all of these things, by default.

Yeah. I mean, sometimes I think of sync pass keys as almost like delegating authentication but to a weaker factor because all of a sudden, it's not your corporate policies driving access security. It's how did I protect my iCloud account? And, I mean, my iCloud account is actually quite locked down, but that's not to say that's true for everybody. Right?

And it's not necessarily just your iCloud account because passkeys can be shared just like passwords can be shared.

So if Jing says, hey, Sarah. I need access to our Netflix account. Can you send me the pass key for that? Apple allows they allow employees to send passkeys to whoever they wanna send it to, and there's no way to tell on the phone which passkey was created on the phone and which passkey was sent from someone else.

Right? And so your passkeys could be shared with all sorts of people, and you might never know it.

Oh, well, that's a that's a real bummer, which is why it's one of the key vectors.

So the second attack vector, which is also very similar to, delegating authentication to a weaker factor, is what the industry is starting to call downgrade attacks. And just like in the name, right, let's say you've implemented FIDO authentication. It turns out attackers say, well, FIDO is really great and strong. I'm actually going to tell your IDP to not use FIDO, and therefore, I can bypass it by forcing a downgrade to weaker authentication methods. And the reason that, downgrade attacks work is because WebAuthn isn't universally supported across all browsers and all, operating systems.

This means that most in the wild implementations have edge cases. Right? So attackers can bypass strong authentication by delivering a spoofed browser, for instance, that doesn't support WebAuthn or, just to disable Fido somehow and instead prompt the user for a one time code or a magic link, which severely degrades the integrity of your access control. Right? I think this, was originally discovered by Proofpoint researchers, and they performed this against Microsoft Entra ID. So if you kinda wanna dig into the research there, we also have a blog that, obviously gives credit where credit is due, so you could check that out.

This is interesting, right, because it doesn't quite break WebAuthn specifically. The standard, the protocol is still, in place, but the platform, the access request never really completes or reaches a FIDO ceremony. And the key takeaway here is it turns out, when your authentication method can be, defined by a weaker method such as one time codes, god forbid, a password, magic link, push notification, if that fallback exists, an attacker will use it. And attackers are a little bit like water.

Right? Water will flow to wherever gravity takes it, and it takes the path of least resistance. So, yeah, it's wonderful that, you know, maybe you have implemented FIDO. And if it's possible for your end users or employees to authenticate in a way other than FIDO, attackers are able to leverage those, pathways to, steal that session.

And I think I'm going to move us to the third threat vector, which is a a very sneaky one, and also very important to understand. So, Sarah, please.

Yeah. This one is usually accomplished by social engineering. So, your employees wanna be helpful. They want to do their best job. And if someone tells them, hey. I need you to install this browser extension, they probably will.

And the problem is that malicious browser extensions can go right around Fido, and they do that in three different ways. So they can man in the middle the web auth and call. So if somebody sends you a cryptographic challenge, they can sit in the middle, watch that cryptographic challenge happen, replay it to another place, get the response back, replay that response. Your employee has no idea that the attacker has then gotten into a secure system.

They can also manipulate the pass keys themselves. So Fido is designed to work with browser extensions. Some people store their pass keys in their password managers, something like KeePass or LastPass, OnePassword. All those things will store pass keys for you.

And if your, employee downloads a malicious browser extension, it can also say, hey. Look. I can store pass keys for you. I'm really good at that.

I'm being helpful. And it can take the pass key that they register and store it on their remote servers and share it with whoever they wanna share it with and use it for whatever they wanna use it for.

And, additionally, if you're using Fido as a second factor, they can exploit autofill. So they even if they have a second factor, right, maybe they don't have the password, and so that will keep them out. That is not the case with the browser extension. If that user has autofill on their passwords, either from the browser itself or from some sort of password manager, that browser extension can see what's going on in the DOM. So it can see what's go what's going into the browser window, and it can exploit that to take that password, steal it, replay it Anywhere they can. So You're really opening yourself up when you use Vanilla Fido to all of these threats caused by malicious browser extensions.

Yeah. Browser extensions are insidious. Right? Because I will also, as an end user who loves my productivity and time, download extensions. And every time they ask for permissions, it's it's a bit of a, oh, I hope it's a good one.

But I know we have some enterprise controls for, filtering out malicious ones. But you just you never know. Right? And I think the, when I was at DEFCON, they showed a really interesting, instance where they basically illustrated how a browser extension can click jack, like, the UI element. And I think the specific UI element was autofill, which is a fantastic, nifty, little UI component. Right? You type in a password or your username, and it doesn't it just fills out the rest.

It turns out if, you know, you get the user to kinda click it, trigger it, the browser extension can leverage that mechanism to exfiltrate stored credentials, codes, and even pass keys. This is why DEFCON is a very interesting conference for many for many people who work in security and identity.

So just to sum up the threat vectors involved in the overall FIDO authentication landscape, there's one thing that they really all have in common. They all exploit the weakest links in your authentication ecosystem. It doesn't matter if it's a personal cloud account, a fallback authentication method that is less secure, or just a malicious browser extension. Attackers will always follow that path of least resistance.

And the the truth of the matter is you're you're not actually as strong as your strongest access controls. You're only as strong as your weakest. So anything you consider to be edge case, anything where MFA or FIDO is not implemented, the attackers have a backdoor to get in. And because FIDO presents these opportunities, right, a security strategy that solely relies on FIDO is not complete because there's the entire authentication life cycle, the ecosystem, not just the credential itself.

Right? It's not that they've broken web authencryption or cryptography. Right? It's that they found ways around it.

So you need to really be thinking about the device, the browser, enrollment process, recovery.

And and Sarah will go into, you know, some of the other recommendations we have for how to implement secure authentication.

On my part, this is the part where we say, wow. There is a solution, and we don't want to throw out the baby with the bathwater because we like babies. Right? And the solution in this case, or the baby, if you're still on that analogy, is device bound credentials.

So unlike synced pass keys, device bound credentials are tied to a specific device. It can't be exported, synced, moved, tampered with. So instantly, you have that first threat vector unlock. That private key is generated and stored in a secure hardware component, so a TPM or a TEE, and it provides a much, much higher level of assurance because you know where the credential is and that it hasn't been synced or compromised.

And especially important in the enterprise context. Right? We're not talking about consumer here. Device bound pass keys give you, just a lot more assurance that this is actually the right user on an authorized device.

And in terms of form factors, device bound credentials, it can be a hardware security key. It can also be a single device, MFA type of solution like Beyond Identity provides where you don't necessarily need that hardware security key, as an extra thing to manage. We do integrate with YubiKey, though, because we wanna be supportive of a strong authentication ecosystem. In addition to implementing device bound credentials, we also have some recommendations for how to think about the broader authentication ecosystem.

So back to you, Sarah.

Yeah. So one of the things that, drew me to Beyond Identity that I love about this product and this company is that we have a super robust policy engine, the most robust one I have seen in the industry. And so you can set policies that say, look. The only pass keys that are getting into my environment are device bound pass keys.

They live on the device. They are created on the device. They are welded to the device. They cannot be shared.

They do not leave that trusted execution environment.

And you can eliminate all fallbacks and say, I do not want passwords anywhere in my infrastructure. I do not want SMS codes. I do not want any sort of way for an attacker to get around using that passkey. That is the only way into the system.

And because Beyond Identity supports all operating systems, all devices, we can ensure universal support. So some of the solutions you will see out there for, device bound solutions say, oh, yeah. We, you know, we support Mac and Windows.

And so then the attacker just gets into a Linux system. Right? So you really need to have robust, coverage of operating systems, of devices. That's something we invest heavily in. It is not inexpensive for us to do, and it's really important because we want that really secure perimeter around each identity and each passkey.

Second, we wanna talk about enrollment and recovery. So we wanna make sure that when you recover a passkey, it's high assurance. Right? You're not going to the help desk and calling in and telling them what your first dog's name was or your mother's maiden name.

Things like that are really relics of the past. We even have, right, AI deepfakes now where even if you know the person, you can't be sure that the person you're talking to on the phone or on Zoom is the person you think it is. So So we want high assurance recovery. We want only device bound credentials.

And, the third one we call capturing attestation. And what we mean by that is that when we look at a passkey, we don't just do a a cryptographic challenge. So we do do that. We we use the same model that Fido uses to say, hey.

Do you have the ability to sign this challenge with a cryptographic key that should belong to you? We do that. But in addition to that, we capture all sorts of information about the device, the operating system, where the key was created, when it was created, and we can cryptographically attest to those things so that you not only get assurance that the authentication is happening correctly, but you also get assurance that the device itself is secure and is in a state that you expect it to be in. And you can get an overall security picture of your whole fleet of of devices and their posture.

So it's incredibly powerful.

And lastly, we'd like to talk about device hygiene. So we want to bind the specific session that your user has to the device so that we know continuously as they go through their session that they're still on the same device, that they're still the same user, that they still have the same security properties and security posture that they had when they started.

We call that continuous authentication. So we check-in every few minutes and make sure that your device is exactly the the posture you expect it to be in, and we can leverage the investments that you've already made in security tooling. So if you have Jamf, if you have CrowdStrike, things like that, you can put those directly into your policy. The the really robust policy engine that we talked about before, it can handle all of those things, and it can check continuously.

Is CrowdStrike on? Is it operating the way I think it should? Is it actually reporting back? What is the security score of this device?

All of those things can happen continuously. So you might hear about this called shared signals. This is our proprietary implementation of shared signals where we continuously check with all of your security investments that you already have so that you can get more value out of them.

And lastly, we block weak factors. So if somebody wants to get in through SMS, if they wanna get in using just a password, using knowledge based authentication It's It's just not allowed. Right? So that kind of device hygiene where we can say, look.

If you didn't register with this device, it's not allowed in. I don't care how many passcues have been shared with it. I don't care what kind of things the user says are okay. It's absolutely not allowed if it doesn't have a Beyond Identity pass key coming from the Beyond Identity Wallet, which lives on that device, which means that there is no browser to compromise.

No browser extension can get into the Beyond Identity Wallet.

And so it's a much more secure way of doing that authentication directly through the back channel so that attackers really if they can't get in the middle, they can't steal the credential, there's there's no path for them to get through. So we're not just making it easier. We're not just making it better. We're completely eliminating their ability to use those attack vectors Wholesale.

I I like that. I like that a lot. To eliminate the attack vectors wholesale, that's that's a that's a dream. Right?

Because, it's like, talk to our customers sometimes, and they'll say things like, after I've implemented Beyond Identity, we've had zero, you know, identity based incidents. Or after we implemented Beyond Identity, as soon as somebody tries to come in with a, a password or requests a password reset, we instantly know that that's a bad actor. So so it it is very powerful. And to kind of bring the point home, I I think for us, the bottom line is Fido really is a starting point.

It's a foundation, but it's not going to deliver that complete wholesale defense. Right? We talked about how saying pass keys may improve visibility for consumers, but they come at the cost of enterprise access, visibility, and security. Downgrade attacks will push users right off the path of FIDO despite your best intentions.

And then you also have these malicious extensions and autofill abuse that can steer or hijack the process inside the browser. Right? So for all of these reasons, we we want to suggest that identity defense should be complete, should be wholesale, and should be deterministic. I know we covered a lot of ground today.

If you're curious about how Beyond Identity can help you implement these security principles in your organization, you see the link there, but you can also just find us at beyond entity dot com. And if you wanna kinda see the product in action, you can request a demo. We'd be happy to to show you and talk through your specific environment. And if you want to reach out to Sarah or myself, I think we are both on, LinkedIn and X, unless there's another place you'd rather people reach out to.

I think that's pretty much it. Thank you for spending time with us. We appreciate your time, and, have a great rest of your day. Stay secure, and, give yourself a hug.

Get get a hot chocolate. You deserve it. Get a pumpkin spice thing. I don't know.

Whatever you have to do. Thanks all! Bye.