Attacks on JSON Web Tokens: A Comprehensive Analysis by Chesleah Kribs

[Music] thank you so much hi everyone I am so excited to be here um I again I'm chess Leah I work at Microsoft it's going to be a really fancy talk for yall um it'll probably be a little bit beginner friendly is anyone familiar with Json web tokens this is awesome aome are you guys familiar with uh some of the attacks on them okay fantastic so this might be a learning experience for some of you some this this might just be reinforcement as well if you are kind of advanced in this field I'd recommend getting a scratch Pad I'm going to be teaching you how to draw owls all right so uh I'm just going to

tell you a little bit about me my team introduction all about jots or jwt's I'm going to have you look at some insecure jot code so look at some hacks and as well you're going to draw some owls for fun so I'm ches Lea while we do have that awesome intro uh I am local to this area I am a Florida State Alum I previously worked for the federal government I'm an offensive security Enthusiast doesn't mean I'm good at it just means I enthus about it uh I'm a mentor a world traveler I love jumping off and out of things and I frequently ask how I work on the services pentest team which is honestly the coolest team I've

ever been able to work on uh yes I started in 2020 but I also previously worked for places like NASA which could be objectively pretty cool um so the services pentest team at Microsoft is probably the coolest place I've ever worked a little bit about us we are too cool um we have two teams we have the red team and the application security team the red team emulates known threat actors to achieve really cool things that I can't talk about uh we also have the application security team which I work on uh which isolates and identifies cold vulnerabilities to also achieve really cool things so something you should know from the name we work on

services within Microsoft so anything that you touch usually comes to us um anything as a user in the front end we usually don't touch but anything in the back end we do touch uh we also work jointly with the blue team and with uh threat Hunters to achieve other really cool things and if you're wondering we are hiring and I was forced to put this in but honestly we are the coolest team ever you can find us at aka.ms best team ever if that even says a little bit about us yeah so I mean it's it's a pretty good good job there so here's what I think about when I think about web security topics or even Tech topics in

general it's similar to drawing a horse or having that Game of Thrones reference where you have season 1 two and three really awesome and by by season 8 it looks like absolute trash um so I'm going to help you draw owls but in the aspect of drawing owls you're going to be learning about Json web tokens and oath and those types of topics that apply towards having these attacks in place if you're a pent tester or you use source code to pent test is going to be very useful for you I'm going to have you H look at some guidance if you're a developer which I don't know if any of you are developers in here fantastic you're going to have

some hints over here too some of them are going to be fairly repetitive I apologize but yeah so I've attempted to learn some very complex topics and what I'm going to be showing you today is just little bitsize pieces so that you can have incremental knowledge to apply this to so we're going to start out with explaining what ooth is ooth is going to be the very basics of what Json web tokens kind of has a fundamental on so I'm going to explain it in the best way I know how and I think everyone can kind of relate to this toys so we're going to have three incredibly cool actors we have a toy box we have our friends and

we have our adults let's say we have Molly who has just had and received an awesome cool Shiny Toy Box as you can see in the white your friends Molly's friends are going to see this toy box and they're going to want access to the toys within this Toy Box however un fortunately or fortunately for Molly the adults are the ones that are going to be giving access to the toys and what the friends will do is they will go to the adults or Molly's mom or dad and say hey I'm a friend I'd like to access the toys the adults are going to then say excuse me do you know my daughter's favorite color do you did you go to her birthday

party do you know anything about her and actually validate the people are who they say they are at that point they're going to be given a ticket and this is ticket is going to be the Crux of the entire presentation they're going to be giving that ticket over to the friends it's going to say here's what you have access to here's who you say you are here's who I say I am and what you should have access to the friends are then going to be giving that ticket to the toy box the toy box very important here is going to be validating that ticket what happens if that ticket is not correctly validated is the point of

this conversation the toy box is then going to Once validated send over access to the friends this is the entirety of ooth explained in a very simplified way so let's take a look at the ticket so during this conversation today I will be having interchangeable uh terms I might be saying Json web tokens I might be saying jots and I might be saying jwt's those all mean the exact same thing I might also be saying ticket or token those are also very interchangeable items so looking at our ticket we have the first part that says hey I'm a ticket very important for right now the middle part is going to be saying I've been issued this by Molly's

