Tim Tomes - {JWT}.{Misuse}.&Abuse

long time and I've been doing security for a really long time so I've used jwt's and code that I've written I've tested apps that have jwt's in them and I know that when I first got started and or even you know a little while into testing and developing I still wasn't super comfortable I didn't know all the I knew how to implement them but didn't really know about all the vulnerabilities that could exist within them and just over months years and particularly lately I just been writing a lot of code around them on for the purpose of really exploiting them for uh in different ways that you might think right I think a lot of us probably are

aware of the different cryptography issues with JWT but I like the thing that I really like to do and I do it in my training I do it in my talks is put myself in the mind of the developer and not so much look at what's wrong with the specification but look at what what are some bad decisions a developer could make about when to use these things and so I've just been exploring that and figured you know what I'll throw a talk together that just share is some of what I've been learning and so that's what we got going on here today um so uh this is a little bit about me but what's way

more important than who I am is why I do what I do okay so um it's my personal belief that that uh God gave me certain abilities right to do the things that I do and Jesus gives me the strength to do those things and so if you get anything out of this talk here today I just want to let you know that I won't um accept any Glory or thanks or anything for that it all comes from him in my book and I am just happy to have this opportunity to serve him in that way okay so all that being said the stuff that's on here for me feel free to digest it way less

important than the stuff that I want to talk about and deliver to you so let's go ahead and just skip this and go right into what we're going to talk about today so couple things talk about what what they are so if you have never even heard of jwt's or or jots as they are called in some cases I'll briefly go over what they are and kind of how they're composed we'll talk about why they matter then we'll talk about how they're used and then I'll jump into three different High Lev use cases authentication authorization and information exchange we'll dive into some specific use cases within those to explore them a little bit and do some

demos then I'll conclude and uh share some stuff with you in terms of resources and credits and attributions for some other stuff that you'll see in the presentation so what are jwt's and what are these things called claims that are with NJ WTS well jws are defined by RFC 7519 and if you ever feel if you ever need some sleep you ever short on sleep or you want to know a little bit more about jwt's go read an RFC or specifically this one because you're guarante guaranteed to get one of those two things if you do that you're going to get some sleep or you're going to learn a little bit about jwt's okay so

by all means that's the one that it comes from if you want to really deep dive into it that's where you go and it defines a JWT as a compact URL safe means of representing these things calleded claims to be communicated or transferred between two parties now the significant piece of that I want to mention at the moment is URL safe makes them really good for using Within web applications that are over HTTP and communicate through URLs and things like that so they're ideal for use over the HTTP protocol and they just basically transfer these things called claims well what is a claim a claim is a piece of information that asserts something about a subject represented in a name value

pair so if you've ever dealt with arrays or named arrays or things like that in JavaScript or any other language you're used to seeing name value Pairs and you can see an example here at the bottom right these are three different claims you have a name colon and a pair and when you put one or more of these things together in a JavaScript object which is where the JavaScript object notation in Json web token comes from you get what's called a JWT claim set and here you see a set of claims now there are couple different types of claims registered public and private I won't go into the details of those feel free to go check

the spec out if you want more uh details on what that means but ultimately none of them are mandatory all of them are option and it's very loose in how these things can be used okay there's nothing preventing nothing technically preventing the developer from completely branching from the specification and ignoring the fact that the Su are registered public or private the spec just CL has some definitions for that so why are these things called claims because on the previous side they just like they look just like JavaScript object attributes or properties right so what is this word claim and what does it mean because that's important to how these things are used and basically you've got a couple different parts of

of of relationship here in which these jwt's gets passed between you have an issuer is somebody that creates a JWT you have an audience someone that actually processes the JWT and within the JWT is information or these claims or assertions about a subject okay something not it's not even necessarily like the person that has this thing but there is a subject that the JWT is associated with and the things that the issuer is telling the audience are called claims because this thing typically transfers through an intermediate an intermediary and this intermediary may not be trusted if you look at this diagram right here you have a JWT that perhaps is coming from the authentication server which is the

issuer and going to be processed by the resource server but it's being communicated by this client so this client is an untrusted entity right because this is it could be a bad guy sitting there not necessarily an honest user and so they're passing this JWT that's making a claim about something that they learned from the issuer and until there's some sort of evidence that's making this claim truth it's called a claim and so that's where we kind of get that just like we would say use the word claim in the English language that's how it is here as well it's something making a claim about it and until there's some sort of proof it is just that a claim okay so claim

should not be trusted unless certain things are verified about it and then it can become truth and those two things are number one do they come from a trusted issue or trusted origin are they actually being provided by something that the person receiving at the audience deems as trustworthy and can we verify that it's not been changed in the process okay so Integrity is very very important when we're talking about Json web tokens and integrity is one of those words that's a part of that CIA Triad and security and what is like the main way that we ensure Integrity within within the CIA Triad within security some sort of signature hashing something like that okay and so we use signatures

