Portswigger Labs
Lab 1: Unverified Signature
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.
Lab 2: Flawed Signature Verification
To solve this lab, delete carlos
as the administrator.
This lab said that it had a faulty signature verification, meaning I should be able to set the signature value to none
and remove the signature.
This works because if there's no algorithm used, then there's no signature expected. Thus, it is a 'valid' cookie.
Here's the exploit script I used:
Lab 3: Weak Signing Key
To solve lab, delete carlos
as the administrator. This lab tells me that there is a weak signature key used for this, meaning it is brute-forceable.
To solve this lab, let's try to crack the JWT token using hashcat
:
So the secret used to encode this thing is secret1
.
Using pyjwt
, I can create a new JWT token.
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.
Here's the contents of the cookie:
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
.
Last updated