Every time, every video, I learn... I learn a TON. I earned my CS degree in 2012, which is for all intents and purposes, one complete stage of evolution of the field. I missed streamlined AI/ML, as they were all electives that required department approval. I also missed in depth server side scripting such as JSON, but we DID do a lot of PHP and our main focus coding wise was C++. We learned nothing pertaining to pentesting or security measure beyond solutions offered in a basic web portal when one purchased hosting. We did an oddly large amount of assembly, as well. I've learned more about security, malware, and generally understanding what you present here than a 4 year degree. You are awesome and have a forever subscriber.
Why does Jwt allow this behaviour ? I mean there should be some strict content Policy like "JWT" can only be checked to a domain which it is used by or something, everything else is really stupid isn't it ?
If I understand you correctly, you are asking why the system is using a "random" source for verification. The answer is that it is kind of the point of the concept JWT. the service that is using JWT would host the "key" itself, the service could be using the good old session ids. The point of JWT is to have authentification and service seperated. The domain with the service trusts the authentification service and simply checks if the token is valid using the public key from the authentification service and the signature from the token. In this case, the service was coded to use the "jku" in the token which makes sense if you have multiple trusted authentification services (think authentification via google, facebook, ...). But the service failed to check if it trusts the jku in the first place. (My understanding could be wrong or incomplete)
The problem is that typically that well known endpoint is just set on the server side (therefore would always verify against the correct keys). This vulnerability was allowing the user to not only provide the jwt… but also how to verify the jwt (well known endpoint in the token)
because it is not supposed to be in the header for user to change, you cannot trust the header for that information. Instead, it should look up the jwks_uri through .well-known/config endpoint before using it for verifying signature
I don't get it, what was the vulnerability? This type of authentication surely isn't supposed to fall apart essentially from just setting "user=admin" inside a cookie.
The vulnerability is that it was allowing the token to dictate how it verified the signature…. Basically… tell me who you are and tell me how to verify that. I should know how to verify without you telling me.
Depending on how the check is setup on the server side you might just have been able to create a new token with username: admin. Not all apis check the signed part only that the jku matches
Actually super helpful to me. I have to use JWTs and I didn't understand them at all. This helped so much and allows me to avoid a pitfall of them as well.
Was thinking the same 😂 John has used ngrok multiple times before, so not sure why he opted to use his prod server this time 😆 I may have done the same thing though 😝
I have been studying networking for the last month and I still have Zero clue what he does with these videos but I am DETERMINDED to figure it out so I can not only follow him on videos but also Solve these problems myself!!! Thanks for the video! loved your cast on HTB battelgrounds and here's hoping for more!
this is so weird to me lmao. this jku field makes like no sense to me and seems sooo insecure i hate jwt. i guess it's like supposed to be used with a whitelist? but what's even the point?
JWT is really not secure enough for me. When John breaks so fast into - I never want to use JWT. So I still use php-session - That is more secure ; I think. ^^ Thanks for the video.
Do check out JWE for additional security of JWT. My advice is to go stateless, simple & easier to scale. Storing session on the server side I guess is fine for a nonscaling web app.
John: “Man, I’m falling apart”
Everyone: We’ve all been there John. We’ve all been there.
Thanks for the video:D
@18:31 you killed gunicorn again after killing it near minute 18, but you didn't kill nginx either time :D
Setup tour
He already did one 6 months ago...
I love it when u do the "WHY?"
Every time, every video, I learn... I learn a TON. I earned my CS degree in 2012, which is for all intents and purposes, one complete stage of evolution of the field. I missed streamlined AI/ML, as they were all electives that required department approval. I also missed in depth server side scripting such as JSON, but we DID do a lot of PHP and our main focus coding wise was C++.
We learned nothing pertaining to pentesting or security measure beyond solutions offered in a basic web portal when one purchased hosting.
We did an oddly large amount of assembly, as well.
I've learned more about security, malware, and generally understanding what you present here than a 4 year degree. You are awesome and have a forever subscriber.
hows it going now?
This for some reasons gave me a pico ctf challenge flashback that john did, it involved JWT
Why does Jwt allow this behaviour ?
I mean there should be some strict content Policy like "JWT" can only be checked to a domain which it is used by or something, everything else is really stupid isn't it ?
If I understand you correctly, you are asking why the system is using a "random" source for verification. The answer is that it is kind of the point of the concept JWT. the service that is using JWT would host the "key" itself, the service could be using the good old session ids. The point of JWT is to have authentification and service seperated. The domain with the service trusts the authentification service and simply checks if the token is valid using the public key from the authentification service and the signature from the token. In this case, the service was coded to use the "jku" in the token which makes sense if you have multiple trusted authentification services (think authentification via google, facebook, ...). But the service failed to check if it trusts the jku in the first place. (My understanding could be wrong or incomplete)
That's pretty much it. This can actually be seen as a "feature" but the server blindly trusted whatever was there
I dont understand how the JKU can be changed to anything so easily, whats the vulnerability?
The problem is that typically that well known endpoint is just set on the server side (therefore would always verify against the correct keys).
This vulnerability was allowing the user to not only provide the jwt… but also how to verify the jwt (well known endpoint in the token)
John this one was a bit confusing to follow, maybe next time some more slow pace. But loving this series keep on o/
whats the main takeaway? how come the jku location can be changed to anything? please talk about what the vulnerability was here - just human error?
because it is not supposed to be in the header for user to change, you cannot trust the header for that information. Instead, it should look up the jwks_uri through .well-known/config endpoint before using it for verifying signature
Weird question... was the "rogin" screen sanitized?
I don't get it, what was the vulnerability? This type of authentication surely isn't supposed to fall apart essentially from just setting "user=admin" inside a cookie.
The vulnerability is that it was allowing the token to dictate how it verified the signature….
Basically… tell me who you are and tell me how to verify that.
I should know how to verify without you telling me.
lol I saw python4 was like darn whyd I spend so long getting the hang of 3
Depending on how the check is setup on the server side you might just have been able to create a new token with username: admin. Not all apis check the signed part only that the jku matches
Edit the audio out when typing your passwords. People can interpolate the keystrokes from their frequency.
Actually super helpful to me. I have to use JWTs and I didn't understand them at all. This helped so much and allows me to avoid a pitfall of them as well.
I enjoy these ctf videos so much! Thanks for the content John, keep these daily uploads!
I like listening to Seth Rogen hacking :)
Python4... I just stared into the eyes of the future!
By the time python4 rolls around, maybe people will have stopped using python2 - Maybe :p
probably not lol
2:27 your chrome is outdated. lmao 😂
you are missing some important security updates !!
I know that issue..
you should install a json viewer extension for chrome :)
its GREAT that you upload daily!
Arent you doing a brain surgery just now by explaining how jwk works ? ;>
Jones Melissa Williams William Rodriguez George
Was I the only one who was screaming: use ngrok?
I was thinking it
Was thinking the same 😂 John has used ngrok multiple times before, so not sure why he opted to use his prod server this time 😆 I may have done the same thing though 😝
can we still do this without the public facing website?
I have been studying networking for the last month and I still have Zero clue what he does with these videos but I am DETERMINDED to figure it out so I can not only follow him on videos but also Solve these problems myself!!! Thanks for the video! loved your cast on HTB battelgrounds and here's hoping for more!
Hey, it’s been a year since you made this vow, how’s it been going since then? Have you made some progress in your learning thus far?
Lopez Deborah Brown Mary Clark Brian
I find it hard to believe that you would find a live app that would accept a key from an arbitrary domain. Vetting the signer should be a basic task.
Why it contains the pk file path? is it so rediculous? i've been confused. :-), It is realy a excellent presentation.
Minute 15: alg, alg, alg!!! Something you don't see the things in front of your eyes 👀😂
this is so weird to me lmao. this jku field makes like no sense to me and seems sooo insecure i hate jwt. i guess it's like supposed to be used with a whitelist? but what's even the point?
Damn should of watched this earlier would of helped tons in the hactivitycon warm up stuff today lol
What a browser extentsion you using?
Was going to comments the same! Want to know as well!
Cookie editing one? It's called EditThisCookie
You can also edit cookies directly in Chrome without any extensions by going to Dev Tools (ctrl+shift+I) -> application tab -> cookies
Good one, still watching from Brazil in 2023
We do not know how it Signet... alg: rs256 Well xD
TOOD
Damn, I feel like I should never use jwt again lol
Ed Sheeran is amazing at infosec stuff.
what problems could this cause from a dev stand point? How can I prevent this? Thanks for the content.
Vett the signing key. Know where it comes from.
This is a dumb exploit to be vulnerable to-very basic.
I really liked the première! I think this will be really useful in many occasions. Thanks John!
Great video as always! , much love man
I just wonder: how old are you John ?
Bye John👋👋Good Night!!
I hope in the future to solve things like you do, great job John!
How do I find these machines on HTB?
Great video. I learn a lot from your channel.
do analysis of asyncRAT
Amazing man, you're are expert!
Super
Bravo maestro 👏👏👏👍
Which plugin you use to check the jwt token ?
i think it is cookiemanager
@@aveon9888 That's the one.
Good luck 👍
:)
❤️
JWT is really not secure enough for me. When John breaks so fast into - I never want to use JWT. So I still use php-session - That is more secure ; I think. ^^ Thanks for the video.
JWT is secure when configured correctly
Do check out JWE for additional security of JWT. My advice is to go stateless, simple & easier to scale. Storing session on the server side I guess is fine for a nonscaling web app.
Look I know he does the whole process with us and all but sometimes it's like hold up hold up how'd we get here???
HIS SO SMART BRO, MAN'S JUST