or jws use signatures to actually enforce integ within these things and so whenever you see a Json web token with a signature on it it's actually not called a Json web token or it is still Json web token but it's Json web token in What's called the Json web signature structure so there's a couple different structures and Json web signatures are one of them the vast majority of the Json web tokens we see are using this structure right here and as you can see at the bottom there's a couple different parts right there's a header that actually describes the cryptography part of this how is this thing being signed and what are all the different variables with that then

there's the actual payload which is just the claim set that's going to be in there and then there's going to be the signature that tries to V that that that the receiver or the audience can use to validate the Integrity of that claim set okay so there's three different pieces there but the centerpiece is what's really really important there the claim set because that's what the Json web web signature structure looks like well sometimes Integrity isn't enough okay these Json web tokens if you've dealt with them but you know this they're transparent by default you can see inside of them you can decode them on JWT doio or using burp sweet Pro and many different Bas 64 decode them and

you can see them they're transparent the data in them can be seen and that's not always desirable so there's another structure built into this spec which is called jwe or Json web encryption and it's fairly similar okay you still got this Cipher text payload right here in yellow and that's basically what's going to be the jws that's then been encrypted using all these other other variables and then all these other pieces to it basically tell the audience how to decrypt it in order to get back at the jws which then gets validated with its signature and so on and so forth so you've got this technology that ensures both integrity and confidentiality and so it's a good way to communicate data

over HTTP because it's also URL safe and so why do these things matter well because they're a core component of modern web applications design because of all those things that I just shared okay the problem with it though is that the spec is really really poorly designed from a security perspective when the spec was released in 2015 immediately we saw this none algorithm attack coming coming through okay and if I get some time later I'll show you the really how the spec breaks this down and how this thing was even introduced but it's literally in the text of the spec that you can just tell the audience to not check the signature and oh it's not

going to do it and I can just bypass it so it's in the spec that this is how it works and that just was the start of it so here we are are eight years later there's been tons of vulnerabilities that have come out um against JWT that are that are that are with in reference to how the spec handles cryptography and in black hat what two months ago there was three more vulnerabilities that were just closed so the spec is just broken pretty badly with regards to cryptography okay well if it's so bad then why don't we have an alternative okay well there are alternatives out there you see a couple of them listed

here there's macars there there's petto right but the reason why we don't use all Alternatives is because they don't have a specification jdb has a specification an iets specification and from a political perspective that makes it the standard okay that makes it the standard and what doesn't help is when you had other organizations go and start developing authentication protocols and authorization protocols they actually built JWT the specification into their specifications and so now if you're required to use jwt's to process ID tokens in oidc which we're going to talk about here in just a minute well you're already using JWT somewhere in your application so why would you then go use an alternative at another place of the

same application so it's just kind of force adoption at this point in time so the reality is these things are here to stay so developers need to be able to implement them security of securely and the testers need to be able to evaluate the security of those implementations okay so that's why they matter and why you should pay attention now what are the use cases for jws there's three High level use cases that we're going to explore authentication authorization information exchange and the approach for this talk is that we're not going to be able to cover or we are going to cover all the categories but we're not going to be able to cover all of the use

cases there's just not enough time so I've just broken out a couple of my favorite use cases that we'll explore I'm not dropping any zero days in here if you go out on the public domain you can find some information about these okay but the majority of what you're going to find on the public domain is going to be about the crypto stuff the nun algorithms the rsca the r the RSA um algorithm confusion attacks those types of things in fact Port swigger web security right there they cover a lot of that those crypto level attacks on this I want to focus on things that aren't covered by things like the web Security Academy the ways I see developers

implementing them that's just broken by how they've implemented them not So Much by someone leveraging the spec so we're going to focus in some non-c crypto related areas plus they're just more fun that way I think at least the demos are um the examples that we're going to use are based on mistakes I've made as a developer and also mistakes others have made as a developer that I found through security testing because I do development I also do security testing um and I also do training on how to do this stuff so i' I as I write code I make mistakes too we're all we're all subject to that none of us are perfect okay at least I'm not and then we're

going to demo specific use cases but I want you to know this when we demo a specific use case like we're going to do a specific attack against you know an authentication system I want you to know that that's not that that that technique that we're using is not unique to that implementation right the techniques that we're going to employ through the various demos that we do are valid against any JWT used in any system so I want you to remember that and not get hung up on the fact that we did this one thing with an access token then we did this other thing with an ID token those same attacks are valid on all the

different types of tokens that we're going to look at all right all the different specific use cases but we just want have time to to demonstrate them in all cases so just keep that in mind as you go through so let's start with jwt's in authentication now the majority of the time when you see jwt's used in authentication you're going to see them refer to as an ID token and the reason being is because an ID token by spe by the open ID connect specification or oidc as the acronym is an ID token and the spe specification says it has to be a JWT so that when you see an ID token that's typically going to be where