mom to access Molly's toy box for one minute until playtime ends and then finally Molly's mom will sign this off and say I actually am who I say I am and so right now you've learned about the jot compositions in a very simplified matter from the previous uh picture is there's going to be three particular parts of a jot it'll be the header the payload and the signature the header is the part that says hey I'm a ticket the payload is going to be I issued this from Molly's mom the audience is Molly's toy box and the expiration is some Unix time then finally the signature which you're going to be learning about is the

signature so now we're starting to draw some ows you've actually learned how to draw circles and you've learned the basics of ooth so anyone drawing which I need to give you some time for no cool so if you don't know this already you use ooth almost on an everyday basis and you probably don't even know that you're using it you use it with Facebook with Instagram you use it with your banking platforms your email providers anything like that and subtly the World Turns so let's talk about jots in the wild if you're familiar with a tool called burp Suite this might help you uh so right now I have an application that I've stood up a web application I've

signed in as a test user I have a product uh that I'd like to add that says I want to test out this feature and so what happens here is that I send this request off and at this point I ask ooth for a token this is similar to having your friends ask adults for permission then we get a response back from whatever is going to be giving us a token and this is likened to the adult sending your ticket back to your friends in this it's going to give you the bearer token which is also known as your JWT your jot inside it's going to say access token what's really important here that it consists of all of the

different pieces right so those three pieces of the composition of the jot is going to be right in there not as pretty as it once was then your friends are going to go and try to get access to whatever API or endpoint that they wanted to access in the first place so when I hit it when I hit it when I hit add product what does it actually go to and this point it's an API called to-do list I'm going to send in my authorization header with the bearer token that I received from the server from the adults for example and this is going to be likened to your friends going to the toy box then finally after validation which

you don't actually see thankfully uh but developers you will see uh this is going to be sent back and you get access and you have a 2011 created for the eventual look of this so this is just kind of the technical steps of what it actually looks like on the back end of what my team works on every single day so why do we use jots well there's a ton of different lists I'm not going to explain what each of these means that would be pointless you're going to get these slides at the end so you can look them up for yourself uh they're simple they're flexible they're stateless they're contained they're compact secure and standardize and what do we use them

for authentication session management and access control something that I didn't mention and something that's very very important to the further attacks is going to be claims claims are something that is asserted about a token so for example our ticket here that says it is a ticket but it also has a few claims in the middle that's going to be the body or the payload it's going to have an audience claim which at the bottom say says who is this token actually meant for Molly's Toy Box the issuer is Molly's mom which asks who issued this token and is it from whom I expect then as well has the expiration which is 5:00 pm today a little bit different from

after playtime but I wanted to give you a hard-coded example um and as well it also has a signature which isn't necessarily a claim but it is important in the validation process to which again the attacks that I'm going to be presenting to you is there any questions that I can answer just particularly on claims that you're not aware of yet fantastic so now we're filling in the blanks of what jots are and how they work and you can continue to draw your owls if you'd like I I see someone drawing I don't know are you drawing an owl yeah yeah so I'm gonna I'm gonna pause for your your ability to be artistic but I'm gonna go in five

seconds all right I think that was more than five seconds but okay so token validation ticket validation jot validation whatever you want to call it it is the called resources responsibility to validate every single token it receives this is important all right it validates the audience the issuer the signature and the expiration so do not expect that anything else will be validating developers please so I told you that this is going be a comprehensive analysis unfortunately I only have 40ish minutes um so I can't tell you every single attack but these are going to be pretty much the the crooks of jot attacks and it's important to note that almost all of these fall under broken

authentication it is because jots by themselves are not insecure um it's actually on how they are implemented so again going back to a call back of the slide it is how the called resource actually implements and handles those jobs so it's important also here is that broken authentication is the number one oasp common vulnerability for web applications as well as number two for web apis so this is not uncommon to see um but fortunately for you I'm going to be talking about some things that pretty simple so we're going to be talking about unvalidated signatures authentication bypass via an unvalidated issue authentication bypass via token expiry and an authentication bypass from lack of audience validation why did I choose

these well not only because they are very easy to understand they're oh yeah I have a slide for this they're quick wins for pentesters this is quite easy to find it's also quite easy if you use source code for pentest it's loow hanging fruit because as you're going to be able to find out they are single lines of code as well they're easy to fix if you're a developer but also the reason why we have these vulnerabilities is because of implementation so it's very very easy to fix and as well they're often overlooked why because sometimes when you're testing an environment and then you move it to prod you don't actually remember what you changed so it's important to know how

