JSON Web Tokens Vulnerabilities and Exploitation.

Hi all…. My self Dishant(dk9510) , and here i will teach you how to find vulnerabilities in JSON Web Tokens or JWTs, so lets start.

What is JWT?

source google.

image taken from Portswigger web security Academy.

• JSON Web Token (JWT) is a compact, URL-safe means of representing
  claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.
• JSON web tokens (JWTs) are a standardized format for sending cryptographically signed JSON data between systems. They can theoretically contain any kind of data, but are most commonly used to send information (“claims”) about users as part of authentication, session handling, and access control mechanisms.

JWT Format:

3 parts : HEADER, PAYLAOD and SIGNATURE separated by dot(.)

1. eyJraWQiOiI5MTM2ZGRiMy1jYjBhLTRhMTktYTA3ZS1lYWRmNWE0NGM4YjUiLCJhbGciOiJSUzI1NiJ9. HEADER
2. eyJpc3MiOiJwb3J0c3dpZ2dlciIsImV4cCI6MTY0ODAzNzE2NCwibmFtZSI6IkNhcmxvcyBNb250b3lhIiwic3ViIjoiY2FybG9zIiwicm9sZSI6ImJsb2dfYXV0aG9yIiwiZW1haWwiOiJjYXJsb3NAY2FybG9zLW1vbnRveWEubmV0IiwiaWF0IjoxNTE2MjM5MDIyfQ. PAYLOAD
3. SYZBPIBg2CRjXAJ8vCER0LA_ENjII1JakvNQoP-Hw6GG1zfl4JyngsZReIfqRvIAEi5L4HV0q7_9qGhQZvy9ZdxEJbwTxRs_6Lb-fZTDpW6lKYNdMyjw45_alSCZ1fypsMWz_2mTpQzil0lOtps5Ei_z7mM7M8gCwe_AGpI53JxduQOaB5HkT5gVrv9cKu9CsW5MS6ZbqYXpGyOG5ehoxqm8DL5tFYaW3lB50ELxi0KsuTKEbD0t5BCl0aCR2MBJWAbN-xeLwEenaqBiwPVvKixYleeDQiBEIylFdNNIMviKRgXiYuAvMziVPbwSgkZVHeEdF5MQP1Oe2Spac-6IfA SIGNATURE

This is how decoded Paylaod from JWT TOKEN is looks like

{
    "iss": "portswigger",
    "exp": 1648037164,
    "name": "Carlos Montoya",
    "sub": "carlos",
    "role": "blog_author",
    "email": "carlos@carlos-montoya.net",
    "iat": 1516239022
}

In most cases, this data can be easily read or modified by anyone with access to the token. Therefore, the security of any JWT-based mechanism is heavily reliant on the cryptographic signature.

JWT Signature.

The server that issues the token typically generates the signature by hashing the header and payload. In some cases, they also encrypt the resulting hash. Either way, this process involves a secret signing key. This mechanism provides a way for servers to verify that none of the data within the token has been tampered with since it was issued:

• As the signature is directly derived from the rest of the token, changing a single byte of the header or payload results in a mismatched signature.
• Without knowing the server’s secret signing key, it shouldn’t be possible to generate the correct signature for a given header or payload.

Where JWT is Used.

Mostly JWT Token is used in Session-tokens, API tokens for Authentication and Authorization of the user. when user logged in the server will generate an Signed JWT token to the user who logged in, and use it as session token for the authentication purpose.

JWT Attacks.

user send modified JWT to server so that can bypass access control on the server, or privilege escalation or Account takeover

We have use full tools for manipulating JWT Token

JWT Editor Burp-Suite extension which is very usefull on analysing the token, editing and exploitaion.

jwt.io : these is also alternative for JWT-Editor, for viewving, signing, and exploitng jwt misconfiguration vulnerabilty.

Finding and exploiting JWT vulnerabilities.

For finding these type of vulnerabilities we need to do manual approach and needs to check for all possible misconfiguration, one-by-one

Exploiting Flawed JWT Signature Verification

• the server is not store any information about the jwts that they issue, token is entirely self-contained entity. since the server doesn’t know the signature and contents of token, we can make arbitrary change in token and forge the token to server.
• eg. here we can change the isAdmin paramenter to true to got the admin privileges.

{
    "username": "dk",
    "isAdmin": false //change this to true,
//re-encode the token and send it t server
}

Server accepting arbitrary Signature

• signature is present on the token but server is not verifying the signature with orignal signature, we can temper the token, re-encode and send to server in order to exploit them.

