eXes & Oauths They Haunt Me: In-Depth Analysis of OAuth/OIDC Misconfigurations & Token Replay Attacks

Good evening everybody. Welcome to our last session. Uh welcome to Bides Las Vegas ground floor. This this talk is going to be the last talk today in ground floor and uh this talk is titled X's and OTS they haunt me and it's given by Daryl right here. Um A few quick announcements before we begin. We'd like to thank our sponsors, especially our diamond sponsors, Adobe and Iikido Security, and our gold sponsors, Drop Zone AI and Profit is their support along with our other sponsors, donors, and volunteers that make this event possible. These talks are being streamed live. And as a courtesy to our speakers and audience, we ask that you check to make sure your

cell phones are set to silent. If you have a question, we you would be using the audience microphone that I'm holding so that YouTube can hear you and I'd bring it along if you raise your hand. As a reminder, the Bides Las Vegas photo policy prohibits taking pictures. Yes. So, please do not raise your cameras to take pictures. That's not allowed unless you have explicit permission later. These talks are all being recorded and will be available on YouTube in the picture in the future. And if you guys have already settled in, please feel free to move uh move forward to let space for others who are coming in. With that, uh let's get started. Please

welcome a speaker again. [applause] >> How's it going everybody? End of the day Monday, right? We're all feeling energized, right? I was on a plane for about 15 hours yesterday, so I'm I'm in the middle somewhere, but we're going to get through this and we're going to have a good time, right? Um this is going to be about cloud security, cloud um authentication, authorization, some of the differences between OIDC and um OOTH 2.0. So, who am I? I'm just a guy. Uh currently I'm a solutions architect for Networks. um work a lot with ping castle, a lot of the old stealth bit tools and stuff like that. So everything from uh endpoint security to network

security, but I I mostly focus on identity. Um all right, so intros were quick. Just going to talk a little bit about what OATH is. We're going to talk a little bit about OIDC. Um the differences between the two. There is a lot of confusion that I hear sometimes. Um then we'll go over some of the vulnerabilities and common misconfigurations when you're developing your own custom web apps that need to interact with these authentication APIs. Uh we'll wrap it up with a quick just to token replay attack demo really just to show you the difference and the power of a bearer token versus other types of authentication in the cloud. Also at any point during this talk if

you guys want to like raise your hand or shout something out please. Uh, I'm not a web developer. I'm not a developer of any sorts. Uh, I tinker a lot. I'm a guy that puts band-aids on grenades, right? And we hope for nuclear bombs. Uh, so I come in in a clutch, I learn stuff real quick, and then we try to like flip it and do something good with that. So I say all that uh simple because I'm learning too. I am no by no means an expert in this. So let's have a good time and see what we get. All right. So um you know what is OOTH in general uh not even just 2.0 know what is uh open

ID connect or OIDC um why why do they matter why am I even giving this talk today so these two protocols are really they're more than protocols these two frameworks are really kind of the backbone of identity uh today when it comes to the cloud uh a lot of people are using OOTH and OIDC and may not even know it right it's as simple as like you you've got ways you know and it's telling you where the traffic is there's a cop around the corner whatever but you also want to listen to Spotify. So you're like, "Yeah, go ahead and give ways permissions to talk to Spotify so I can listen to my next app." Right? So these

are kind of some of the things that we're talking about, right? Being able to uh authenticate or be authorized to use and access resources uh on behalf of just some random user across the internet, any internet. So essentially O 2.0 um it's a delegation protocol, right? Right? And so it lets applications access resources on behalf of users. Um, and it does that without having to handle passwords. And so the thing that's great about that, that means that uh the authorization server doesn't have to worry about passwords. The end user doesn't have to worry about passwords. Passwords aren't in your file systems. They're not in memory. They're not in your logs, etc., etc., etc., right? Every all the places

we find passwords. Um, so that kind of alleviates that piece to an extent. So there are still pieces that we have to uh worry about and we still have to secure and we'll get into those a little bit. But um these protocols are being used everywhere. Um they're used specifically for API calls, but we use them in mobile applications. We use them in SAS all the time. Um and that's really what makes them a prime target is that you can access them anywhere, anytime, all the time. And with uh cloud platforms like GCP, Azure, AWS, you have the ability to really quickly spin up these web applications that rely on these authentication and authorization frameworks, but they're not really doing

