How to Hack JWT using Burp Suite?

What is JWT (JSON Web Token)?

JSON Web Token (JWT) is an open standard (RFC 7519) 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 can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.

Signed tokens can verify the integrity of the claims contained within it, while encrypted tokens hide those claims from other parties. When tokens are signed using public/private key pairs, the signature also certifies that only the party holding the private key is the one that signed it.

JSON web token are mostly used as an authorization mechanism. As the JWT contains certain claims, these claims can then be easily used to determine what kind of access the user has and what type of resources they are permitted to access.

Structure of JWT

JSON Web Tokens consist of three parts separated by dots (.), which are:

• Header
• Payload
• Signature

Therefore, a JWT typically looks like the following. The header and payload are base64 encoded strings.

xxxxx.yyyyy.zzzzz

Header

Header usually consists of elements type which specifies the type of token, alg which specifies the algorithm used to sign the token.

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload

This part of the token consists of all the claims. Claims are statements about an entity (usually the user). These claims help to identify the user as well as the access level of the user. There are typically three types of claim

• Registered Claim: Predefined claims which are not mandatory but are recommended eg. iss (issuer) or exp (expiration time)
• Public Claim: These can be defined at will by those using JWTs. But to avoid collisions they should be defined in the IANA JSON Web Token Registry or be defined as a URI that contains a collision resistant namespace.
• Private Claim: These are the custom claims created to share information between parties that agree to use them and are neither registered nor public claims.

Signature

A signature is used to verify the integrity of the token i.e., whether or not the token has tampered. To calculate the signature, attach the header with the payload and then sign it with the algorithm specified in the header.

Example, For HMAC SHA256 algorithm, the signature will be created in the following way:

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

How does JWT works

1. The user makes a POST request with the set of credentials.
2. The credentials are then verified.
3. If valid, the server responds with a JWT.
4. Now for all the subsequent requests made, the JWT is sent either as an Authorization header or in cookies.
5. The server verifies the signature of the JWT, and determines the access level using the claims in the JWT.
6. The server sends the response with the requested resource and information.

Type of Vulnerabilities in JWT and How to Find those Using Burp Suite

The JWT implementation suffers from various misconfigurations, which, if not considered, could result in vulnerabilities like account takeover, privilege escalation, SQL Injection, and many more. This section defines various vulnerabilities in JWT implementation and how to identify as well as exploit them using the Burp Suite extension JWT Editor

1. No signature verification: Usually, JWT libraries provide different methods to verify and decode the token. So there may exist the possibility that the developer directly decodes the token before verifying it. In this scenario, any signature would be valid, and an attacker can tamper the claims inside the token to impersonate another user. As the signatures are not verified, the claims become true, and this would result in account takeover and privilege escalations.

Exercise Link : https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-unverified-signature Here attacker needs to escalate privileges to admin user. There is no check for valid signature in this exercise

Step to reproduce

• Login into your regular user account.
• Make a request to /my-account endpoint and intercept the request using burp and send the request to the repeater.
• As you already installed JWT Editor, the repeater contains the tab JSON Web Token. Click on it, edit the claim sub to value administrator, and send the request. As the signature is not validated and the token is being decoded directly, the claim will be deemed valid, and you will be able to access the admin account.

Check out how you can perform the above steps Video POC

2. None Algorithm: JWT allows a number of algorithms that can be used to sign the token. The type of algorithm used is specified in the header part of the token in the element named ‘alg.’ There exists an algorithm called None, which accept token without any signature. This was originally developed for debugging purposes. 

If the implementation is vulnerable and accepts none algorithm, an attacker can easily change the token’s algorithm to none and tamper with the claim to impersonate some other issues. Once the server receives the token and supports the none algorithm, the token, without a signature, will be deemed valid, and any claim will be considered true.

Exercise Link : https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-flawed-signature-verification Here attacker needs to escalate privileges to admin user. The server supports none algorithm

Steps to reproduce

• Login into your regular user account.
• Make a request to /my-account endpoint, intercept the request using burp, and send the request to the repeater.
• As you already installed JWT Editor, the repeater contains a tab JSON Web Token; click on it. Edit the alg value to none and change the sub value to the administrator. Once done, strip the signature from the token till the last trailing dot (the trailing dot should be present in the token).

Check out the Video POC

