Trying to log in, the password field was locked, so I entered username=mH4ck3r0n3 and logged in:
Login
As we can see, we are given a session role set to user, which immediately made me think I should change the role from user to admin. Apparently, the session token is a JWT (JSON Web Token). By inspecting the page source:
Page Source
I found the /admin and /public-key endpoints. The /public-key endpoint contains the public key for the JWT, and from this, I can already infer that it is likely using the RSA algorithm (which is an asymmetric encryption algorithm, hence the use of public and private keys). So, instead of visiting the page, I called the getPublicKey() function in the ChromeDevTools console:
Public Key
By doing this, I obtained the public key. One of the known vulnerabilities of JWT is Algorithm Confusion. The vulnerability in this scenario concerns the management of the JWT (JSON Web Token) and, specifically, the possibility of manipulating the payload of a JWT token in order to gain unauthorized privileges (elevating the role to “admin”). The system uses JWT for authentication management. The JWT consists of three parts: a header, a payload, and a signature. The payload contains important information such as the user’s role (role), and the signature (using HMAC with a secret) ensures that the token hasn’t been tampered with. As we can see from extracting the JWT with the help of https://jwt.io:
Jwt.io
RS256 is a signature algorithm based on RSA, where the server signs the JWT token using its private key, and anyone can verify the signature using the public key. In this case, the public key is exposed via the /public-key endpoint, and the attacker can use it to verify the signature, but cannot generate the signature itself because only the server has the private key. The issue here is that the signature of the token is not correctly verified by the server. If the server does not verify the signature properly or uses a faulty verification mechanism, the attacker can manipulate the payload and create a forged token that passes as valid.
🔬 Vulnerability Analysis
Potential Vulnerabilities
Algorithm Confusion (JWT)
Token Forgery
🎯 Solution Path
Exploitation Steps
Initial setup
Once the vulnerability is understood, we move on to the exploitation phase.
Exploitation
As we have already mentioned, the server uses RS256 and expects the token’s signature to be verified using a public key (derived from a private key). If an attacker has access to the public key, they can verify the signature but cannot sign new tokens. There are several methods to sign a JWT, one of the most common being HS256 (HMAC with SHA-256), which is a symmetric signature algorithm (it uses the same secret key for signing and verification). In this specific case, the server uses RS256 to sign the JWTs but allows forging tokens using the wrong algorithm, HS256, an algorithm based on a shared secret and not a key pair (since there is no check on the validity of the JWT).
The server signs the JWT with RS256: The server uses an RSA private key to sign the JWT. This is the secure mechanism and should prevent anyone from creating fake tokens, as only the server holding the private key can sign valid tokens.
The client receives the token: When a user authenticates, the server generates a JWT signed with the private key (RS256) and sends it to the client. The client can use this token to access protected resources, such as the admin area, by attaching the token in the request headers.
Here comes the vulnerability. If the server doesn’t perform a strict check on the algorithm used to sign the token, an attacker could attempt to modify the token. Specifically:
The server might accept a JWT signed with a different algorithm than RS256, such as HS256.
With the HS256 algorithm, the token is signed using a shared secret key, but the attacker can obtain the public key from the server (the RSA public key is available publicly).
If the attacker can determine the secret used for HS256, they can create a new JWT token that has the same structure as the original token but with a modified payload (for example, changing the user role to “admin”).
So the exploit is based on:
Decode the original JWT token signed with RS256.
Modify the payload (changing the role to “admin”).
Use the HS256 algorithm to sign the token with a secret that can be derived from the public key (in a misconfigured or poorly designed setup, the secret could potentially be deduced).
Sending the forged token to the server.
Since the server does not correctly verify the algorithm used (HS256 instead of RS256), it accepts the forged token as valid. The server doesn’t realize that the token wasn’t signed with the private key, but rather with a secret that both the client and the attacker can derive.
By having a token with the role modified to “admin”, I can access the admin area of the site without actually being authorized.
This results in access to the flag. I wrote an exploit in Python to automate the entire process, and by running it, I was able to extract the flag.
Flag capture
Automated Flag
🛠️ Exploitation Process
Approach
The exploit follows exactly the process described earlier: it makes a request to /admin, passing the crafted token, and extracts the flag using a regex.