any error checking or validation to make sure that your configuration is actually secure. It may work, but that doesn't mean that it works in a secure manner. Um, okay. So, we're just going to start off with um OOTH 2.0. So was it was developed by IATF um and it was finalized in 2012. So they actually have a whole RFC that's dedicated to them uh 6749 um that actually finalized in 2013 because they made an additional revision to it. But OOTH's been around for a long time. Oath 1.0 was around for a very long time by today's standards of like pin testing or red teaming or even cyber security. It was sloppy. It was effective but it was sloppy. It's the

like throwing the the noodle on the My wife's Italian anyway. So if you're making spaghetti, you throw a noodle on the wall. If it sticks, like the pasta's ready, like that's what it was. Like maybe, you know, maybe it worked. Uh so there there was a lot of holes in it. And uh so OA 2.0 came in in order to try to bring more flexibility and to uh make the framework more extensible. Uh OATH 2.0 introduced four new grant types. It introduced authorization code. Uh implicit authorization. Here are the fun ones. Resource owner password credentials. And resource owners are you, the user, the person sitting on the keyboard. Um, or client credentials. And the client credentials are the

application that you built, the application that needs to interact with everything else in the wild. So you can still pass those credentials uh using the the O 2.0. Not needed, but you can. All right. So this is a pretty common looking page whenever you're interacting uh with OOTH 2.0. Uh so this is Indie O whatever Indie O is cool but it's going to allow so when I when I log into my Twitter account it would allow me to or rather it would allow indie off to read tweets from my timeline and see who I follow. It even tells me what it can't do and I will implicitly believe it or I will read that long page that nobody

reads. Right? But uh that's that's really what uh OOTH looks like when you're the end user and you're interacting with it. It's really simple. You just say like yes, I want it to be able to do A, B, and C. That's all it can do. And those permissions are just tied to that token. Um this concept is really important when it comes to OA 2.0 because a lot of people get one concept mixed up constantly between OOTH and OIDC and it's that OATH does not offer any kind of authentication. It does not know who the user is, does not know where the user came from, doesn't there's things that you can do to uh limit your audience and

even limit where the issuer comes from, but there's no authentication that happens. It's simply a token that gets authorized to have access to some resource on behalf of the user. So, if anybody has access to that token, uh they have the same access as that user does based on what it was given to that to that um access token. Okay, so OOTH is relatively easy. Um, there are a couple of terms that are weird and they they seem not as uh intuitive as normal. Like when we talk about servers, there's a few different servers involved. When we talk about clients, uh when we're talking about cloud authentication, typically, not always, but typically when we talk

about a client and server uh authentication communication, the client is actually the web application that is making that authentication or authorization request on behalf of you as the human or on behalf of some other entity that has actual access to some resource somewhere. Um in most scenarios, we refer to ourselves, right? We are the client. The machine we are is the client, but this is the cloud. Um, we don't own those machines. The client can be a lot of different things. Um, so the resource owner, that's actually who you are as you know, average Joe. You own whatever data that you have in the cloud, you know, whatever frameworks, whatever services that you have access

to, those are yours and that's why you're the resource owner. So your web application the the whole point of it is to be able to mitigate that conversation securely and ensure that uh the web application only has access to the resources that the resource owner both has and has authorized and those two things are not the same. Just because you have authorization to something does not mean that because you create a bearer token based on your identity that that beer token has to have you know every privilege or permission that you have. you can actually make blank bearer tokens which will give you back you'll get a 200 okay so you'll know that you a

you're able to uh successfully authenticate but you'll never be able to pull any resources back so that's actually really useful for developers um all right so this is a very very very basic um authentication flow this is more of an internal facing app or an application that's not going to be public facing at all um and we'll talk about a couple of reasons why but uh just in general that application on the left, that's your client application. Um, your user is the resource owner in the top right and then your resource server in the bottom right. Those are kind of the big pieces here in this puzzle. So, it's it's simply that you wanted to access something. So, the

application on your behalf goes ahead and prompts you as a user and says, "All right, well, you can log in. You can use these different types of forms to log in in order to grant this authorization." Right? So let's say you use Google or you use Facebook or GitHub or any of these different providers. Uh you go ahead and get that authorization grant. Once that authorization grant uh is received by your browser or your web app, you get a redirect URI. That redirect URI is going to send you to the authorization server. In a lot of cases, your authorization server and your resource servers are the same, especially if you're looking internally, but this authorization server is the

IDP. So whether that IDP is active directory or intra id or uh you know octa doesn't doesn't matter google doesn't matter uh it it will always perform the exact same functions you'll get an access token and then you can use that access token for uh uh subsequent API calls now in a more secure world uh so that that last one was very straightforward uh doesn't matter what you came from. If I'm on a Linux machine, a Windows machine, a cell phone, whatever, right? I always hit that same backend. That backend interacts with the API the the exact same way. Um there have been a lot of exploits around that because not all operating systems, not all devices, not

