The Hacker's Guide to JWT Security by Patrycja Wegrzynowicz

[Music] hello everyone my name is Patricia ving Tsun Ovid and today I'm gonna tell you about some issues with security of JSON web tokens briefly about myself I've been doing professional software development for over 20 years I've always been close to code and I'm still trying to keep that way my interest focus on patterns and anti patterns in software along the way how to improve software quality I work on tools for automated software detection and refactoring of various software defects related to security performance and databases so basically security vulnerabilities are my daily job what am I gonna talk about today first a brief introduction to JSON web tokens just for all of us to be on the same page and page and when it comes to basic Nolan terminology the key part of the talk involves four demos that reveal some security problems with the spec the implementation of token libraries and some problems with other applications and there are a number of caveats which concern JSON web tokens and we'll start with the first difficult difficult thing about JSON web tokens how to pronounce it because I've heard various pronunciation like JWT as a Polish native speaker I pronounce it Yatta but the correct way is taught let's take a look at the spec the suggested pronunciation is like English word chart I will do my best to pronounce it correctly to be conforming to the spec and when we are at the spec let's take a look at the definition it's quite a lengthy one to cut it short we usually use dots to represent a self-contained session of the authenticated user and his or her roles it's a it's a set of claims that encode users usually encode users identity and users permission Plus charts are deleted digitally signed to protect their content that's an example of JSON web token we see a lot of letters some numbers and occasional dots when we take a closer look at charts it turns out it consists of three parts separated by two dots and how can we decode it it turns out that JSON web token is simply based 4064 URL encoded so each part is encoded separately when we decode it we can see plaintext of a header payload and signature signature usually is not very readable because it's usually binary content but header and payload are pretty simple to read so in in the header we usually see algorithm which is used to digitally signed a token and in the payload we see subject that's a must and some other claims like for example issued at the time when the token has been issued issuer who issued the token and expiration time well how long the token will be valid so those are the basics and now let's move to the our first demo the first demo involves the algorithm I'm not sure whether you've heard about this algorithm but basically the spec says that - Al Gore needs should must be implemented by a library one is none and the other is h2 five six so this is a very important algorithm as by the spec and what does it mean it means that it's not fine at all how can we exploit it I will show you I will show you a demo I have prepared I will post a link on Twitter I would like you to log in basically in first to register in the application so okay my twitter is young labs I'm sending the link to the demo I've already have my own account I will login this application uses charts for session management let's take a look how it looks like in this case okay so please register because I see that nobody oh I see two person registering that's great I'm waiting for more and let's take a look at at developers tools and we'll take a look at the storage because usually on the client side we store our tokens in session storage and we see here the token for my demo application so basically I would like to copy to copy the token and I will try to decode it just to take a look at the structure I will use this website it's very useful in case of quick checking and decoding we see that the algorithm use is H 2 v 2 v 6 and the subject is mysterious one I guess it's a user ID so I will try to generate a token with non algorithm some other user ID and we'll see whether aya I succeed ok let's take a look how many oh I see quite a lot of people registered I've already prepared a token with ID 7 I will show you that non token so basically that's it algorithm subject that means user ID 7 and there is no signature you see there is an empty string at the end so I will try to use this token and replace my valid token with this artificial one I just refresh the page and yes I've got the session of Zuzu if he or she on in the room those are yeah so congratulation you've been hijacked so thank you for your cooperation you see that's that's a huge problem right we trust our libraries and it turns out that we shouldn't do that of course it depends on the library here I've used I Oh JSON web token and it turns out it has a problem with API I will show you the code so the code is is here that's my verification function i used i all JSON web token i simply said signing key to my secret key and I perform pass then I checked the claims and if no exception is from I assume it's fine and the problem is with the API because this library has two functions or even more the public function it has passed and the other one is pass claims jws so the other one checks whether or not the token has been signed this one doesn't allows for non tokens those unsecured tokens so that's the problem and actually I found this problem during code our deeds and pen testing of real-world applications so it happens in real world as well so check your application whether they are vulnerable or not so this is the problem with the spec it allows for non algorri it was an assumption that after the token has been validated you can use those unsecured tokens so that was the assumption of the spec writers however it turns out that you face the public public Internet it's not that safe anymore so you need to put a lot of attention to make your code secure plus another problem is clean api of the library ok the sample on the webpage is fine because it shows the example of parse claims signed however I found on some open source projects that the authors used to disperse function which is insecure when it comes to non-elderly so those are two problems plus this is the problem of us developers because we need to put a lot of attention and a lot of knowledge to find the right way to implement our security mechanisms another problem another library which had the same problem you see here a security issue from national vulnerability database that's the perfect source to check out your libraries and find out whether or not they have some vulnerabilities so I recommend I highly recommend for all of you to go and check your your libraries because you see this vulnerability has been discovered in only just last year so it's pretty fresh there are more libraries which have API problem this one has this issue with path versus parse claims secure another library it provides two functions the code and verify the code just simply does base64 decoding and verify only verify verifies fully signature so if you are new to a library you use the first function which fits your purposes and it must be a wrong one it might be a wrong one the best practices in this case includes that we do during the verification step we should require a specific algorithm and a specific key obviously we should understand our job libraries and check out national vulnerability database to discuss a potential vulnerabilities in tools we are using why to require specific algorithmic key because this is not the only problem in the libraries here you see another example of a security vulnerability from national vulnerability vulnerability database it turns out that one library accepted tokens normally the library allowed for RSA tokens signed with the private key and verified with public key however a hacker could provide drafted token which has been signed with h moksha algorithm but we use using public RSA key usually public keys can are less protected and can be available to hackers so hacker tried to trick library to use a different algorithm during verification but the key which has been configured on the server side so only the verification of the algorithm and the key could and protect against such problems and another algorithm and key problem from the security database and from last year it turns out that the spec of charts allows to provide a key in the header so basically a hacker could generate alkie a sign with this key the token and provide a key to the library to the server site in the header and it turns out that there was library not J's library which allowed for such an attack scenario but basically take a look at this piece of text the vulnerability vulnerability is due to following the spec so yeah the spec is not always the best thing to follow okay so I've mentioned that the spec requires to algorithm-- us be implemented by libraries nun and HS 2 5 6 so let's take a look at HS 2 5 6 it turns out that our tokens our tokens use exactly this algorithm I real or just to generate a new token because I would like to crack it um okay so there are a lot maybe not a lot but there are a few libraries good password crackers or they call themselves passwords recovery tools ok so you lose I will use one of those password recovery tools hash card Harshad is sever fine tall because it uses GPIOs so using TPO we can crack the password very very quickly if you have a couple of very high performing GPUs you can achieve like a couple of billions hashes per second so that's a huge number of course my computer is not that fast so I use slightly weaker password and okay we will see how long it takes to crack this password okay it's still waiting but basically you see that on my computer and my GPU which is not the best it takes like five million hashes per second and when we recover the secret key we can use it just to sign a new token and to impersonate another user right and take a look at that this is simple brute-force attack oh it happened already so yeah the password is pretty obvious that works we will try to use it in a moment so basically when you perform did this was a very simple configuration with brute-force attack and take into account that in case of JSON web tokens we don't need to connect to external server we do it totally offline so we need only one token and we can experiment with this token on other machines we don't warn the server side we don't connect to the server side in case of password cracking we need to connect to the power to the server side right in this case we don't need to so it's pretty comfortable so the password is des Voges so again I will use this chart I all like worry no page okay I will change the algorithm to hs2 five six now I will impersonate you for thirteen and I will provide the sacred because I know it now this should generate a perfectly valid token which will be accepted by the server side we will see in a moment okay now to refresh yep very readable test user who is that is the test user on the side okay I guess that no it was one of the first users know there are a lot of test users okay so basically you see that we if we discover the secret we can do anything what what we want okay so let's move on you see that's my computer even on my computer it was pretty performant if you have a desktop computer with really fine GPU it would be really very very fast so the problem here was this we use quite weak key it was only six characters long but the problem also is that all those alkaloids are pretty complicated there are many algorithms so when we as developers for the first time we try to implement charts we simply go for the simplest solution right we find some example on the net we try to make it working and we don't have much time to think about security and actually which we should be at least familiar with basic algorithms and properties so for charts we have four families of elderlies each mark wish with RSA with Shah and elliptic curves and probabilistic signature schema both with Shah those two lasts our beliefs are not supported in JDK you need to use an external provider like bouncy castle to use them however both of them are pretty good when it went when it comes to cryptography so let's start with H mark sweet the key property of this algorithm is that it requires a short key so this is a symmetric algorithm when we discover this key it can be used by a hacker to forge and see prepare totally different tokens so when it comes to key sizes as well as a roof of tamp we should pick a short key as long as the length of the hush so for HS 2 5 6 it should be at least 32 bytes minimum so my six characters was definitely too short on the other hand when you are when you are choosing this algorithm your system you should be about you should be aware about scalability why because in terms of scalability you have many machines each of them must verify tokens so each of them must store this secret shared key right and this is just a larger attack surface because one central compromise means that the entire system is compromised so you you could think about a symmetric algorithm like RSA so with a symmetric algorithm you have like public and private keys authentication server or servers use private key and verification servers or others can use only public keys so it's much but when it comes to large infrastructure the single point of security Feli failure however the verification is slightly slower especially the longer key you'll have the slower for application and the key size is recommended for RSA it's at least 2 K bits 2 K bits okay so let's move to our third demo it's a packet sniffing okay so I will once again I will need your help first I will okay that's my remote session okay so I'm now I'm on the external server I will run TCP dump TCP dump just allows to sniff all TCP traffic I've configured my TCP dump tour to just capture the request coming to the port 80 and plus I I've added filtering by power just to capture my to capture yours not mine tokens okay so oh I was about to ask you to refresh the pages and I see that totals are coming and pretty fast okay oh oh and I need tea okay I need to stop my discipline down because I need to I need to copy one of those tokens okay I have a lot of them plenty to choose from and okay so again it's a pretty now I'm Antoine Antoine are you who you are over there thank you you are very lucky to be picked from so many tokens so you see how easy is the hijacked users session why you have access to tokens right nothing can stop here so the problem here was obviously lack of encryption so you can argue that if we use HTTPS that wouldn't happen no I I would not be allowed to sniff your pockets however think about all those vulnerabilities in open SSL TLS and cetera so HTTPS is not that secure as well however it is getting better of course and the other problem is token say Jackie stolen tokens can be freely used the hacker can simply use a replay attack and we can't do anything right so and think about your expiration times if you have like a very long expiration times like a couple of colors or or even worse a couple of days or 30 days that's a long time span during which a hacker can reuse the stolen tokens and we play the with any requests comes to in any request come to the to their minds okay so now we can switch to HTTPS and I will show you exercise to steal token so basically this application is also available over HTTPS so let's switch to HTTPS version okay I can log in and you see here that oh yeah someone found out my password lucky I was I was thinking whether or not anyone will find that out the password was very very simple password as simple as that so I was pretty sure that all of you will try that out so Marwick are you here yeah yeah thank you good job yeah Malik is here but I will I will update that I will update that with with that attack I will show you the full line so basically this line this field is vulnerable vulnerable to exercise how can I check that I will simply write something like that ah yep thank you it's difficult to look at the under monitor okay now no it's not rigged okay I wait a moment yeah that's the most difficult part of my demo I think it collect correctly okay no not okay because I forgotten yep password cracking was a piece of cake and this one is like off okay I will refresh that and when you click my page you see that there is exercise yeah okay so now when we know that we have an exercise we will try to be more malicious than it's a simple error alert we will try to store the talk to steal the token and sent it to our evil server i've prepared i've prepared simple servlet on my evil server we just logs down all stolen tokens but again i need your cooperation so you need to unfortunately click my page okay and in the meantime i will observe the logs on my server okay the toxins are coming I'm so happy and again at the very high speed right thank you so we will try this one okay got it and we will see who will be this lucky girl guy and refresh and we have Steven Steven you have work love thank you for your cooperation without you my demos would be a failure so you see even with the use HTTP and if we have an XSS '''l application basically our application is exposed to hackers all users can be impersonated if you take a look at our attack vector this attack vector is pretty simple and common it can be used as well it cookies basically we have only one tweak here we load where evil URL into image source why to bypass same origin policy because the browser's will not allow to connect the external servers only they allow for the scene for images to be loaded from other domains or splits there are some there are some exceptions are the exceptions as well so basically that was it and we needed to prepare external server when we will stop where we store our stolen tokens and and that's it so the problem here is that we have an XSS and we have no way to block access to certain storage for JavaScript for cookies I guess that you know that we can mark cookies with flags like HTTP only which blocks those cookies from being accessed from JavaScript so cookies secured that way will not be stolen via XSS in case of certain storage there is no certain mechanism certain storage must be available to JavaScript so there is no way to block access to session storage so how can we approach this problem in terms of exercise fortunately we have modern web frameworks and usually they take good care of exercise unfortunately you again must know what you are doing because I used in my demo application I use angular and angular has really very good contextual escaping of untrusted data but in case of such things like you want for a user to configure the web page you must bypass those securities scientist ation and escaping so you see that you must you must implement some other solution to validate those potentially vulnerable fields so good library and smart usage plus good server configuration in terms of this exercise it would be very helpful to configure a good content security policy which basically will block any connection to external domain names so even though we will have XSS we will not be able as hackers we will not be able to send those tokens to our servers to the evil servers on the other hand you can think about hers and cookies as a storage mechanism or jars so it's only a storage mechanism so it's not being stateful no server-side state we just only store our tokens instead of station storage we store them in a cookie with flags like secure HTTP only and same side but and cane when we use Coke we we will go back to the CSRF problem cross-site request forgery the same sign comes in some way protects us against CSRF but again we need to in case of token stored in cookies we need to take care of Sierra's CSS CSRF another approach is recommended by OS OS stands for open web application security project is it's a non-for-profit organization which aims at increasing security awareness among software developers they have a lot of good security guys guides cheat sheets and tools so I highly recommend their webpage and there are their approach to token site jacking is to use fingerprinting what is what is that we generate random secure value we hash it and add it to as a claim to our token and roll value of the secure random value we set as a hardened cookie so we we send it through two channels one channel involves token itself and the other channel involves cooking and on the verification tariff occasion step we verify whether or not token itself is valid and we verify they took the cookie value hashed cookie value with the claim from our valid token if those two values match that's fine if they don't we have a problem and probably and for sure is some sort of an attack on our application so we can safely reject that request and in terms of basic hygiene that's pretty difficult with charts why because we have we don't have any built-in mechanisms for token revocation so and that's a basic hygiene from the security point of view that a user must be able to explicitly stop his or her session he can just log out and he can be guaranteed that's all nobody will use that session anymore with tokens is pretty difficult plus timeouts usually when we go for cookie based server-side session management we have built-in feature of inactivity timeout with tokens we don't have such an feature right we have a fixed expiration time and that's it that's why we usually go for a long long lift tokens to avoid reloading on the other hand it's not very secure because it increases attack timespan potential attack time zone so how to approach log outs the state Strikes Back we need a state on the server side we need some sort of a store to store invalidated tokens there is no other way we can use like very short-lived tokens but it's and access token refresh tokens but it's pretty complicated so the best approach is to just have a state on a server side so unfortunately it's not that easy with the stateless approach and when it comes to timeouts we should definitely use shorter token expiration time times and we can accept reloading or we can go for an approach with refreshing access tokens so basically what you've seen here it's just a tip of the iceberg so you need to be very careful in implementation of your JSON web tokens because a full-width toll is only a four right we developers can't be false we need to know what we are doing which tool is right for a given job and how to use it wisely and nobody's perfect we all make mistakes all we can do is to improve ourselves as developers so that's continuous learning right in software development we have continuous integration we have continuous delivery I often talk about continuous refactoring but the fundamental paradigm is continuous learning so let's keep educating ourselves and I hope that you have enjoyed my presentation thank you for your cooperation and now it's time for your questions you have like two minutes left or you can approach me during the break I will be happy to discuss your problems my problems would say JSON web tokens thank you you

Channel: Devoxx

Views: 11,546

Rating: 4.9220781 out of 5

Keywords: DevoxxBE, DevoxxBE19

Id: dq39w4MiZzs

Length: 48min 25sec (2905 seconds)

Published: Thu Nov 07 2019