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.
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 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!
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
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
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)
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.
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 😝
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.
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?
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?
I love it when u do the "WHY?"
John: “Man, I’m falling apart”
Everyone: We’ve all been there John. We’ve all been there.
Thanks for the video:D
Good one, still watching from Brazil in 2023
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!
its GREAT that you upload daily!
This for some reasons gave me a pico ctf challenge flashback that john did, it involved JWT
@18:31 you killed gunicorn again after killing it near minute 18, but you didn't kill nginx either time :D
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?
Setup tour
He already did one 6 months ago...
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
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
I hope in the future to solve things like you do, great job John!
I really liked the première! I think this will be really useful in many occasions. Thanks John!
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?
Minute 15: alg, alg, alg!!! Something you don't see the things in front of your eyes 👀😂
Great video. I learn a lot from your channel.
John this one was a bit confusing to follow, maybe next time some more slow pace. But loving this series keep on o/
Bravo maestro 👏👏👏👍
Great video as always! , much love man
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)
lol I saw python4 was like darn whyd I spend so long getting the hang of 3
Bye John👋👋Good Night!!
can we still do this without the public facing website?
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.
Edit the audio out when typing your passwords. People can interpolate the keystrokes from their frequency.
Good luck 👍
Why it contains the pk file path? is it so rediculous? i've been confused. :-), It is realy a excellent presentation.
Amazing man, you're are expert!
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
Damn should of watched this earlier would of helped tons in the hactivitycon warm up stuff today 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 :)
❤️
How do I find these machines on HTB?
Which plugin you use to check the jwt token ?
i think it is cookiemanager
@@aveon9888 That's the one.
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 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.
Ed Sheeran is amazing at infosec stuff.
Super
I like listening to Seth Rogen hacking :)
I just wonder: how old are you John ?
do analysis of asyncRAT
TOOD
We do not know how it Signet... alg: rs256 Well xD
Damn, I feel like I should never use jwt again lol
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 😝
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.
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?
:)
Lopez Deborah Brown Mary Clark Brian
Arent you doing a brain surgery just now by explaining how jwk works ? ;>