you're seeing it as is a part of an oidc flow okay and it's going to be an artifact that proves that the user's been authenticated so the last thing that happens in an oid connect kind of handshake between you and this third party is going to be this thing called an ID token and that gets passed poent to the to the server and that tells the server this is the person that just clicked the log me on with Google button and that's how this that's what the server processes to log that person in and what you see right here this is literally some information taken out of a Google open ID connect ID token so

those are the types of information that you should generally see depending on how that token is scoped now the issue that I've seen here in testing and as a developer mistakes that I have made here is that there's a couple of different open ID connect flow anybody here ever implemented an open ID connect client or server right it's a complex handshake right it's built on top of something called oal which we'll talk a little bit about in a minute it's not simple and when you go reading through the documentation of these various providers whether it be Facebook Google or whatever there's two different flows that you'll come across there's something called a server flow and and

there's something called an implicit flow and they have very different security implications and it's very easy to be implementing say the implicit flow but reading the documentation from the server flow and bad mistakes can happen I know because I actually did this all right I was imp I was implementing an implicit flow open ID connect thing and I was accidentally and I know it sounds crazy but if you went and looked at Google's Google's documentation it's an absolute mess it's like spaghetti code in documentation and I was reading the ser flow documentation that said that I do not have to validate the signature when I'm using that particular flow okay and so that's that's because of that

confusion and the complexity it leaves open the opportunity for a developer to not check a signature when checking the signature is the absolute most important thing that they can do in that particular relationship so whenever I'm testing an application that's implementing open open ID connect and there's an ID token involved the question I always ask myself when I'm going into this is what if the de developer mistakenly trusted an implicit flow like a server flow and I know because and I and I can do that because I've done it before and I know the implication so let's go through and demonstrate what that looks like and this is a dead simple one that I think

many of you have probably already seen okay but we'll do it just to kind of just to sort of get things started today okay so we're going to be using burp sweet Pro of course JWT editor is the is the uh extension that we're going to be using to look at the jws and analyze them and tamper with them and then we're going to be testing an application called pb.com This is actually ponub 2.0 the original one is a part of the same Suite of applications this is what I train with this is what I talk to this is where I do I build all my vulnerabilities that I talk about into the suite of applications so we're going

to be testing this or this is going to be our Target app so I want to exercise the open ID connect flow here by clicking the sign in with Google button and what you're not going to see or actually you are going to see it is just going through the process and because I've already logged in through you didn't see the prompt for my my username and credentials and to click this button to allow these things right I've already done all that off the stage it's already cached so the browser just did all the things for me and flow and took me through the flow and I result and the end result is an created account and now

a login okay so I've created the account and simultaneously logged in and I can go to log out and then let's look at this process and see what happened so this here is probably clicking the button or somewhere around in there but this post to the access token that is actually coming back from the process so you see these exchanges happening between accounts.google.com it would actually be a heck of a lot longer if I had to go through the process of typing in a username and a password there would have been probably somewhere in the neighborhood of 20 to 30 different requests going back and forth but all of those are between my browser and Google so they're not even in scope

for what we're doing the most important piece is this last part for me where Google Now hands things back off to the Target application which is this api. pb.com and I see this ID token being passed here then that results in an access token which is basically going to be my temporary credential moving forward that temporary credential gets passed off to users me it pulls back some user information you can see there that it's Tim Toms and then I can continue to use the application with my access token from that point for okay but what happens if the signature is missing what happens if I take this ID token and modify it to have a

different I guess some different claims than what were actually sent by the issuer so I'm going to right click this and send it over to repeater and we can use Json web token or Json token editor or JWT editor plug in to do this and we'll actually just go over to tab mode so we can see some things here and so I'm going to go in here and I'm going to type in admin. ponub do.com instead of pb. gmail.com and we could have enumerated this this user or found it in any number of ways and the application is vulnerable to that but let's just pretend we've got this piece of information here and now let's replay

this and we can see we get an access token now we could just have an access token that's invalid okay so we don't know at this point in time whether or not it's valid but let's go and take that users me endpoint and replay it to it and see what happens so send this over to repeater we'll grab our token here here that came from our modification pasted into our authorization header and hit send and you'll see that we're logged in as the administrator so in this particular case the server did not check the signature it did not validate the signature and the end result of that is me being able to actually log in as the administrator

because what the server did is take that ID token look at that email and it said oh I've already got an account that's associated with that email I don't need to create a new one I'll just log that person in that's why that signature is really important because my browser is an untrusted intermediary and this and the audience which is the server should have verified integrity and they did not now this is just the beginning there's tons of signature attacks so even if they're Val validating signatures and if I go over here and I enable signature verification within my application and we try to do this again and this is our modify JWT and I

hit send you'll notice it says expired or invalid ID token that's because the signature is properly being validated at this point in time and now I would want to move forward with all those crypto attacks that I said I'm not going to talk about today once again go to that web security stuff for from burp and it will cover those in great depth so that's basically what you would want to do you want every time you're doing with the JWT absolutely make sure it's checking signatures and that it's doing it properly that's an absolute must all right let's move on to the next use case here which is jwt's in authorization okay so quite often when