The algorithm HS256 (HMAC+SHA-256). This is a symmetric key algorithm, meaning the same key is used to encrypt and decrypt the token. This key is called a secret key and should never be leaked.

There are situations where the key used may get leaked or can be easily brute-forced. In such a scenario, if the attacker possesses a secret key, they can make the changes in claims and sign the resultant token with the secret key. Once the token is sent to the server, the same key is used to verify it and give access to the resource.

Exercise Link : https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-weak-signing-key Here attacker needs to escalate privileges to the admin user. The alg is set to HS256, and a weak secret is used.

Steps to reproduce

• Login into your regular user account.
• Make a request to /my-account endpoint, intercept the request using burp, and send the request to the repeater.
• Copy the JWT token and, using hashcat, crack the secret key. The command hashcat -a 0 -m 16500 jwt-token-here wordlist-here can be used to crack the secret. You can use rockyou.txt or this wordlist.
• Once you have the secret key, visit jwt.io, paste the token, edit the claim you want, and paste the secret key to sign the token. Use the resultant token to get access to the account you want.

Video POC

4. JWT Header parameter Injection (JWK Embed): 

There is a header parameter called JWK, that servers can use to embed their public key directly within the token in JWK format. A JWK (JSON Web Key) is a standardized format for representing keys as JSON objects.
The server should only verify the signature using a specific set of keys, but a vulnerable server can use the keys embedded into the JWK parameter to verify the signature. This behavior can be exploited easily by creating an RSA private/public key pair, signing the token with the private key, and supplying the public key in the JWK parameter. The server receives the token using the key in this parameter to verify the signature, providing access to the resource requested.

Exercise Link : https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-jwk-header-injection Here attacker needs to escalate privileges to an admin user. The server is misconfigured and uses the key in jwk header to verify the signature.

Steps to reproduce

• Login into your regular user account.
• Make a request to /my-account endpoint, intercept the request using burp, and send the request to the repeater.
• Go to the JWT Editor Key, click on the New RSA key, and click on generate. This will create a new RSA key pair.
• Go to the repeater tab and change the claim inside the payload to the user you want to impersonate.
• Click on the attack, select Embed JWK, and select the key from the prompt. This will sign the token with the private key and embed the public key in the header parameter jwk.
• Use the resultant token to access the victim’s account.

There is a header parameter called jku which contains the URL from where the server can fetch the key to verify the signature. Now some servers only fetch these keys from URLs they trust.

However, if checks are weak or not present, the attacker will directly reach the specific URL from where it can fetch the keys. The attacker can generate a new RSA key pair, make the changes in the payload claims, sign the token with the private key, and host the public key on the URL they control. Once the token is sent to the server, the misconfigured server will verify that token using the key hosted on the attacker’s controlled URL.

Exercise Link : https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-jku-header-injection Here attacker needs to escalate privileges to the admin user. The server is misconfigured and uses the URL in jku header to fetch the key and verify the signature.

Steps to reproduce

• Login into your regular user account.
•  Make a request to /my-account endpoint and intercept the request using burp and send the request to the repeater.
•  Go to the JWT Editor Key, click on New RSA key, and click on generate. This will create a new RSA key pair.
•  Right click on the key after creation and copy the public key as jwk . Paste this key in the following keys array and host this at a remote server.

{

    “keys”: [ ]

}

• Change the kid with a kid on your key, and create/ replace the value of jku parameter in the header with the URL hosting your key. Make the changes in claims you want to change, click on the Sign button at the bottom, and select the key you have created. This will sign the token with the private key whose public key is present as the URL mentioned in jku element.
•  Use the resultant token to access the victim’s account.

Video POC

6. KID Header parameter Injection (Path Traversal): kid header parameter is used to identify the key used to verify the signature as the server may contain multiple cryptographic keys for various purposes. There’s no specific format for using this parameter.

It can be a numeric value, a UUID, a database value, or even a file. If the parameter is vulnerable to the path, the traversal attacker can use this to point to any file on the system to verify the signature. This can be exploited to point to /dev/null, which returns null and is equivalent to signing the token with a null byte. In this way, an attacker can change the kid value to point to this file, make changes in claims, and sign the key with a null byte. For this to be successful, the server should support a symmetric key encryption algorithm.

Exercise Link: https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-kid-header-path-traversal Here attacker needs to escalate privileges to the admin user. The server is vulnerable to path traversal in the kid parameter