all software interacts with these APIs the same way. And so if you just have uh a backend or if you don't have a front end that's sitting there that knows how to interact with the backend based on how that client web application would best work, you're going to end up with not the best results. You might still pull in the data that you're looking for, but it might not be formatted correctly. It might not come in um you know human readable forms and that type of thing, right? So uh this this screen this is backend for front end. Um, if there's developers that are here, I'm sure that you've you've heard of this, but backend for front end basically uh

just opens up the front end so that instead of having a dedicated just one service that has to handle every single API call for every single type of client in every single situation, which is going to get wrong a lot, uh you actually have a dedicated uh backend for front end. So based on the type of client or the type of user or other types of criteria um you will have a dedicated backend for front end that will then interact with those APIs specifically. Um, so this is brought up because this actually brings in a lot of optimization around just just uh client side programming um and scalability because you don't have to worry about

for every single time that you want to add in another API service or something else like that that you have to add it into this massive uh monolithic you know front end that has to handle all these different things. You can just spin up another front back end for front end and it just handles that API. um kind of similar to how uh MCP servers are working nowadays. If you guys are kind of in the MCP world, you've got this other server that does like the translation for you and that's what these these uh frameworks are doing.

So this is a a detailed just authorization flow. This is when you're using a backend for front end. It is very similar to the especially from the user standpoint. it feels the exact same. You don't notice anything different. Uh what happens is instead of having that authorization request go all the way to the authorization server, then back to you, and then you get the token all the way from the authorization server, then you send it to the application, um the application itself has a backend that acts for you on your behalf as a front end. Um and it handles that token request. So the it kicks off normal. You have an authorization request. Uh no user interactions

required. You get the uh redirect URI. Um, you get the call back request, you send it, the backend for front end then takes over, goes goes ahead and does the token request, gets the token, sends you everything you need, sets up the session for you, and then you're good to go. So, the back end for front end does a lot of the heavy lifting so that a lot of the uh the authentic authentication pieces or really the authorization pieces at the the endpoint, right? Using the token and actually being able to use that token to make a call is happening on your uh backend for front end instead of happening inside of the user's browser.

And we will talk about why that's also a problem here shortly.

Okay.

All right. Well, there was a video there. We had we had a minute and a half video that was gonna show authentication. Don't know why uh that's not working there. Interesting. All right. Well, we might wrap up a little bit earlier. That's fine. Um so when it's used, uh OOTH 2.0 is is mostly used when it comes to delegating access for APIs and applications, right? It's made so that some other entity, typically non-human, can make requests and interact with some resource on your behalf. Um, it enables login and I lightly quote, you know, I'm air quoting login just because of what login means to some people doesn't mean the same thing to identity folks, right? Um, but it does

enable login with, you know, Google, Facebook, GitHub, all kinds of different uh frameworks without you having to create an additional account. >> Say that again. DC now. >> No, no, no, no. I'm still I'm still on Oath. >> Okay. >> Still on OATH. >> So, the question was he's asking if I've changed and and hopped over to OIDC. No, but we're about to get there next. >> Um, so this is used and that's why I air quoted when I said login because the login is different to some people than others. So, if you actually look at the RFC and the documentation, it references logging in. It references authentication. It references a lot of words that are not correct based on the

protocol itself. So that's that. But speaking of OIDC, the prophet has spoken and we're here now. Um OIDC is an identity layer that's actually built directly on top of uh OATH 2.0. So you cannot run OIDC without OOTH. Um you have OOTH and then you have additional pieces to it. Now OAH 2.0 was originally designed for authorization uh granting thirdparty applications limited accesses access access to user resources. OIDC actually extends its support to authentication meaning that with OIDC you can actually verify and assert the identity of a user. Um this is really important because again like I said OOTH alone doesn't tell uh the client who the user is at all. it just implicitly trusts that

bearer token and then it's just going to go ahead and give access to the resources that the bearer token has access to. Um, OIDC fixes that by introducing a new type of token that's known as an ID token. Um, this is typically a JSON web token or jot token. Um, this jot token contains the claims of that user. So, it's got, you know, the username, it's got the email, the user ID, and anything else that the user wants to assert about themsel or claim about themsel. Um, OIDC is actually a dominant standard right now. Uh, which is kind of interesting because when you look kind of statistically as to uh the progression of um, OATH 2.0 versus like