you see the when you see an application using access tokens you're dealing with authorization at this point in time and there's a couple different times you'll see access to tokens being used and you can obviously use it for way more than this but the vast majority of the time they're going to be used one as a part of the of an ooth flow and where open ID connect is an authentication mechanism ooth is an authorization mechanism okay now the difference between it here is in the in the oidc the open ID connect spec jwt's are a part of the spec ID tokens have to be jwt's not so with oaf oaf doesn't say that jwt's have or sorry

oalf doesn't say that access access tokens have to be jws but in many cases they are just so happens in Google open ID connect they're not they're just opaque pieces of data but they can be and quite often are one of the ways you'll you'll see these used a lot is access or JWT uses access tokens a lot is when we're dealing with temporary credentials okay and the thing about temporary credentials we're talking about sessions a session is a form of temporary credential right you log into an app you receive a session ID and the server is Now tracking you via that session ID access tokens can also be temporary credentials in a stateless application where I'm using say a single

page application on the front end and an API on the back end when I log in just like I did here in this app I'm given an access token and that now that becomes my temporary credential there's got to be something inside that temporary credential that identifies me as me right there's got to be something in there whether it's my email address whether it's my user id that's a direct object reference to the user table there's something there's got to be something inside of that access token or that session that tells that server that I am this person okay it's got to identify me so one of the things I'm looking at whenever I see an application

that's leveraging access tokens as a temporary credential one of the things I ask myself is what if the developer use the same claims right the same claims in a more accessible token signed with the same key so I've got an access access token and it may have a claim like Sub in it like here that's got my user id associated with it okay what if I can find some other token that the application uses that uses the same the same exact claim to identify the user ID but I'm able to make it represent a different user have a different number in there a different user ID so if you've got an application that's using access tokens look for

other places using tokens and then substitute them and this is an attack called JWT substitution so let's play this out in our application and see how this works okay so I'm going to go in here and I'm actually going to make this really hard on us because not only am I going to enable signatures I'm going to enable encryption so now we can't even see our tokens our tokens are encrypted and they're signed this is the worst possible case scenario for an attacker okay this is this is this is this is the most difficult type of Json web web token to attack so let's log in with an existing user here and the existing user

we're going to log in is Cooper so Cooper at pup.com and it says hey you got an email this is a passwordless authentication system anybody use a passwordless authentication system anywhere Maybe not maybe it's kind of like the hotness nowadays all right so passwordless system and I've got a the ability to check email here so I'm gonna go to my inbox and I see Cooper's inbox there and here's my email that says hey here's your code for passwordless authentication so I'm going to copy that go back to the app and put in the code and I'm authenticated to the app as scoper that's how those systems work I'm sure we've done these things before I've

tested them that used emails I've tested ones that use uh SMS they use text message and a phone number lots of different ways for passwordless authentication systems to work now let's go and let's look at this a little bit more so it probably started right about here there was my that was my log out so first I send over cooper. phone.com I get back a 403 that said there's a Code required and here's the code token okay so then I take that code token and I post it and I get back an access to access token but not only am I sending over the code token I'm also sending over the value that I typed in

that I got through my email so I got one an email put it in there sent both of these value back across the server evaluated those two things and sent me back an access token that then I can go and access users. me with and the rest of the server side of the application okay so the interesting thing about this is I've got Cooper in and Cooper out right so Cooper goes in here and then after all the after all this happens I get Cooper out at the end right here at the users. me but there's a handoff that happens in between with the code token where am I at here so I get this code token and right here this

code token gets handed off for an access token but Cooper goes in and Cooper goes out so it stands to reason if I got the same person in same person out and a swap of tokens that those two tokens have something in them that both identify me as Cooper right something in both of those tokens have to identify the user which is Cooper in this particular case okay so what if the code token is using the same claim to do so as the access token that's what we want to try out here so what I'm going to do is I'm actually going to go in and try to log in as

admin okay now I don't have the admin's email right I'm not the admin I'm Cooper so I can't access the admin's email what I can do is I can go in here and I can look at the code that came back and if I assume if that that that subject is the same person in both cens they're using the same claim then I may be able to use it as the access token to go back and access that same user's me endpoint so I'm going to go back here or actually just hit send here and you can see here this token is no longer valid so I'm going to take my code token and paste it

in here remember this is encrypted and signed send it over and I'm logged into as the administrator okay so I didn't even have to see it okay I didn't have to see it there I could just assume based on the behavior that perhaps this code token is using a similar claim and if it is I may be able to confuse the system into treating my code token as an access token and that's absolutely what this application is vulnerable to now let's look at another version of this that I actually find even more interesting so I'm going to go over here and I'm going to make this more typical now so typically we're going to be