Steps to reproduce

• Login into your regular user account.
•  Make a request to /my-account endpoint and intercept the request using burp and send the request to the repeater.
•  Copy the JWT token and paste it on jwt.io. Change the key parameter to ../../../../../../../dev/null and make the change in the claim you want. Sign the key with the empty string.
•  Use the resultant token to access the victim’s account.

Video POC

As JWT supports multiple algorithms and this can cause issues if the developer assumes that they will only receive the token with one specific algorithm. If there is an assumption that the token will be RS256; the verification process is implemented for public key verification, and the server supports HS256, as will this result in an Algorithm Confusion attack.

In this case, when a token with an algorithm set as HS256, the server will interpret the public key as the secret key to verify the signature, and as the public key is available publicly, this will lead to bad results. This means that an attacker could sign the token using HS256 and the public key, and the server will use the same public key to verify the signature. The only cause of worry for this attack is the format of the key stored on the server. Both should be identical for the attack to work.

Exercise Link: https://portswigger.net/web-security/jwt/algorithm-confusion/lab-jwt-authentication-bypass-via-algorithm-confusion Here attacker needs to escalate privileges to an admin user. The server supports HS256 and is vulnerable to confusion attacks. Here we assume the key at the server is stored in format X.509 PEM file.

Steps to reproduce

• Login into your regular user account.
•  Make a request to /my-account endpoint and intercept the request using burp and send the request to the repeater.
•  Now you need to obtain the public key of the server. This can be done using two valid tokens and using docker run –rm -it portswigger/sig2n <token1> <token2>; this will give the public key in X.509 PEM file or visiting endpoints likes /jwks.jsonor /.well-known/jwks.json, which contains the key in jwk format. Copy the key, visit the burp tab JWT Key Editor click on New RSA Key, and paste the key. Click on the PEM button and copy this key. Paste the key in encode tab and encode this base64. Copy the base64 value and go to JWT Key Editor and click on New Symmetric Key, click on generate and replace the value of element k with base64 string and save this key.
•  Go to the repeater tab and make the changes in payload claims of the token, change the alg to HS256, click on the sign button at the bottom and choose the new key you created.
•  Use the resultant key to access the victim’s account.

8. KID Header parameter Injection (SQL Injection): Kid header parameter is used to identify the key used to verify the signature, as the server may contain multiple cryptographic keys for various purposes. There is a not specified format for this parameter. This can be a numeric value, a UUID, a database value, or even a file. If the key is in the database and vulnerable to SQL Injection, then changing the key to “kid”: “aaaaaaa’ UNION SELECT ‘key’;–” and signing the token with the secret key will result in access to the resources.

The “x5c” (X.509 certificate chain) Header Parameter contains the X.509 public key certificate or certificate chain [RFC5280] corresponding to the key used to digitally sign the token.
The certificate or certificate chain is represented as a JSON array of certificate value strings. Each string in the array is a base64-encoded (not base64url-encoded) DER [ITU.X690.2008] PKIX certificate value. The certificate containing the public key corresponding to the key used to digitally sign the JWS MUST be the first certificate.
In order to exploit this implementation, an attacker can easily create an x5c certificate key pair, make the changes in payload claims, replace or create the x5c header with the public key and sign this token with the private key. Once the server receives the token and is vulnerable to this implementation and doesn’t verify the issuer of the certificate in that case, the signature will be verified, claims in the payload will be deemed as true, and access to the requested resources will be granted.

To create key use the following commands

openssl req -x509 -nodes -days -newkey rsa:2048 -keyout privatekey.pem -out issued.crt 
openssl x509 -pubkey -noout -in issued.crt > publickey.pem

Paste the token in jwt.io and use the keys to modify and sign the token.

If there exists no claim for the expiration of the token, then the token can be repeatedly used without any issues to get access to resources. If the token gets leaked due to some other existing vulnerability, then even if the user changes the password for the account, the attacker would still have access to the victim’s account.
Conclusion:
Most the websites nowadays use JWT tokens; if implemented correctly, they provide strong security and safeguards against any tampering and are self-contained, very quick, and efficient. However, due to the above-mentioned misconfigurations, it is also considered a good attack surface while exploring the authentication and authorization vulnerabilities. If successful, these, more often than not, lead to critical/high-severity vulnerabilities and are worth looking for.