This lab fails to verify the signature of the JWT token. To solve the lab, delete carlos as the site admin.
When logged in as wiener, the first thing I observed was the JWT session cookie:
Here's the contents of the token:
I can abuse this by changing the middle portion of the cookie (payload). I changed the sub value from wiener to administrator, then base64 encoded it and placed it back in the cookie.
Note that the usage of space characters was to remove the = characters that appeared. While not actually necessary, I thought it would make the value look cleaner.
I could then access the administrator account.
Afterwards, a request can be sent to /admin/delete?username=carlos to solve the lab.
Here's a little script I made to enumerate the cookie values, then solve the lab.
Note that the pyjwt library is only usable if I'm creating 'legit' tokens. All other funny exploit methods that involve deforming the token is easier exploited using base64 encoding directly (in my opinion).
Lab 4: jwk Injection
To solve this lab, delete carlos. This lab supports the jwk parameter in the JWT header. JWK stands for JSON Web Key, which is the set of keys used to verify the validity of JWT tokens.
I noticed that this uses RS256, an asymmetric algorithm. Since the lab requires us to inject my own jwk header into the token, I can create a new key, sign the token, and then place my own public key there.
Using the JWT Editor extension for Burpsuite, I can generate a new set of keys:
Afterwards, I can head to any requests with the cookie value, and use the JSON Web Token tab.
Change the sub to administrator and use the "Embedded JWK" attack:
Sign the new token:
Afterwards, the cookie value changes to this absurdly long one:
When decoded, it gives this:
This can be scripted as usual. It's rather similar to the script in Lab 2 with base64 encoding, so I'm not going to bother.
Lab 5: jku Injection
To solve this lab, delete carlos as the administrator. I am given the exploit server. The jku header of a JWT token is a link to a valid JWKS.
Since I am given an exploit server, I can actually spoof this. After creating a new key pair in the JWT Editor, copy it JWK and store it on the exploit server like this:
Afterwards, using JWT Editor, I can inject change the kid value within the JWT header, and also the user:
Afterwards, sign the token, then use it to send a GET request to /admin/delete?username=carlos.
Lab 6: kid Header Path Traversal
To solve this lab, delete carlos. There is a path traversal within the kid parameter, which allows us to fetch the key from the file system.
Just replace this value with ../../../../../../../dev/null. Afterwards, sign this key with a new symmetric key.
Since we effectively removed the kid value, there is an empty key that is used to sign the token. As such, our symmetric key has to be an empty string:
After signing the token and changing the username, delete carlos.