things work in attacking them before you actually begin attacking them and how you can actually have this practically go wrong and you've learned that jot vulnerabilities fall under broken Authentication and they're typically implementation failures you got this so what's so important about signature validation we know that a signature isn't validated if a signature isn't validated we can have authentication bypass and we know that the ticket for the toy box has these three particular components but how is the toy box actually expected to validate and verify the signature unfortunately you don't need to know this because we have libraries that will do this for you however in the aspect of learning and in the the Quest for

knowledge here I'm going to be telling you exactly what it is so let's try to sign the job if you're an adult these are the steps that you're going to go through I'm going to go through them pretty quickly because I am short on time and I know I talk a lot so we're going to have a header and a payload from here you're going to base 64 URL encode both of that and concatenate it with a period or dot that's going to be called your signing input you're then going to take that signing input and then you're going to you're going to Hash it that's going to be your hashed signing input and if you know from crypto class

cryptographic hashing is irreversible and we can't get that back so but we do know that given two inputs of the same exact Source we're going to get the exact same output back so this is what a toy box is going to do when they're going to eventually validate it but we're not done we're going to cryptographically sign this we're going to take our hash signning input and we're going to have our trusted adult come in sign that with their RSA private key if RSA is the algorithm that they choose scramble that up and finally you're going to get the cipher text that leads to the signature this is going to be the signature that you see see why I

mean it's not important to know exactly why it does this and you've learned how an issue asss a jot you're going to be starting to draw the face here okay I'm not I'm not pointing this out for you if anybody else is drawing this I'm all for it I have it in my slides for a reason so we're going to have a call back here this is where it's going to start to get a little fuzzy um so we know that a trusted issuer can sign a an issue and sign a jop but it's on the implementation to actually secure how it's used so so how does a toy box actually know what's going to be

happening here and how we know that it hasn't been tampered with we have public information to our knowledge and to our advantage we know that we have the header the payload and the signature and because our trusted adults signed it with their private key we know at this point they do have a public key that is publicly available Public Public public all right so what do we do we're going to validate that signature now as a toy box we're going to base 64 yearold to code the header and the payload segments at this point all of this is not complex whatsoever again these are going to have libraries that do it for you so please

don't do this on your own I'm going to tell you this very very often uh but you can use something like JWT IO you can also use something like JWT domms if you ever get a jot if you want to manually validate this um and at this point we didn't talk quite about this but it's the portion that says I'm a ticket um if it's says I'm a ticket and you're looking for that you're going to continue this process if it doesn't and it says uh I'm a nuisance and I'm here to cause Mayhem you're obviously going to reject it this is where it gets a little fuzzy literally um so we're going to take

we're going to redo our hash sign and input because we have the header and the payload we know that we can replicate it and hash it all over again so once we do that we have the toy box calculated hash then because we know that the adult has signed it with their private key we're going to take again that public key knowledge that we have and we're going to submit it over to what the adult originally sent to the friends from there you get the hash signing input that is decrypted from the adult and we have two particular hashes that we can think about at the end so what we want to do here is compare the

toy box calculated hash to the decrypted original hash of the adult and are they the same if they are then we know that the signature has been validated if it isn't then we know that at some point whatever point doesn't really matter that the token has been modified and you are expected to reject it so now you've learned how an application validates the jot signature and here we go again so it's important in aing your understanding on how this actually works but again please don't do this manually do not roll your own crypto it results in many different vulnerabilities as well as broken authentication which are the attacks that I'm going to be showing you I'm

also going to be showing you some net code but there are all different libraries and all different programming languages that do this for you so let's get into the text so we're going to be talking about signature validation bypass so this this is asking what if the application doesn't actually validate the signature so we have an application here we have an attacker named Eve like our good old crypto crypto class and then we also have a server so if I'm Eve and I know that an application is invalidating the signature what I can do is I can just craft a token or I can send over a request for a token the server is going to give me a legit

legitimate token back and there's nothing malicious here it's all legitimate traffic what happens now if I'm Eve what I can do is I can have my username as Eve I have permissions as right and I'm a basic role but I can tamper this token to have whatever type of authorization that I want I can then change my name to admin I can create my role as administrator I can keep my right privileges because I have access to literally anything I want so I take this uh new token that I've modified and I submit it over to the application and if you remember from my emphasis that it is the application's responsibility to validate this because

