Hacking JWT : Exploiting the “none” algorithm

Hello folks, In this article we are going to discuss how we can forge JWT tokens by exploiting the “alg” parameter in the header section of JWT. But first of all let’s have a short intro about JWT.

Photo by Setyaki Irham on Unsplash

What is JWT ?

JWT is an open standard for creating compact and self contained way of creating tokens. For example, a server could generate a token that has the claim “isAdmin” which is set to false for the normal user and provide that to a client. The client than use the token to prove their authorization that they are logged in as xyz user. The tokens are signed by server’s key, so the server is able to verify if the token is legitimate or not.

JWT is not a thing of its own, it’s define the token format and uses complementary specifications for signing and encryption.

JWS: When JWT is signed than it is called JSON web signature. It defines the process to digitally sign a JWT.

JWE: When we represent encrypted content using JSON data structures. In this article we will mainly look at JWS.

What’s in the header JWT/JWS?

• alg algorithm used for signing the the token (compulsory)
• type (compulsory)
• kid Key ID
• cty content type
• jku JWK set URL
• jwk JSON web key

For more header parameters look here : https://tools.ietf.org/html/rfc7519

The “alg” Field!!

The alg field in the header help us to determine which algorithm is used to sign the token.

Okay, Than what is the problem??

The problem arises when the libraries depends solely upon the alg field for determination of algorithm used. And the libraries used for validating tokens allows the tokens with “None” algorithm.

The None Algorithm

The none algorithm is one of the type we can set in the “alg” field. It is intended to use for the situations where the token has already been verified. Some libraries treated None algorithms as valid token with a verified signature.

As a result anyone can create their own “signed” tokens and can use whatever claims they want in the payload. This means an attacker can tamper with the payload section and can able to bypass the authorization. The impact of this can be arbitrary account access or maybe gets administrative access.

Attack Scenario

Suppose you do login to a website using your username and password. If the authentication is valid than the website will return an JWT/JWS token the response.

Note:- The website is using JWT for validating authorization. Generally RESTful service use JWT for maintaining sessionless connections.

Now from the each subsequent request the browser (client) will add these tokens in the authorization header and you can access the protected resources which are in the scope of your token.

This is how your decoded token looks like :

Now after decoding the token we can see that it contains three claims in the payload section.

Let’s create our own token- Since we don’t know the secret key used by the server to sign the the token. So we will create our own token using none algorithm.

Since the tokens are base64 URL encoded. The modified payload will look like this :

If you can see here we have added an extra claim “isAdmin:true”.

The modified payload : eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCAiaXNBZG1pbiI6dHJ1ZX0

Now let’s move on to the head section :

Here we have set the “alg” field to none.

The modified head: eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0

Forged Token:

eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCAiaXNBZG1pbiI6dHJ1ZX0.

Note:- Since the the none algorithm is used so we keep the signature section of the token blank.

Now we will use our forged token in the authorization header to and if our token is accepted this means the underlying library is accepting the token with “none” algorithm. Hence the user can bypass all the restrictions and can get the admin access on the website.

Note:- You can also tamper the user ID claim mentioned in the payload and get access to arbitrary accounts. Just look for the claims which you can temper with to bypass authorization.

Mitigation

The JWT libraries should not depends upon the “alg” for determining the algorithm used.

1. JWT libraries can use a “algorithm” parameter in their verification function. We can hardcode the value of algorithm that the server will use. Like is HMAC SHA256, than the server will only accept this particular algorithm. So it will reject any other algorithm including “none”.
2. If we want our server to support more than one algorithm, than we can use the key id “kid”. In this case a separate key can be used for each supported algorithm. JWT provides a “Key ID” field for exactly this purpose.

Let me know in the comments what you think about this article and if you found any mistake please feel free to reach out to me.

If you found this article helpful please do clap and share this with your friends. You can connect with me on LinkedIN and Twitter.