dealing with jwss sign Json web tokens so for this next demo we're using just sign jws web tokens we're going to be able to see inside them which is which is pretty normal when you're dealing with jwt's okay so I disable encryption now I'm going to sign up for a new account so I'm going to go to sign up I'll use my Gmail account here my display name and I'm going to sign it okay it tells me that my ACT activation email was sent please check it I have no idea why it's way over there that's never happened before but you get the gist so I'm going to go over here and check a new inbox I should have

a new inbox and I do I've got mine tjt 1980 go to the activation it sent me an activation link so I'll click the activation link it takes me back here and then I could log in to prove that it worked at this point in time and you would see a loadup users. me and it would be Tim okay so let's go and look at what happened in that process so I'm going to go down here and here's the post that I signed up that I posted to sign up for the account you see I got email I got my email name Avatar signature and then the API responds back with success equals true which then

triggers the front end to say front end to say hey check your inbox we sent you an activation email so then I go I check the activ a email I click the link it loads the application in order to send that token the activation token from the URL back to the server again the server takes that token and it says okay I validated that token um I'm creating the user success is true you've created the user and then it would go on and pro and and provide I'd be able to log in with it at that point in time to receive an access token for for um the new user which is Tim and continue to move about

using the application okay but let's look inside this activate token actually yeah let's look inside this activate token and I want to show you something that is very interesting to me if you look at this you'll see email tjt 1980. name Tim Avatar nothing and signature nothing what stands out to you about that it looks exactly like what I sent initially so if we compare that to my registration request which was right here it looks identical it's the same information so there is potential here that that the server is taking the information that I gave it in the registration request and is just taking it and stuffing it inside the JW the activation token which is

this JWT and then is reading it back in I can't modify it because it's signed right but it's sending that information over and then receiving it back and creating a user as long as the person proves they are that person by clicking the activation thing okay but if these are exactly the same maybe anything else I send in that par that initial signup request will show up in the JWT that be some interesting Behavior so I'm actually going to take this and I'm going to send it to repeater and I'm going to add a claim here fuar hit send got success equals true so I should have a new activation email let me go into tjt there's my new

activation email and if I click on it the user already exist so I should get that the that the user already exists but let's look at the token that was created as as a result of this process and you see four. bar which is supposed to be Foo but whatever I'm a terrible typer okay so that's interesting I feel like I I now have control over arbitrary claims inside of this and if I can control arbitrary claims then maybe I can overwrite existing claims and if I can overwrite existing claims then perhaps I can override the subject claim to make it anything I want and turn this activation token into an access token okay so let's

try that I'm going to go back to my repeater here and instead of using four I'm going to use sub instead of using bar I'm going to use one and we'll just guess it's the first one okay another activation email here so let's check it I got that pop it open and let's see what we have so now I don't see sub one at the bottom up there it is right there so it overwrote the meaningful claim that I that that I I know at this point in time means something to an access token right so now I'm going to take this activation token that shows up here I'm going to go back and replay it again to that users.

me to prove or to determine whether or not it'll actually process it based on that claim so go to repeater go back to where users me which is right here does this still work probably nope it doesn't good that's perfect so let's go down here paste that in hit send and I'm the administrator so I was able to forge basically an access token because I controlled the claims through some other mechanism within the application so this idea of substituting tokens for one another jwt's keep an eye out for that if you see an application that's using jwt's in a couple different places see how much of those things you can control start swapping them around and using

them in different places and you might be really surprise what you come up with okay all right so so the last category that I want to talk about is JWT and information exchanges okay now in reality everything we've done up to this point in time has been exchanging information in jwt's okay so ID tokens fall into that category access tokens fall into that category but these are more things that aren't governed by any types of rfc's they're not governed by any sort of any sort of standard these are things that developers have made up things like uh activation tokens code tokens reset tokens a lot of the things that we've already been tinkering with that you have may also may have seen in

applications we already talked about how tokens are transparent and often contain sensitive inform information and in most cases that's not a problem okay because the bearer is often the subject like if I am the subject of the token and I can see my own token what does it matter right well then sometimes it doesn't but sometimes it does I think we've demonstrated some ways in which it can matter especially if the app is broken okay uh but Integrity is always the priority when we're talking about Json web tokens J the ability to change that is a huge deal and that's why we normally we're at at a minimum we're going to see jws implemented here which

enforces signature verification right but sometimes that's not enough sometimes the ab ability to see inside of a token is a problem and here are some examples here number one um stor in local storage for persistence if you've got a transparent token sitting inside local storage has got sensitive information and even if it's about me if I get exploited remotely or if somebody sits down at my terminal or if there's a cross-site scripting in that particular application someone else can steal my token and then look at the contents of it and gain information about me and sometimes it reveals things about the bearer that they shouldn't know about themselves or others okay and what that means is is perhaps the token includes

some information about me that then allows me to infer things about someone else so one an example of this that I've seen is a token which had a had a private claim in it that basically showed an upload folder and the upload folder had a path in the operating system but then at the end of the path was an md5 hash well that md5 hash was the hash of my user ID so I just looked at the sub which was you know whatever I hashed it as md5 and it and that was the that was my folder so I knew at that point in time on the operating system exactly where my upload folder was which

