Defending Cross-Device flows against Illicit Consent Grant Attacks

So thanks everybody for joining this afternoon. I, I really appreciate your time and also I want to thank Kuppinger goal for this opportunity to talk about the topic of cross device flows, some of the attacks that we're seeing against it, and also what we are doing to try and fix this.

So, baby, by way of introduction, I'm Peter Kasman, identity standards architect, and I have the privilege of working on identity standards, trying to make them safer, trying to solve problems for our industry at large, and also helping to shape the future of the identity industry in that process. So in the next 20 minutes, I am gonna introduce cross device flows for folks who are maybe not familiar with them. I'll describe these cross device consent phishing or illicit consent grant attacks, how and why it works.

And I'm gonna talk about the three-pronged response that we're putting in place to help and mitigate this. A combination of practical mitigations, some alternatives in terms of protocols, and also what we're doing with the help of academia to, to try and better understand these attacks and prevent them in the future. So cross device flows, what are they? So imagine cross device flow.

You have, they're designed typically for devices with limited input capabilities, but they're actually kind of handy in very various other scenarios as well. And so if you think about it, you have a typical consumption device that will initiate a session that will start by contacting an authorization server and essentially get and display a code that a user can then scan with their phone or they can enter it on their phone.

This usually then leads the user to authenticate and authorize to an authorization server, at which point the authorization server retrieves or allows the consumption device to retrieve a set of tokens, access tokens, and refresh tokens. And those tokens are then used to access the user's resources. And so in a nutshell, you initiate a session on one device, but you authorize it on a second one. And this is really handy, right?

Because you can use it with devices with limited input capabilities like your, your smart tv, your car infotainment system maybe, or maybe in other systems productivity applications, et cetera, where there's limited input capabilities. It also allows you to do strong authentication MFA with a personally trusted device. Your smartphone, a device that you trust, right? So that sounds great. So how does a cross device consent phishing attack look and what happens in these attacks? So there's this gap that happens between where a code gets displayed and the user that scans it.

And the problem with that gap is it's an unauthenticated action. That device, that QR code that you see, in fact the QR code that you have on your neck, when I scan it, I'm sort of taking it on good faith that I should scan that, that it is okay to scan that and that the context in which I'm scanning it is I'm at the EIC conference and I want to be connected to you, I want to learn more about you. But of course that QR code could take me anywhere. And that's kind of what's happening here.

So there's this air gap and the, the problem is there's no protocol that sets up a trust relationship between the consumption and authorization device. And really what we're asking the user, right? We're saying you make the decision, you decide if it's okay to scan this QR code that's being presented to you, and this is then open to abused by attackers by using social engineering attacks. And you end up with these illicit consent grant or cross device phishing consent attacks or consent phishing attacks. And so this is how it works.

The attacker have their own device or they emulate a device, another common technique, and they access the authorization server and they obtain one of these codes and then they change the context. Take a QR code and you can do something as simple as just put it up at a bus stop. Somebody's gonna scan it because this is one of those ceremonies, ceremonies that Ian talked about in his a keynote yesterday or the, the day before on Tuesday, right? We see a QR code, we know what to do with QR codes, you scan them, right? Or you get an email message, click to win.

So an attacker tries to access Netflix, obtains one of these codes, send you an email, congratulations. You know, we value you as a customer. We're gonna give you a six month extension on your contract. Just click this code or scan this QR code and we'll extend your, your subscription. So click to win. Or you get an email and it says something like this, we have been trying to reach you for the last two months. This is your final warning. We are going to delete your SharePoint site. Please sign in now, or your SharePoint site will be deleted and you will lose all your data.

And all of these are really designed to convince the user that it is okay, in fact, they have an imperative, they have a responsibility to complete this action. And so the user goes, they scan, enter the QR code, they present to the authorization server, which retrieve the tokens, and now the attacker has access and refresh tokens and access to your content. So what happened here?

You initiate the session on one device, you retrieve that QR code, some social engineering to change the context, and then the user can use as many forms of authentication as you can imagine, it can use the strongest authentication, any kind of mfa, it sort of doesn't matter because the user gave their consent, they agreed, and that's a big bypass, right? And so this is kind of problematic and part of this is because of the assumptions we made when we designed some protocols, right?