the application looks this over and doesn't actually validate whether the to whether the token is legitimate or not it sends this through and if I am attacking I can impersonate modify or elevate my privileges because why not the application isn't actually checking so this is going to seem a bit repetitive and it's a bit small so if you can't see this I will explain this a little bit more in detail if you can't uh this block of code is actually going to have every single vulnerability that I'm going to be talking about in it this is going to be net code because we are Microsoft and that's what we're familiar with working in but this is the only

block of code that you're going to have to remember today so if you're a code assisted uh pent tester or you perform pent tests or excuse me if you're a developer this is going to be extremely helpful to you if you're a pen tester in general sorry this doesn't really apply to you uh but right here you have in a block it's going to be required sign tokens is equal to false typically this is not going to be disabled but if you're a developer for example and you'd like to figure something out quickly and you want to disable validation this is what you might disable just for funsies it's a quick and easy fix uh but a quick

and easy win if you're a tester but you won't actually see this if you don't use code so again this is not live examples it's very important to tell you that um these are applications that you can intentionally make insecure um but again all programming languages have standard libraries to do all these checks for you that have secure defaults uh again while I show you net code there's something similar to Java to python which is one of my favorites uh but again some developers overwrite these for interest of time or for whatever reasons they might have to have security trade-offs which lead to vulnerabilities so some guidance for you if you're an attacker if some guidance

for you if you're a vulner excuse me if you're a developer if you're an attacker I'm going to be going through the steps Point by point and that's going to grow as we go on if you're a developer these are probably going to stay the same because not a lot of things change for you but if you're an attacker what I'd like for you to do do is I want you to identify a web application that you suspect has jot tokens uh through a proxy like burp here then you're going to remove the token from the request and check if it's actually changed if it hasn't then it's probably uh other things that might persist the session uh

but otherwise keep going if you delete some characters from the signature does it return an error fail or success seed if it has an error message or a different page then the signature is definitely being checked and you don't have a win but if it is the same the signature is not being checked so what you're going to do is then tamper the payload if you're a developer I want you to use an upto-date library for handling jots ensure po proper negative testing which means that your application is going to gracefully handle things that it shouldn't um as well do not roll your own custom authentication Library c number one as well at minimum your application

should check for Signature validation but this should be enabled by default so you learned what vulnerabilities exist in not validating signatures and you're continuing to draw an owl so I want to have some audience participation here these are pretty simple examples but I want to make sure that you're on the same page with me in our example of a toy box adult and our friends one of these parties is the issuer I think I've talked about it enough but hopefully you know that it's going to be the adult which is going to be our next attack so now we have Eve a nice young child who uh is very very nice she's a nice lady but she used to be Molly's

friend and she isn't anymore but because she used to be a friend she knows the exact way a ticket needs to be signed what shape it looks like what uh qualifications it needs to have in it and she can basically do whatever she wants to the ticket to make it look exactly like it was before she's going to go to an issuer or a ticket store in our case and say Here's exactly what our ticket looks like and at this point our ticket is going to look exactly the same except for the fact of an isure at this point the ticket looks as if it's signed from Molly's mom excuse me and what she's going to then do is unfortunately

unbeknown to Eve she's going to take this to the ticket reader that's now been installed so it's going to do things like signature validation it's going to do things like audience validation it's going to have everything that it needs to except for the fact that it's not expecting that the issuer might not be Molly's mom she's going to go over they're going to check everything and unfortunately because it's not doing issue of validation if I'm an attacker I can go and access any of the resources and try to Tamper something that I shouldn't have access to so let's talk about the lack of issue validation in the source here you can see that single line of code pretty

simple it's going I don't even see it on my screen validate issuer is equal to false I should have known that by heart but it's important to note that particularly with uh azuread uh a lot of times we call this multi-tenant but for here I have multi- issuer again multi-tenant uh might be sporadically through here but multi-tenant multi applic excuse me multi- issuer applications are intentionally designed to lose control over the issuer and this is because there might be some applications that accept input from a larger like a larger issuer so for example for our analogy this might be come into play when the entire neighborhood of parents can actually issue tickets so uh it's a feature not a

bug we like to say this is what happens when we have teams that crash every day but it's fine uh developers might miss configure this mistaking that their single tenant application or single issuer application is multi- iser so for our example ours is going to be a single tenant application there is no other issuers that should have access to Grant tickets so again if we're doing some guidance for penetration testers and some developers continuing on our workflow for attackers I would like for you to Mint a token from an attacker control R issuer and Replay that token against the application this is going to be pretty complex um but it is an attack that we can do um and this is going to