OIDC, OAH 2.0, there were people that really were against it. They did not feel like it was secure enough. um with this secondary layer of OIDC. I mean it is hands down uh the one of the most dominant if not the most dominant um authentication cloud authentication protocol that exists currently.

So uh this is what it looks like again from the user standpoint. So Corest stack is just a a learning platform that I use, right? In order to log in, you can create a new account or you can log in with a local account with Core Stack or you can sign in with Google or you can sign in with GitHub. So the ability to be able to not even create a new account with a completely different system that you've never touched and just click that log in with Google and then you get redirected and now you have account you have an account you just use your Google account. Um this is OIDC and we see this all the time. I can't

remember the last time that I've like actually logged into a web app on my phone because most of the time it's just like you want to just use that account. I'm like yeah Google it up dog Google it up you know make it easy. Uh who wants to remember another password. All right so how it works again like I said it does extend on uh the 2.0 authorization uh the oath 2.0 authorization code flow. Um what it does do is it adds an additional token and that token is going to be a jot token and the user identity is encoded in the ID token. Now this is a this is an interesting thing. So by the RFC

standard the user identity is encoded. However, Jot itself is not a standalone framework. Um it's an extension of two other frameworks. Uh there's there's some really cool JSON stuff that's out there. Um most of this is JSON web signing that we're talking about. Um, and that typically uses encoding, but there's also JSON web encryption. And with JSON web encryption, the entire thing is encrypted. Like it's it's not just encoded. That's very very hardcore stuff to break into. It's just not common. You just don't see it very often. Most of the time when we're talking about jots, we're just talking about JSON web signing with these additional security features. Um, so it typically starts with just a

user request. that user gets authenticated by some IDP whether that's Google Active Directory, Entra ID, anything else like that. That IDP will give the authentication code. This can come in a lot of different ways. It can come inside of the actual URI itself. It can come inside of a body. Uh it can come inside of other forms of metadata just depending on the IDP. A lot of times it just comes across inside of uh the actual return uh URL. So once you have that, you can use that return URL to get redirected back to typically the same IDP, but not always, but typically back to the same IDP. You've got your um you've got your au

authorization code. That authorization code allows you to get a token. Now you have your bearer token and you can use that token. Now the difference is in this scenario instead of just getting the bearer token you also get an ID token and that's where that JWT or that jot token comes into play. Uh again so this is just that flow for uh OIDC right you've got the user request gets authenticated by IDP which did not exist at all in any other flows that we've talked about before. So it actually knows who the user is before the user gets authorized to anything. You get the authorization code that gets sent back to the browser and then the

browser goes ahead and gets the token and then can use that token for uh subsequent API calls. So not to spend too much time on Jot because there's like a whole bunch on Jot. Like if you guys like to break stuff, if there's red teamers out there, do it. Do your research. Do your research. It's awesome. Uh that's just me. I'm I'm I love cryptography. But uh jot token is basically made up of three parts, right? You've got a header, a payload, and a signature. Um by RFC standard, you can implement Jot tokens and IDPS in a lot of different ways, and they don't necessarily have to follow these standards, but this is what the

standard is via the via the RFC. Um what's interesting about it is like I said, sometimes the body is encrypted, sometimes the body is encoded. All this typically is is uh going to be pointed out inside of the header. The header is going to say, "Hey, this is going to be the encryption algorithm that we're using. This is going to be the length. This is this is what it's going to look like." The issue with Jot tokens and why they're such a prime target. And the reason why literally I'm having this talk today is because Jot tokens are actually incredibly secure. They're awesome. They're amazing. The code that we write to verify Jot tokens, not so

good, not so amazing, not so strong. Um, and the problem is unless again you have to know what you don't know. Um, you have to have some really strong error validation to understand that like okay well this token went ahead and passed and I got back the resource that I needed. But did the verification actually go through? Did it actually look at the ID token or did it just look at the bearer token and it got the resources when it looked at the ID token? Did it look at the entire ID token or was that ID token expired last week and we don't validate for for uh expiration dates? Um, so Jot tokens are prime targets. Left and right all day.

If there's any bug bounty hunters out there, you know what I'm talking about. All right. So, when is it used? Always, all the time, everywhere, online. Uh, if you log into pretty much most modern platforms nowadays, uh, modern applications tend to give you some sort of SSO type feel um, via OIDC, right? Um, that's that's one of the main reasons why when you open up your phone, regardless of what type of phone that you have, you don't have to like log into your apps every single time that you log into your apps and things like that, right? We don't have to cach these passwords anymore. Um, we have tokens to do these things for us. Um it enables