Server accepting Tokens with no Signature

• “alg” parameter of jwt -header tells the server that which algorithum used to sign the token, we can sign jwt using “none” algorithum , servers usually reject tokens with no signature. However, as this kind of filtering relies on string parsing, you can sometimes bypass these filters using classic obfuscation techniques, such as mixed capitalization and unexpected encodings. JWT editor > Attack > None sign.

Brute-Forcing the Secret keys used to sign using HS256 alg.

• Some signing algorithms, such as HS256 (HMAC + SHA-256), use an arbitrary, standalone string as the secret key. Just like a password, it’s crucial that this secret can’t be easily guessed or brute-forced by an attacker. Otherwise, they may be able to create JWTs with any header and payload values they like, then use the key to re-sign the token with a valid signature.
• we can use Hashcat to bruteforce signing secret key.

Hashcat hashcat -a 0 -m 16500 jwt wordlist

https://github.com/wallarm/jwt-secrets/blob/master/jwt.secrets.list common jwt secrets list.

• once the key is identified, we can temper the payload of the JWT Token and resign the token using “found secret key”

JWT Header Parameter Injection.

Acc to JWS only alg parameter is mandatory, but in practise jwt headers (JOSE headers) contain several parameters such as

• jwk : JSON WEB KEY - Provides an embaded JSON Object Representing key
• jku: JSON Web Key Set Url: Provides a URL from which servers can fetch a set of keys containing the correct key.
• kid: Key ID - provides an ID to Key so that server can identify correct key , since there are multiple keys present

Injecting Self-Signed JWTs Via the jwk paramter

{
 "kid": "ed2Nf8sb-sD6ng0-scs5390g-fFD8sfxG",
 "typ": "JWT",
 "alg": "RS256",
 "jwk": {
    "kty": "RSA",
    "e": "AQAB",
    "kid": "ed2Nf8sb-sD6ng0-scs5390g-fFD8sfxG",
    "n": "yy1wpYmffgXBxhAUJzHHocCuJolwDqql75ZWuCQ_cb33K2vh9m"
    }
}

Ideally, servers should only use a limited whitelist of public keys to verify JWT signatures. However, misconfigured servers sometimes use any key that’s embedded in the jwk parameter.

we can exploit this using signing modified jwt with our own generated RSA private key and then embading matching public key in jwk parameter.

• generate new rsa key in JWT editor extension.
• modify paylaod of jwt
• attack > embaded JWK

Injecting Self-signed JWTs via jku Parameter

instead of embading public keys directly using the jwk header paramter, some servers let you use jku (JWK set URL) , header parameter

here is example of how json object looks at remote url. https://someurl.com/jwks.json

Some time JWK Sets are exposed to publicly via Standerd Endpoint such as /.well-known/jwks.json

{
    "keys": [
        {
            "kty": "RSA",
            "e": "AQAB",
            "kid": "75d0ef47-af89-47a9-9061-7c02a610d5ab",
            "n": "o-yy1wpYmffgXBxhAUJzHHocCuJolwDqql75ZWuCQ_cb33K2vh9mk6GPM9gNN4Y_qTVX67WhsN3JvaFYw-fhvsWQ"
        },
        {
            "kty": "RSA",
            "e": "AQAB",
            "kid": "d8fDFo-fS9-faS14a9-ASf99sa-7c1Ad5abA",
            "n": "fc3f-yy1wpYmffgXBxhAUJzHql79gNNQ_cb33HocCuJolwDqmk6GPM4Y_qTVX67WhsN3JvaFYw-dfg6DH-asAScw"
        }
    ]
}

More secure websites will only fetch keys from trusted domains, but you can sometimes take advantage of URL parsing discrepancies to bypass this kind of filtering

• Modify the payload of jwt.
• Inject “jku” header paramter in JWT header, and put signed public key in your-server.com/jwk.json in above mentioned format.

 "kid":"somr hex of kid of key",
"jku":"https://ourserver.com/jwks.json"

• sign the token with our generated private key and send to server. if server is misconfigured we success fully exploit this, else not vulnerable to this attack.

How to prevent JWT Attacks

• Use Up-to-date library for JWT handling.
• implement Robust Signature verification on received JWTs, and account for edge-cases such as JWTs signed using unexpected algorithms.
• Enforce Strict White-list for permitted hosts for jku header parameter
• always set expiration date for tokens
• Enable the issuing server to revoke tokens on logout. etc

reference: portswigger-web security academy

Twitter: DK_9510.