means I could also guess that information for every other user of the system so if I ever found path traversal I would then know exactly how to get to other people's places within the file store so things that you could infer about other users would be bad um and sometimes they contain sensitive information about unauthenticated systems and that's the one that we're going to explore so what if the developer another question I'm always going to ask myself if I'm dealing with an application that's leveraging these kinds of tokens is what if the developer failed to encrypt a sensitive token so let's take a look at that okay so I'm gonna log in with Cooper went to the wrong

place um did I need to nope I think we're good I'm going to log in I'm going check my email go to the inbox I think I loged in as Cooper grab my password list authentication token paste it in there and I'm logged in okay so that's the login process let's review this process again we've looked at it once before let's do it again so here we are we're we're presenting our our email um we are what what do we receive back here we should receive let me go back to this side by side we receive a code require 403 with a code token then we provide the code token along with the code it gives us an

access token and then we're able to use the application okay so how do these systems when we're dealing with a stateless system here and a stateless system means that the server does not remember what our code is the server the server when it issues us that token it completely says I have forgotten everything about you I'll think about you the next time I receive something meaningful from you there is it is completely stateless so everything that the server is going to know next time around when I make contact with it has to be in that request it doesn't remember anything about the relationship across a series of requests so that means that this code token has got to

have that piece of information in it right and if we look at it you'll see that it's got the subject to which is Cooper's user ID and then it's got the code okay so it sends the code over to my client and then when I place the code into the box on the screen it sends the token that has the code in it and the code from the request or the code that I typed in the Box gets them both to the server Compares them and says okay they're the same you're good to go it verifies the signature to make sure I didn't modify the token to just be what I typed in right so it does some of

those things it validates the signature and we're good to go and when the developer implements this or QA is testing it they look at this and they're like okay I see I that token looks obfuscated to me we're good to go okay so what can I possibly do with this well let's take a look so I'm going to go in here I'm going to log with

admin now I don't have the admin's email address right I I mean I had their address but I can't go in and check their email and grab the code but where's that code sitting at if I go inside and I look at the response in this code token it's sitting right inside the token so I can just copy this take it over here paste it in I'm long this the administrator I found this twice in the past year twice and they were on systems that used SMS text messages and I you know I had I had the cell phone numbers for the people that I was doing the test for and so I I took the cell phone number and I

could have found the cell phone number even if I didn't have it I took the cell phone number plugged it in okay got the got the code put that in there and on the other end the person that I was working with the developer he receives the text message and about 30 seconds later receives a picture from me of me logged in is him and immediately I get the text back and I was just waiting for it I'm like just sitting there waiting for it like we need to talk immediately right so we did and this is a problem I found in two different applications over the past year just simply because when you look when a developer looks at this

and when other I mean almost anybody looks at this they see this right here and it doesn't sh jump out at them that there's something there's something sensitive in there that no one else should see and then even when they do look at it they're like well it's just going to the user that owns it right not thinking about this other the way that the system works and it can lead to flaws like this okay so these are three of my favorite vulnerabilities I love finding these things love missing love I love it when I see an application using Json web tokens because these are things that people just don't think about okay how much time do I have I got 20

minutes awesome that I'm not going to conclude yet okay let's actually jump to a section I didn't think I was going to have time to talk about yes sure I won't be able to tell you

anyway yeah yeah those are homegrown homegrown apps so they wer no they were they built themselves yeah and and Frameworks don't do this for you anyway right the using jws are things that you're mostly going to be developing yourself I'm I guess there may be package solutions that employee jwt's right um like almost kind of following Google's guidelines of how to do open ID connect with them and there's probably a library involved in that as well so yeah that's possible but in most cases when you're seeing these types of systems there A lot of times are homegrown

yeah because both apps were vulnerable to it well here's the interesting thing the one developer there was a developer from the one app the company that that wrote the one app that was working at the company of the new app so potentially could have been the same guy same mindset in it okay because these were two they were they were kind of Quasi Partners but their development teams were separate and one guy did make the jump at one point in time I'm I'm not going to throw him under the bus I've made these mistakes too but as soon as I showed him what happens he's like oh my gosh I know exactly what I forgot

to do I got to encrypt the token of course you go encryp the token you're good to go okay so I do have a few extra minutes so let's talk a little bit about that encryption piece because this is actually kind of fun um so we when we back we talking about missing signatures okay and then if the signatures Miss Even if the signatur is not missing you should definitely check to make sure the signatures are being tested properly okay so missing sign signature verification is just the beginning it's just the beginning once again there's a link to the RFC if you want to check it out but reading through it there were four things that stood out to me four

points number one is the implicit wording all the way throughout the RFC tells you that the Jose header parameters okay which is the thing that's responsible and actually this is an ex bull that says this the Jose header parameters are user controllable the Jose header parameters are also the ones that describe the cryptographic operations and all the inputs into the cryptographic operations so that tells you right away the user controls the cryptography and the inputs to how that cryptography is applied that's immediately it's kind of like well that sounds like a really bad idea okay well here's the third thing because even if a developer reads that and says okay that may be what the spec say but that's not