secure more secure I'm not going to say the most secure but it enables more secure login across systems especially across other things other types of um uh authentication authorization such as like basic or anonymous and you know but those things do exist they exist out there and the pin testers and bug testers will let you know that it's really interesting when you start messing with claims inside of a jot token and you throw in guest you throw in anonymous you leave it blank you throw in an actual null variable It's kind of interesting to see what happens. Um, so OIDC is widely used for federated identity and and single sign on. So again, when you use like Azure AD or

OCTA, something like that, you're pretty much guaranteed to be using OIDC underneath the hood. Uh what makes it better again is it is just OATH 2.0. It's just with this you also have authentication. OOTH does not care at all about who is the person that's making this call. You can add in some flags, you can add in some parameters to narrow that down a bit, but there's no authentication saying that this came from a true proof of source, you know, a source of truth rather. Um, it's just it's just out there. Whereas with OIDC, before you even progress to that stage of authorization, you've already been authenticated with that IDP. So, we're going to swing back to OOTH

2.0 0 for a second and we're going to talk about some of the vulnerabilities with uh OATH 2.0. There are a there are a few vulnerabilities that are targeted around OIDC specifically, but most of the attacks that really you see in the wild that work that are successful, uh whether it's a bug bounty or it's some like zero day or anything else like that, it's not oid specific. It's usually the the OOTH underlying uh process of getting that bearer token. uh because again if you can get that bearer token and there's no other verification in the system you're you're good or if the system doesn't know or it believes that you verified in some other way uh

and we'll we'll talk about that here in a little bit. So one of the most common ooth issues uh is a missing state parameter uh and this parameter is kind of important because it links the authorization request uh to uh to the actual response from the authorization server. So, that's what actually prevents uh CSRF. Without that, anybody else can just hop in if they're they're able to listen in on your network or for whatever reason they're able to to to grab this conversation, they can just hijack your session. There's nothing to stop them from hijacking that session at all. Um by having that state parameter in place, it highly mitigates does not completely prevent, but it highly mitigates that

from happening. Um the second issue and this is the one that I see the most common when it comes to bug bounties and um in the past when I've done security assessments uh across Entra ID and uh just some of these you know create your own application processes that some some corporations have in place is an overly permissive redirect URI um and then an overly permissive redirect URI validation. So the URI works, the the redirect works, you go to the authorization server, it tells you, "All right, awesome. So I've given you the call back. Come back over to the server." And again, 90% of the time, if you're out in the wild, if it's not

something custom you built, it's the same server. You went to Google, Google gave you the call back, you hit some other endpoint, you know, back on Google, you know, 90 99% of the time. Um, but the issue is an attacker can actually put in their own redirect URI, right? if they're able to hijack the session, they can just say, "Hey, I'm going to point it to my own server. My own server's got a nice IDP server that's running within the standards of RFC. So, that authentication process is going to go, it's going to get a proper token, right? And if that user does actually have access and does have authorization to specific resources, more than likely, you'll get access to

some things. um depending on what type of environment that you have in federated environments like if we're talking about ADFS that token a lot of times is not just you know tied to one different one service it ties to like a slew of services like there's a whole bunch of different things you can do and move your way laterally and then now you're laterally and you're in a different you know you got a different um access token that you have and from there you can just continue to escalate and escalate and escalate at least in the Windows world Linux world not so much but in the world of Windows and ADFS yeah what once Once you get in, you're

good. Okay, so um not going to spend too much time on this slide, but this is the same thing that we looked at earlier, right? Still, it's still got the BFF in the middle. The only difference is now the first step instead of it being the user saying that, hey, I want to access some application that's out there, they've already been hacked. They've already been pawned. Uh some attacker has been able to inject some malicious JavaScript or whatever to run in their browser, as an example. It could be a fat application. It could be any application. They will all support this flow. But this is a good example, right? JavaScript. So, JavaScript goes ahead and like it it starts off this

authorization uh flow on your behalf as the user, right? Goes out, everything starts as normal. Everything works the exact same. The difference is is in this script instead of this just being a just a plain HTML request that just goes out normal, it's going to be called inside of an iframe. And you can make iframes incredibly tiny. You can make iframes invisible. You can make iframes in the background. So this entire call, this person's just like on uh Facebook or doing whatever checking their mail and they have no idea that all this code is just running in the background, right? So uh when that happens, you go you go ahead and you get the redirect URI. the the attacker