I think this is something for myself to think about is when we design an experience, when we design a protocol, it's this idea of homo securities. We expect an awful lot from our, from our users, right? We think of them as security experts. We want them to know how the protocol should work. They should do the right thing, right?

They can, they can spot the social engineering attempt. They, they're not easily fooled. And if only we add more homo securities members, things would be good. But we're really dealing with homo sapiens. I think of them as expertise elsewhere. They're not experts at identity or security or anything like that, right? They are experts at something else. And now we're expecting even more from them. They're busy, they're in a rush, they need to get things done. They're often worried about breaking things, right?

When you get that email that says your SharePoint site is gonna be deleted and it's gonna be your fault and your boss is gonna be upset with you, that creates a sense of urgency, right? And so we don't want things to break, they also want to help, right? That's another, there are attacks, there are versions of this attack, which comes as a sign in to help me, right? And people of course want to help. And so what we need to do is we think about protocol design in general. We want to our homo sapiens to make fewer decisions.

We need them to help, we need to have them to help them make better decisions, better information, and we need to protect them even when they make bad decisions, right? Because that is inevitable. We're asking 7 billion people to make good decisions, right?

And, and, and some of them will by accident, be misled and make the wrong decision. So how are we responding to this?

Well, we start, we start by doing what's necessary and then we'll do what's possible. And who knows, we may get to the impossible, but we, we really wanna start by some pragmatic things first, right? So we're putting in place a set of pragmatic mitigations, and I'll talk a little bit more about those things that we can do with the existing protocol. One of those is proximity, and I'll talk a little bit more about proximity in some of the coming slides, but it gets a whole lot harder if you can somehow enforce proximity.

This QR code is being scanned in the proximity of the place where it was actually displayed the first time this user code is being entered, at least in a country where I expect it to be entered. The, the completion comes from this, or the authorization comes from the same network as where the, the initiation originated from. Not foolproof, but a very good first step around proximity.

So, and there's a set of other mitigations. I'll talk a little bit more about them on the, the, the following slide. The other thing that we're looking at is exploring alternatives. So there are other cross device flows that are less susceptible to this kind of exploit.

And I'll, I'll, I'll speak a little towards those as well. And I think one of the things that I would encourage folks, as you think about deploying or building systems, be thoughtful about which protocol you use, if you need a cross device scenario or need to support a device scenario. And then finally some foundation underpinnings. We've been collaborating with the University of Stuttgart on formal analysis of specifically the device authorization grant or device code flow. That analysis, I believe has been progressing very well.

And we hope that somewhere in the next couple of months there will be some publication or some further with some further insights about any additional attacks that we may not be thinking about in the context of the, this set of protocols. So there's some additional work happening there. I think another area that we're very interested in, and I'm also interested to hearing maybe from people in this audience is research around the user experience for cross device flows. What is it that we need to, to do to help users understand the risk better? What works, what doesn't work?

And what guidance can we give to the industry, to developers about designing the user experience so that our customers will make better, better choices? So, so what have we done so far in terms of sort of practical mitigations within the iatf? We're working on a best current practice document at present. We have identified 14 practical mitigations that you can implement today with in addition to the protocol, right? So these are changes or these are mitigations that you can implement without making changes to the existing protocol.

I want to be clear that these, these do not prevent the attacks from happening. They just make it harder, right? And I think in security that sort of already, like just making the attack harder reduces the probability that the attack will actually happen. Some of those that I've highlighted here, establishing proximity I've already sort of talked about.

But really the more we can do to establish proximity, whether it's through network protocols, whether it's through wireless protocols or whether it's through geolocation, all everything that we do there to restrict that actually reduces the ability of an attacker to lift a QR code from one setting and have that consumed in a different setting. Trusted devices and trusted networks, right? So only allowing trusted devices to initiate the protocol that prevents that, that raises the bar for the attacker again, right? So now I have to get access to a trusted device before I can even start this.

