How to play with JWT
Exploit JWT using JWT TOOL
Preventive Measures /Mitigation
JSON web Token (JWT) is string which is sent in HTTP request (from client to server) to validate authenticity of the client. JWT should be send when user sign in, it should contain the info of user or we can say user identity those who are using it. In case user id is changed, JWT verification will fail.
JWT are comes under RFC 7519 for representing secure and reliable communication between 2 parties like users and servers. JWT uses a combination of public and private key in X.509 certificate for signing. By using HMAC algorithm we can use JWT for shared secrets. JWT is created with secret key and that secret key i.e. private to you(user) when user receive a JWT from a client, So we can verify it by secret key.
Working: When user enters his credentials, credentials send to the server for validations. IF credentials are right server assigns a JWT token with the response of that request.
Post Requests with credentials
Return JWT token in response
JWT(Header + payload + Signature)
Response with claims
· Used to pass identity of authenticated users between identity providers.
· Information can be verified and trusted because it is digitally signed.
· By using it we can avoid querying any respective database more than once.
· More compact as compare to SAML token, so it is preferred to be used with HTML.
· We can use JWT token for authentication, authorization and Information exchange.
Structure: A single JWT token consist 3 parts, all three parts are divided by ‘.’ And all 3 parts uses “base 64 encoding”.
The three pasts are mentioned below:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 when I decoded it by Base64 format I got string in JSON format, please check it below
“alg”: “HS256”,“typ”: “JWT”
The headers contain information about the JWT configuration, such as the signature algorithm (alg), type (JWT), and key file used by the algorithm (used when the server requires multiple key files). Algorithm can be HS256, RS256, HS512, PS256, HS384 and many more. In different platform we have different algorithms.
· Payload :
When I decoded it by Base64 format I got string in JSON format, please check it below
“first name”: “testing”,
“last name”: “learning”,
“phone no”: “123456789”,
So payload part contain any data that we want to include in our JWT token because it readable so do not write any sensitive things here like credentials or key. We can add as many fields as we want but it’s good not to write more than 5–6 otherwise it will create big JWT token. It is also known as “claim” because when JWT send as a request it claims a user identity.
· Signature: This is used to validate that the token is trustworthy and has not been tampered with. You must verify this signature before storing and using a JWT.
This is the only part of JWT token which is not publically readable because it is encrypted with a secret key and the header and payload are stored in plaintext, the signature is used to prevent data from being modified. The signature of the transaction function that provides data often uses RS256 (RSA asymmetric encryption and private key signature) and HS256 (HMAC SHA256 symmetric encryption) algorithm. ,
The signature object is base64UrlEncode(headers) + ‘.’ +base64UrlEncode(‘signature’).
Playing with JWT:
· Leakage of sensitive information: Information is clearly visible when payload is transmitted from client to server.
· Modify the algorithm to none: As we discussed in Header part of JWT, there is “alg” if attacker changed “alg” value to “none” then server will not perform any signature verification.
· Modify the algorithm RS256 to HS256:
HS256: uses public key
Rs256: uses private key to sign the message and uses public key for authentication.
So when we change algorithm to HS256, code starts using public key as a secret key and with the help of public by passing of token is easy.
· HS256 (symmetric encryption) key cracking: HS256 key strength is weak, so by using brute forcing tool like “jwt-tool” we can easily guess key. If key is correct then the decryption is possible.
AIM: Goal is to get access to admin panel.
We have an application where “application is assigning JWT”. It can be possible with a JWT assigned to “admin” account only.
As in below screen shot it mentioned we have to make GET request to endpoint “token “ to get the initial token.
As we send the request to the above mentioned endpoint we get the token.
As we have already discussed different aspects of JWT token. Now we decode the JWT token we get this value.
We got “Header”, “payload” parts value but if we make changes to the token, in order to get the token accepted on the backend we have to verify it with the “signature”. Now we have try to brute force the signature to get the token. To brute force the token I used a tool named as ”jwt_tool”.
I used the “JWT_tool” in BackBox and used below mentioned command
Python3.6 jwt-py <Token_Value>
We have to select best options, I select 7 an give it default “rockyou.txt” password file as an input which is available in kali by default and you can download this too.
Note: Here we have to manually type the path of rockyou file.
And we got the key by using “jwt-tool”. Now we put this key into signature field to generate a token with the role as admin instead of guest. It was discussed in the starting that we need admin aceess.
After copying this token and updating the burp request to solve the challenge. For this I did couple of change in request.
· Change request method in POST.
· Change request endpoint to admin.
· Add Authorization Bearer header in request with updated token value.
So when we apply these changes in burp, burp request will look as shown in below screen shot.
After implementing these changes I got “Congrats ” message and access to the admin account refer to the screenshot below
By using “Brute Force techniques” with the help of “jwt-tool” tool we can easily get the secret key token is using.
Preventive Measures /Mitigation
· Always perform algorithm verification so no one can change “alg” filed to “none”.
· Always perform all validations. It is not sufficient to decrypt or validate the outermost token only and skip validation and verification of inner token.
· Always pick a strong chronological signature so bypass cannot be possible.
· Validate all possible payloads value. Sometimes attacker can get signed or encrypted token so to save these types of attacks is to only consider a token valid when both the signature and the content are valid.