actually jumps in there and it'll stop that call back. And this is where the attacker sends that redirect back to their own server. So you see that right at uh step seven. And after step seven, the user is no longer in this authentication flow at all. At this point, this is an actual authenticated and authorized flow from that attacker. If you looked in your logs, everything looks good. If you looked everywhere else, everything looks good. uh for everybody except for whoever that user was. He's He's having a bad day, probably. Of course. So, that video doesn't work either. All right. Cool, cool, cool, cool. Don't worry, there's only two videos. So, that was video two.

Let's uh cool. Um All right. So, additional OIDC vulnerabilities. Uh one of the uh the biggest ones is discovery document tampering. Um this is the way that you find it's one of the ways that you can find some of these redirect URLs and some of these URIs. Um many like many implementations of web applications actually uh trust discovery of documents and the issuer blindly. There's no verification of that. So like when you get a document and it says that it came from X, it came from Google, it came from besides Las Vegas, there's nowhere really inside the application that's verifying that. Uh so an attacker can actually just create fake tokens. Excuse [clears throat] me. So as long as

they're following the the RFC standards, they're going to that application is going to go ahead and go through its normal flow. Now, one of the reasons why this is possible is because a lot of times when web developers are creating applications, they're either in a rush, they don't know or they haven't fully switched from uh dev to prod uh you know with that application is they're not checking some of the parameters inside of the tokens itself. So the token has parameters such as the audience, who is this token actually for, right? This token is for, you know, DC05, but I'm presenting it over to file server 12, right? Why is it here? It should not be

here. The issuer, right? The issuer should have come from this is bad web implementation.net and it didn't. It came from this is really really bad web implementation.org. Uh, right. So, we're not looking for that. And there's also another state parameter known as a non. It's that one-time use. And a lot of times that's not even in place. And if it's in place, it's not being verified. Uh unless you're using a really kind of like major framework, I've never seen that just automatically added in. So if you're creating custom applications and stuff, the parameter for the nons is not just going to be there on its own. And even if you create the nons, the verification for that nons

is not going to be there on its own. So it'll pass and you'll think everything's good, but it's not actually verifying. Um, and again, this is one of the biggest issues with OIDC is lack of verification and there's no notification to you as the developer that yes, you succeeded to authenticate or to authorize, but you didn't succeed with your verification of of the data to get to that authentication or authorization. Um, yeah. So, well, this one is not a video. This one's live. So, hopefully the demo gods are better than my YouTube gods, right? And uh I've just got um I've got an IDP and I've got a vulnerable web app that's there. Essentially, I'm just going to log in.

I'm going to grab that bearer token. We'll curl it up and we're going to pull in some protected resources that I should not be able to get. Um but this bearer token, like I said, does come back across in the URI. And let me just

got start container. Cool. Awesome. All right. So, got the world's fanciest uh web application here. All right. Look at that CSS, guys. Look at that CSS. Call me. All right, let's go ahead and log in. Stole this template as well. [laughter] And we'll just call it me. Doesn't matter. One, two, three, four. Then we'll go ahead and authorize. Cool. So, uh, I'm trying to pull in there. There's a protected route called it's it's slashprotected. You can't get it to it unless you've you've been authenticated with the system. So, I'm going to go ahead and just grab this handy dandy information here. So, this is the actual bearer token that's here. Um, the bear token does get returned back inside of

the URI itself. Um, so I just went ahead and made it easier for myself for when I'm doing presentations to just like, yeah, why don't you just present it to me so I can just copy and paste. So, let's copy and paste. Hop over here, hop into Narnia. Yep, I'm one of those guys. And, uh, yeah, and just like that, uh, completely different computer, completely different operating system, just use the same bear token. I was able to be get, uh, get access to it. So this is just to show you that it doesn't it's not about the security necessarily or the encryption or even the encoding when it comes to uh you know creating these

jot tokens or creating these like in intense frameworks really a lot of times where the flaws come into play they come into play around the verification. So like you can have a token with the most security information in the world. If your application is not checking for that and then not responding appropriately based on what it finds, you're you're going to find yourself in a in a situation every time.

All right. So the reason this worked there's there's no token binding which means that I'm not using any layer of the session in order to tie into the actual token that I'm using as well. That's essentially a secondary signature. So if you change anything about the token or anything about the session, you know that something has been changed and it'll go ahead and and die off. The second thing is uh my token does not have expiration dates, right? It's longived token. That's a very common thing that we see out there. So even if you know a token's been exploited a long time ago, uh it's the same thing like you see with service accounts. Um they need to have

