Token Validation to Server Hijacking
I have been researching on JWTs for quite some time now and what I found was that if the token verification implementation is vulnerable, then you can actually hijack the server even before a JWT token gets validated!
Well it blew my mind and reminded my of the great LangSec talk: Science of Insecurity by Meredith L. Patterson and Sergey Bratus! Btw I highly recommend you all to check this amazing talk!
So in the talk, Meredith talks about how a “Weird Machine” can arise during the input validation phase!
This was kinda cool to listen to, and I have seen such issues in binary exploitation domain where the user input messes up with the stack and the heap and leads to memory corruption issues, but I was wondering if this can happen with JWT tokens :)
And the answer is, yes it can happen!
Token Validation to Command Injection
Ruby language has this function called open which can be used to open a file (as you all must have already guessed). But it can also be used to execute system commands! Yes, you read it right… One can execute system commands using the open function, provided that the file names are not validated properly!
So now we have all the knowledge we need. Let me take you to the exploitation part :)
Let’s say a JWT token makes use of the kid claim, which contains the reference to the key used for token verification.
kid claim can contain a file path, key index, some random key id which could be used to lookup the key from some cache or db.
This approach can be tried out if the kid claim contains some reference to the key used for token verification and the backend is Ruby-based or passes user input to some command injection sink like eval/system or something else, depending on the programming language being used in the backend!
Now consider the kid claim containing path of the verification key. If this file name is passed to Ruby’s open function, and if the attacker modified the token to make the kid claim like: | nc -lvp 4444 &;#
You know what happens next right!
When a JWT token reaches the server for verification, the key file is read and passed to the token verification library. But oh no! As soon as the file is read using the open function, the attacker’s command already gets executed!
Yes, and this even didn’t required token validation at all :)
Before token validation, the weird machine that attacker created resulted in the execution of netcat listener on the backend and even though token validation failed, the attacker could have connected to the backend!
Kinda cool right!
I hope you all enjoyed this post!
Btw if you are enjoying my work and would like to support me, then please check out my Patreon page: https://www.patreon.com/SecurityGOAT
See ya!
Until next time, keep learning and happy hacking :)