what I'm going to do sorry you can't do that because the operation or sorry the specification requires all implementations to process the Jose header they have to understand and process it as the user provides it any variation from that now makes you RFC non-compliant okay and then the last piece the last kind of icing on the cake here is they must be processed in the manner defined by the specification using all of the old and dated algorithms and stuff that it talks about okay so this this whole all four of these pieces together end up creating a really bad situation almost kind of like a perfect perfect storm for cryptography with regards to jwt's okay so sign so signatures

libraries that are total RFC compliant the signatures that they create can be exploited by a myriad of different things that started way back in 2015 and it's still going today as as I mentioned a couple different things that were that were released at black hat there's one called the non- algorithm if you've never heard of the N algorithm the spec usually actually says just put in the algorithm none and we won't calculate a signature that's controlled by the user so if if the library spec compliant you can forge tokens all day long self signing a Json web using a Json web key so there's something in the specification that says hey we'll sign it and you can actually provide the key

that we'll that that we'll that we'll sign it that we'll check the signature for so you sign it with your own key give it the key and it'll use the key you gave it to check the signature awesome right so you could use that to completely bypass signature verification and Forge tokens then there's some odd confusion between between how RSA works so um like the Google open ID connect they use a publicly AA they they take their public CT and they put it out on the internet and the way that this whole system works is you go out and and or you will provide a signed token that was signed with their public key and then

they have the you go out and pulled out the public key obviously sign the token pass it in they'll validate the signature with the private key but there was a confusion issue in the spec where you could actually go down and pull their public key down like you would sign the token but then instead of passing it in telling it it's RSA you pass it in and tell it it's just using HS 256 or 512 whatever an hmac basically a symmetric and it would actually then just use the public key on it end to check the signature so you basically just create this almost the similar to the similar to the self- signing but you're using their public SE to sign it

and then telling them to use their public C to check it okay so there was a confusion there and then tons of other crypto stuff because crypto is not aged D for JWT since that spec was created back in 2015 okay and and the real the rub here is that fixing any of these things causes your implementation of it to be non compliant with the specification which is supposed to be one of the things that we like about JWT that that that they are a specification that we want to comply with okay so what happens is is you have you have developers that are using libraries that um in most cases nowadays when you're typically if

you're going to be implementing JWT or you're testing an app that implements jws they're using a a library that's no longer SP compliant because that's the way they've been fixed they've gone and been fixed I I don't I hardly ever see these vulnerabilities anymore simply because the libraries are on top of it they fixed their stuff but now their libraries are no longer spec compliant so regardless when I'm testing an app if they're using jwt's I make that assumption in my head and just say what if the developer is using a library that's 100% total spec compliant and and and makes all these things available to me well when it is I'm going to check for

those and actually Bert makes it pretty easy to do so I don't know if any of you ever messed with this before but JWT editor actually provides these attacks and so if I go back and look at our ID token here and we should be at this point in time signing things right yeah so it's not working and I still have the admin email address in here there's this little attack button and that allows you to conduct the embedded attack the non signature attack the key confusion attack signing it with an empty key something called psychic signature which is one of it's too complex for me I'm not real smart when it comes to crypto

stuff so I don't get into the deep stuff and that's beyond my understanding and then the ability to embed collaborator tokens which is really odd too because there's this other thing inside the specification that allows you to provide a URL for where the key is does anybody remember oh what was the old school PHP vulnerability where you could the the include Lo uh there's like local include and then there's you guys know what I'm talking about the file incl lfi and RFA remote file include it's basically remote file include vulnerabilities for jwt's you just say hey go to this URL and pull down the key that I put there and then check that for signing but the

cool thing about that is is now the server is visiting that URL which becomes what vulnerability server side request forgery yeah so you can use and then there's another one which is called there's a kid claim which is supposed to be an ID for a key and if the server is storing keys in a database or in a file or something the key ID is what tells the server go look up the key based on this ID well if it's on a file then you're looking at path reversal if it's on a database you're looking at SQL injection depending on where if it's in an XML file you're looking at xxe so you've got tons of injection

vulnerabilities possible and this is only if the spe at at the library you're that they're using is actually compliant with the specification all these things become available to you but there's just so many cool things that you can do with JWT is that we can sit here and do demos forever okay but just know that burp does give you the ability ility to automate some of these attacks here and burp does a or Port swier does a really good job of of walking you through these within their their web Security Academy so I highly encourage you to go check that out it's really good stuff okay so now I think I'll conclude sounds like a good time to do

it right all right so the JWT specification allows for a whole lot of pitfalls right um and there I did get a chance to mention a lot more tack vectors than I anticipated doing but there's even more beyond that um this great quote by I think Tai dang is his name not even really sure but if crypto standers give users enough ropes they're going to hang themselves and JWT gives you a bunch of ropes like a whole bag of ropes right you got a whole bag of ropes to hang yourself with um a lot of damage can done with a tool that isn't fully understood right and I think that's demonstrated best by the substitution vulnerabilities and stuff