And just restricting about who can, who can initiate the flow is already a good start. And then trusted networks, right? So make sure that maybe that device that you trust only comes from networks that you trust right?

Now, this may not work for all scenarios, but again, things to consider. The other one that I would wanna touch on, user experience, I mentioned the need for some research in this area, but just reminding somebody, right, when you display this QR code or when they see this QR code or when they scan the QR code, are you in Berlin in Germany?

No, I'm in Paris. Oh, that's weird. Maybe I shouldn't say yes. Right? The other, another thing to think about is the scopes. So it's very tempting to think about something like across device flow, like the device authorization grant as equivalent to a more secure version, version of the OAuth protocols, like the authorization code grant flow, and they're not equivalent, right? And so for that reason, we probably shouldn't give the same scopes and the same, same set of access to somebody using a cross device flow compared to somebody using one of the other protocols, right?

So just being very thoughtful about the scopes that the, the scope of access that gets granted short-lived time-bound codes, right? I think both of those, very important. If that QR code is only valid for 10 minutes, it makes it really hard for an attacker to scale.

Yes, they can still perform very targeted attacks, but at least I can't generate or obtain one QR code, send it to a million people, wait 24 hours, and, and then see who, who was kind enough to, to react to my call for help. And of course, the other one is just don't use some of these flows, right?

And, and so this gets us to protocol selection. So when we think about protocol selection, there are other protocols, some of them being standardized already, some of them in the process of course, right? So something like Siva, the client initiated channel, back channel authentication developed in the open ID foundation, slightly different properties, but a little bit harder to exploit, right? There are attacks against them, they are documented in the best current practice document we're developing in the IATF as well, but a little bit more secure, right? A little bit less likely to succeed.

And then I think the other thing is to consider, right? Is that even with the emergence of pasky with web and Fido standards, it is actually possible to just use the regular authorization code grant flow today and use your mobile phone to bootstrap a device and have, and really sort of use that, that existing highly much more secure authorization code grant protocol instead. Right?

Now, again, that puts limitations on your device and it makes certain assumptions about your users and deployments, but again, depending on your scenario, that is going to be a much more secure flow. So practically, I think, yeah, that's, that's where we are and yep, increasing security, right? So try and pick more secure options. So if you want to learn a little bit more, you can scan that QR code if you're brave enough.

I, it's some irony I didn't realize that I'll be, I should have thought about not asking people to scan QR codes after the fact, but we are working on a best current practice. It's going through the IATF process. We're still fairly early in that draft, really would welcome any feedback, input, you know, anybody who just want to have a read and help us make that even better.

The purpose of this best current practice document is really to document a set of the attacks to raise awareness of how these attacks work and why they work, but then also to propose a set of mitigations and help people understand which mitigations are effective against which attacks and to what extent. And so that's really where we are with, with that work at the moment.

Again, any feedback, any commentary on that would be most welcome as well. And with that, I'm gonna pause and if there's any questions, we have a minute and 30 seconds George. Okay. Have the, I mean the devices all are sort of different, right?

But the, the QR code might come up on, but have there been any conversations with browsers or smart TV makers or any of those things that would enable a BLE type connection between the scanning device and the device that's displaying the QR code? So that's effectively what the, the, I'm now, I may have the wrong name for this protocol, but there's this new hybrid protocol being developed with in Fido. And effectively what that does is when you scan the QR code, what it does is it, I'm gonna very crudely describe this, right?

It sets up a Bluetooth connection and establishes a session and then it uses a web socket and that is where the command channel then runs, right? So effectively it establishes proximity so that you cannot take a snapshot of that, send it to someone else.

I, I'm really excited about that protocol. I I wish we can expand that to other applications beyond Fido. But that is certainly one of the, one of the, that is an example of that. There is also work in the Open ID foundation. I thought I saw some of the authors earlier that's introducing an idea of using Bluetooth as a transport for verifiable presentations for wallet type scenarios. I think this will become very important for wallets. Actually I think the One is cable Too.

That, that and I, yes. And I think there's this hybrid mode in that, in that thing. That's a whole naming thing that happens there. applause.