meaningful expiration dates. And the best thing that you can do, especially in a world of tokens, is that you want to have short-term lift tokens and just request and verify them on a more regular basis. You don't want to just have a long living token and just hope it's still doing everything that you want it to do. Uh the next thing is uh the no audience or the issuer validation on the resource server, right? So nothing to validate where it's supposed to be coming from and nothing to validate who this token's actually uh supposed to be served to. Uh no no token introspection or revocation support. This is kind of added on to more of like once you have a

framework in place and you have the ability to verify what do you do about it, right? Do you reject the token? Do you kick the token back? Do you alert the the fire squad and they coming down with the pitchforks or whatever? You know, that's what you do there. Um and then like no logging or anomaly detection. So anomaly detection is a big one especially in the cloud based cloud-based stuff if you're building your own applications it's a little bit harder if you're using you know Azure if you're using AWS it's already built in for a licensing fee but uh you know it is there though so the impact of this type of attack I

mean it it is a full account impersonation again there is no verification and there's not going to be any type of secondary tertiary or any following type of uh validation of that that token as long as that token is valid and that it hasn't expired, it's it's going to stay valid. Um, one of the cool things for red teamers and the the things for blue teamers is the fact that whenever you issue these tokens, typically in in almost all cases, they bypass all MFA and login defenses around MFA and that type of thing, right? Because they are meant to be used uh with non-human entities. Um, so whereas again when we're talking about federated environments, one token

might give access to dozens of services. Um, an attacker can pivot laterally, gather data, and even abuse APIs, escalate privileges, um, or destroy records. I don't know why I went up at the end of that, like that was positive. It wasn't positive, but I felt like I was bringing it home. Uh, so detection and mitigation, again, most of the things that I've talked about have not been any actual attacks. Nothing I've talked about has been red teamcentric. So I work in the world of identity. Most of the stuff that I deal with is identity. And besides like brute forcing and and you know the stuff we've been doing for a very very long time, most most attacks

on identity don't really come from any kind of like twisting or you know new breaking bad cool yellow jumpsuit type thing. They really just come from u misconfigurations in in the implementation of these frameworks. and then you have some guy who's sitting around or girl that that takes the time to find that hole, find that spot that you didn't cover and they're off to the races. So, preventative controls are use short-term uh excuse me, short-lived uh tokens, make sure that you validate the audience, use a nuns, the nuns will stop almost all token replay attacks because it changes every single time. Um, if you use announce, make sure that you verify that you use a nons. And one one last

thing that I I'm just going to give like a tidbit because I I might have known somebody who did this and that's why they created this talk was in Node.js there are two methods when it comes to verifying an OIDC token that Jot token. Uh there is a verify method and there is a decode method. uh if you don't read all the way down to the bottom of the page, you only got to the decode message and not not to that verify message. And they do similar but not the same things. The decode uh the decode method will actually say like, hey, yeah, this is a valid token. You can use that token. It's it's good, but it doesn't verify

it. It doesn't say that the information that I got from it that is in the right format is actually the information that should be in that token. So, uh, it's it's little things like that, uh, really on the developer side of of trying to figure out and make sure you learn the things that you don't know. Um, so for me, when I had to create an app in the beginning of the year, I did not know a lot about a lot that I did not know and I went down a lot of rabbit holes and broke a lot of things and pissed off a lot of people, but but we got there. Um, there are a lot of detection measures.

There's a lot of ITDR solutions around this. Um there's a lot of monitoring especially with AI nowadays everybody and their mother any any of the big cloud platforms are going to offer some kind of um heruristic behavioral analysis uh implementation again typically costs money but for most uh most organizations that's not something you can implement on your own you do typically have to outsource that to a third party um so OAF OIDC powerful but complex very small config configs, missing one word, missing one parameter, uh not verifying one thing, it it can negate every single thing else. Um so little mistakes can cause large issues. Um and really you just have to continuously test uh and monitor

your environment to ensure that your applications are doing exactly what they're supposed to be doing and only the identities that you want have access to the data that they're supposed to have access to. And that's it. I think I made it with a minute and a half to spare. [applause]

>> Yeah. >> Yeah. So, your certificates, would you say maybe like a typical workday plus like a couple hours for your hardcore devs? >> You're saying as far as securing how much time they're >> like Yeah. When do they when does your sort expire? >> Oh, so that depends. It depends on the resource, right? Right. It depends on the access because you created that authorization for reason like like what I'm thinking of is you know like your log insert but there might be other kinds of things >> right so because you have to have some kind of human interaction well you have to have some kind of human interaction in order to renew that token it's how