that we talked about and here it's like you know I'm going say oh this drill looks like a great toothbrush you know it just doesn't work out very well for you it makes a mess so there's that and then just understanding that there are component they're not going anywhere so if you're not fully you know if if you're in the testing field or you're developing you're writing code make sure you understand these things and how they can cause trouble both for you as a developer and how they can cause how they can lead to really nice uh really good fun times if you're a tester okay so uh there's some resources pwn Hub the the application we've been testing it's

a whole Suite of applications if you've never been in any of my classes um that's it's the target we use definitely check that out um there's some some good links here to some I just as I did some search on JWT those were good resources that I think are worth checking out and reading through and uh this one's actually the bottom one's actually a pretty good if you're a tester it's a it's a neat kind of Playbook on jwt's there these are some credits and attribution for some of the pictures that I used and uh this is just some information about me subscribe to my mailing list if you want to get information about blog posts I write or

classes I teach but I do I teach classes on web application penetration testing it's the only thing I do I don't try to be a jack of all trades I do one thing and I do one thing I'm a one trick pony but I'm good at my trick all right that's like that's what I tell my clients I'm like they're like hey will you do this net pen test I'm like no I won't because I only do one thing I do it good but I only do one thing all right so um I do I train on I train on web app pen testing um I do web app pen testing if that's a service that you are

interested in I also do development stuff okay so if you've got um particularly in the area of security if you need help remediating vulnerabilities that you don't fully understand I partner with a lot of organizations to do that as well and then I got a whole bunch of garbage up on lmaster 53.com old blog post I've been doing since like mid 2000s when I was doing Red Team stuff so are there any questions for me yes you can feel free to hit the button on the mic and that'll actually light the mic up and give you the ability to use it this is actually just can you go back to the yeah right there yep

okay both of them access yeah so so very different purposes right those are both two different ways to um manage credentials okay so the JWT is the credential and the S the session ID is also a credential where cookies come into play is how they're managed so the cookies would allow you to or they introduce the idea of implicit credential management so when you have that temporary credential set as a cookie you know the browser is always going to send it back it doesn't require any client side code or user interaction to send that cookie back when you're using explicit temporary credentials which again you can use a token as a cookie you can use

a session ID as a cookie you don't where that goes doesn't matter okay but if you're storing a session ID or you're storing a token and you're doing it explicitly you're having to store it somewhere on the client and the client side code is responsible for then taking that data and sending it back with every single request so it's explicit in that it doesn't just automatically happen and there are I could give another 15 20 minute talk on the benefit the advantages and disadvantages of both of those and that's something we dig pretty deeply into in my pwap class practical web at pen testing any other questions

yes um which one you talking about I mean either one of them are vulnerable to replay attack right because a cookie can be can be captured um can be captured off the wire just as easily as a token can be so both of them could be replayed the downside to a stateless token um and truly stateless because you can I've seen developers introduce State into a token which actually defeats the purpose of using a stateless token so that can happen but if you throw that out the de some of the disadvantages of using a token as a stateless temporary credential is there's no way to log it out right you have to use something like a timestamp

that's stored within the claim and if you saw the EXP claim um as we were looking at jwt's that tells the JWT Library hey this is the Tim stamp when it should expire that's really the only way to log a token out other than that know with a session an actual active stateful session the server can just say I'm ready to throw this thing away right now and it can delete it and any request that comes in it'll just say sorry I don't oby that thing anymore but with a token it doesn't remember anything about anyone it just receives it and says is this still valid it is I'll process it there's no way to log it

out yes say again what your biggest challeng analing applic web applications in general biggest challenge um probably the understanding the variety of standards and protocols that go into it there is a tremendous amount of things to know about web apps the developing Community is moving so quickly from one library to the next from one technology to from one design pattern to the next I mean in the past 20 years we've had four different architectural design pattern shifts and how we create web applications and all of them introduce different vulnerabilities and different behaviors that if you're not WR if you're not writing web apps it's very difficult to be a adequate security tester to test web apps um it's just critical to

understand all the different things that the developer has to do and how they think about the problem who asked the first two questions by the way I think oh sh I think she already beat street she left who asked the second one you did okay and then the third one was right there in the orange cool I got these for you the lock pit kits awesome any other questions yes

sir yeah so you talking about like macaroons and petts so I don't I have no idea what goes into introducing a new standard or how it gets ratified by ietf or how all that works so I don't I don't know why it hasn't honestly I don't because I mean Google created mecar runes right so you would think that Google would have some leverage there but how that body how That Body Works I have no idea none at all if anybody else has any input on that feel free to share but I'm clueless in that area any other questions all right I hope everybody enjoyed it I hope you took away something useful um have a great rest of

the day enjoy the conference let's hear for Tim Toms