be from something that you've already previously had a vulnerability on that you know that you can access something like the STS if you're a developer on top of the things that I've already talked about do not roll your own custom authentication Library it's going to be repetitive so sorry do not disable issuer validation checks unless you are a multi-tenant application or multi- issuer application by Design and now you've learned the importance of an issuer claim in a jot and you've drawn some Talons so now we're going to be talking about expiry validation bypasses how are we doing on time good Perfect all right so here we know that the expiry validation relies on something called time

at this point your friends have access to use the toy box until Play Time ends and they can submit this toy to this Toy Box a to or token ticket however long they want up until Play Time ends or it becomes 5 o'clock today at that point that token should become NL and void however there is some developer that did not want to do this uh and they do something called a lifetime token or they disable some of the secureity checks that I've talked about Eve can come in and pick that t ticket up she can steal it she can you know just grab it from whatever request that she wants she can then replay that token send it

over to this ticket reader and because the ticket reader hasn't been updated for example for it doesn't know what time it actually is it's not in a standardize format like the Unix time uh she can then replay that token to the toy box and get access it's important to note here that a jot that never expires is dangerous because if someone steals that ticket you can always access this so again there is no normal method to revoke a non a lifetime token so do not use this but for our example we have validate lifetime as equal to false there is no expiration checks on this particular piece of code so again it's kept as a forever token

even the expiration of the token so let's say it did expire it would not invalidate the ticket because of this check right here so again continuing on your guidance I'd like for you if you're an attacker to take an expired token and then replay it against an application or an API just like how I said uh what you should do is if you have a non-expired token you can wait 24 hours that's sometimes usually the the expected equivalent of an expired token but sometimes it could be upwards to six months so this might not be the best way but if you do have an expired token already try to replay that and see what you can

do it's still a finding though if you do see that you can access this application with an expired token uh even if you can't actually get something further from this authentication bypass again don't roll your own custom authentication Library do not disable expiration claim checks and reject any expired tokens if you're a developer so now you've learned about improper expiry validation of jock claims we're going to go back to another knowledge check this time for an audience this is actually what stumped me typically when I was going through jots and learning web security uh because most of the time I thought the audience was actually who was giving the ticket or the token unfortunately it's

going to be your toy box which is going to be one of my favorite attacks so far so right now you have an audience or excuse me you have the main players typically of our analogy you have the adult you have the toy box and you have your friends this is going to go exactly how you think it is same way nothing new here they're going to your friends are going to be able to play that token against the toy box and this is normal use there's nothing malicious about this however we have a fancy new toy box and the only problem is is that this is your siblings and we don't like the siblings

that much but your friends do and so they can take that actual token that they receive for your toy box and push it onto the new toy box why is this because at this point the toy box for your sibling is not validating the audience at this point they are expecting it to come from The Trusted adult company but they're not explicitly checking the entire full claim so they do see that string trusted adult company but they don't actually see that it's supposed to go to your personal toy box so in this point in a real world scenario what could happen something like this could give users and therefore malicious attackers permissions to access otherwise inaccessible Services which is

again one of my favorite vulnerabilities when they should only be given access to certain ones we're going back to a single line of code validate audience is equal to false this is typically enabled like I said one of my favorites because it is so easy to fix but there are so many times because this is an optional claim people put this in and it's not going to be validated so just don't disable audience checks if you're an attacker again we're going to go back check if you can replay a token intended for one service to another service if you can typically you can get Privileges and access like elevation if you're a developer again not to be repetitive don't roll your own

custom authentication Library don't disable Val audience checks and reject tokens that don't explicitly match your audience claim there are sometimes that I see people and particularly with the services team that they have multiple different uh services that can run on it and because they have one particular owner they don't do explicit checks and now you've learned proper validation audience validation and its importance on security and in summary you've drawn a complete owl and I've given you an easy analogy for ooth simple checks for pent testers and developers oh yeah I'm not time uh you've learned issuer signing and application validations you've seen an authentication bypass without signature validation unless you're an MTA which is multi-tenant application by

Design uh you should validate the issuer you should set reasonable token expiration times you should Implement token revocation mechanisms explicitly check for audience claims and relied on tried and tested sdks and libraries because you don't roll your own custom authentication Library and I hope You' learned how to draw an owl and thank you so much for having me [Applause] [Music]

[Music]