often does that human need to interact right so if you have something that runs every single night maybe the human if it's just updating something right like it's WSUS or something like that maybe you just need to interact with that once a week if it is financial software, right? And it's updating, you know, transactions for the entire day. Yeah, you might want to look at that every single morning and make sure that you have a refresh token and that that you're good to go, you know? So, but that is operational, not technological.

>> Um, in the beginning of the talk, you drew an interesting parallel between this and the MCP servers. I was just wondering if you've seen any similar attack vectors in the MCP space or you know if anything is like parallel to that world. >> Oh, as far as attacks Yeah. in the NC. No, not yet. But they're coming because uh there's so many uh MCP servers that are openly available like on GitHub and you know, script kitties don't verify their text and you're trusting some third party to make every single API call on your behalf. So yeah, you should probably read through that code before you hit go and do this thing using my credentials.

>> So can we expect like similar kind of identity problems with that space as well? Probably >> as far as uh MCPS specifically. >> Well, I mean I think that's really where it's at because an MCP server is just a translator, right? That's all it is. It's it's taking out the time for you to modify your code every single time that an API endpoint changes or that you want to interact with something else. And it can just do that for you. um you creating an MCP server, I don't really see any inherent issues with that. Um depends on of course like how you're interacting with it, but I don't see any inherent issues uh with with that

directly. It's more of when you trust that that code from somewhere else because you're going to give it your authentication. You're going to give it authorization. It's going to interact with APIs that you think it's interacting with, but if you haven't done any kind of um you know SAS testing at minimum against that code, you know, I wouldn't run it. Okay. >> Thank you. Um I'm going to ask something that's more uh specific. Um so I mean if you can't answer this question that's all okay because it's it's very specific. So the CSRF attack uh the the flow that you demonstrate earlier. So that one so is that the condition for that to work is

because that flow uses the set cookies. So if for example if I don't persist the persist the the the um the token on the desk >> would that prevent this kind of issue of happening? >> So so I don't I don't know the full answer to that. I don't I don't want to say the answer is yes. But I will tell I will say this that regardless of if the cookie is present or not present uh it can still work. It does depend on the type of cookie that you're using. Um because you can you can execute this code regardless of if the session is stateful or stateless. >> Yeah, that's interesting.

>> Uh are are you familiar with the uh pass keys at all? >> No. >> Because some of the issues you've talked about like lack of revocation, lack of logging, yes. Lack of transparency, I believe, issues uh affects Pesky's as well. Um it's it's hard to when they go bad, you don't know they go bad. You they're stolen. You don't know if they're stolen. Um and they do they are a pretty cool thing, but there's just little flaws in the implementation that sound like this. >> Yep. Yeah. And it's because you're using some other um method uh in order to represent your credential set. you know, we you see the same thing with Windows Hello is pretty solid, but few years

back and stuff, you know, when you're when you're uh using CAT cards and and things like that, like it's it's interesting, right? Because it's just tying your password or your identity, not really your password, but your identity to like some PIN that's on your system. So, if your system gets compromised, all you have to do is set a new PIN. You don't have to change your password. You don't have to worry about that. In your example earlier, you had the token coming back from your IDP in the URI. Uh, and then in your list of misconfigurations, uh, I saw both URI containing the token and Pixie. Isn't Pixie supposed to solve that, or am I completely off the

reservation there? >> Yeah. Okay, hold on. Let me go back a couple slides. Yeah, >> it's a good question. It's a good question. I don't want to say it wrong and I got notes for this. I was waiting for this question. So, uh, so Pixie pro uh proof key for code exchange we're talking about, right? Yeah. So, it is an extension of um OOTH in in this in this particular case. Uh, the access token is accessible in the browser because it was stored like in memory or in dev tools and it's and that's what it's supposed to simulate. It's supposed to simulate um nonsecure storage, >> right? Because like I found them, well, not me personally, but they've been

found even in logs, right? Like his credentials, right? And that's what that's supposed to show. >> Okay. So, if my IDP really wants to give me the token in the URI, that's not fundamentally flawed. I just need to be very careful with how I handle it. >> Exactly. And that that's really the takeaway for this entire talk, right? Is like the framework itself actually works really really well. You just have to be careful in the way that you implement it because there's a lot of pieces to it and like you miss one thing you're you might get a valid token but it's not being verified right so it's valid it's valid for some but not for the rest

right >> thank you thank you Darl right >> thank you guys for coming today hope to see you guys tomorrow have a great rest of your evening