JWT Vulnerabilities (Json Web Tokens)
Last updated
Last updated
Part of this post was taken from: https://github.com/ticarpi/jwt_tool/wiki/Attack-Methodology Author of the great tool to pentest JWTs https://github.com/ticarpi/jwt_tool
Run jwt_tool **with mode All Tests! and wait for green lines
If you are lucky the tool will find some case where the web application is correctly checking the JWT:
Then, you can search the request in your proxy or dump the used JWT for that request using jwt_ tool:
You can just tamper with the data leaving the signature as is and check if the server is checking the signature. Try to change your username to "admin" for example.
If an error message occurs the signature is being checked - read any verbose error info that might leak something sensitive.
If the page returned is different the signature is being checked.
If the page is the same then the signature is not being checked - time to start tampering the Payload claims to see what you can do!
Check where the token originated in your proxy's request history. It should be created on the server, not the client.
If it was first seen coming from the client-side then the key is accessible to client-side code - seek it out!
If it was first seen coming from the server then all is well.
Check if the token lasts more than 24h... maybe it never expires. If there is a "exp" filed, check if the server is correctly handling it.
****See this page.****
Set the algorithm used as "None" and remove the signature part.
Use the Burp extension call "JSON Web Token" to try this vulnerability and to change different values inside the JWT (send the request to Repeater and in the "JSON Web Token" tab you can modify the values of the token. You can also select to put the value of the "Alg" field to "None").
The algorithm HS256 uses the secret key to sign and verify each message. The algorithm RS256 uses the private key to sign the message and uses the public key for authentication.
If you change the algorithm from RS256 to HS256, the back end code uses the public key as the secret key and then uses the HS256 algorithm to verify the signature.
Then, using the public key and changing RS256 to HS256 we could create a valid signature. You can retrieve the certificate of the web server executing this:
An attacker embeds a new key in the header of the token and the server uses this new key to verify the signature (CVE-2018-0114).
This can be done with the "JSON Web Tokens" Burp extension. (Send the request to the Repeater, inside the JSON Web Token tab select "CVE-2018-0114" and send the request).
If the token uses a “jku” Header claim then check out the provided URL. This should point to a URL containing the JWKS file that holds the Public Key for verifying the token. Tamper the token to point the jku value to a web service you can monitor traffic for.
If you get an HTTP interaction you now know that the server is trying to load keys from the URL you are supplying. Use jwt_tool's -S flag alongside the -u http://example.com argument to generate a new key pair, inject your provided URL, generate a JWKS containing the Public Key, and sign the token with the Private Key
kid is an optional header claim which holds a key identifier, particularly useful when you have multiple keys to sign the tokens and you need to look up the right one to verify the signature.
If the claim "kid" is used in the header, check the web directory for that file or a variation of it. For example if "kid":"key/12345" then look for /key/12345 and /key/12345.pem on the web root.
If the claim "kid" is used in the header, check if you can use a different file in the file system. Pick a file you might be able to predict the content of, or maybe try "kid":"/dev/tcp/yourIP/yourPort" to test connectivity, or even some SSRF payloads...
Use jwt_tool's -T flag to tamper the JWT and change the value of the kid claim, then choose to keep the original signature
Using files inside the host with known content you can also forge a valid JWT. For example, in linux systems the file /proc/sys/kernel/randomize_va_space has the value set to 2. So, putting that path inside the "kid" parameter and using "2" as the symetric password to generate the JWT you should be able to generate a valid new JWT.
In a scenario wehre the content of the "kid" is used to retreive the password from the database, you could change the payload inside the "kid" parameter to: non-existent-index' UNION SELECT 'ATTACKER';-- - and then sign the JWT with the secret key ATTACKER.
In a scenario where the "kid" parameter contains a path to the file with the key and this path is being used inside an executed command you could be able to obtain RCE and expose the private key with a payload like the following: /root/res/keys/secret7.key; cd /root/res/keys/ && python -m SimpleHTTPServer 1337&
The following are known weaknesses that should be tested for.
Some web applications use a trusted JWT ‘service’ to generate and manage tokens for them. In the past some instances have occurred where a token generated for one of the JWT services’ clients can actually be accepted by another of the JWT services’ clients. If you observe the JWT being issued or renewed via a third-party service then it is worth identifying if you can sign up for an account on another of that service’s clients with your same username/email. If so try taking that token and replaying it in a request to your target. Is it accepted?
If your token is accepted then you may have a critical issue allowing you to spoof any user’s account. HOWEVER, be aware that if you are signing up on a third party application you may need to seek permission for wider testing permissions in case it enters a legal grey-area!
The “exp” Payload claim is used to check the expiry of a token. As JWTs are often used in the absence of session information, so they do need to be handled with care - in many cases capturing and replaying someone else’s JWT will allow you to masquerade as that user. One mitigation against JWT replay attacks (that is advised by the JWT RFC) is to use the “exp” claim to set an expiry time for the token. It is also important to set the relevant checks in place in the application to make sure this value is processed and the token rejected where it is expired. If the token contains an “exp” claim and test time limits permit it - try storing the token and replaying it after the expiry time has passed. Use jwt_tool's -R flag to read the content of the token, which includes timestamp parsing and expiry checking (timestamp in UTC)
If the token still validates in the application then this may be a security risk as the token may NEVER expire.
jku stands for JWK Set URL. If the token uses a “jku” Header claim then check out the provided URL. This should point to a URL containing the JWKS file that holds the Public Key for verifying the token. Tamper the token to point the jku value to a web service you can monitor traffic for.
First you need to create a new certificate with new private & public keys
Then you can use for example jwt.io **to create the new JWT with the created public and private keys and pointing the parameter jku to the certificate created.** In order to create a valid jku certificate you can download the original one anche change the needed parameters.
You can obtain the parametes "e" and "n" from a public certificate using:
X.509 URL. A URI pointing to a set of X.509 (a certificate format standard) public certificates encoded in PEM form. The first certificate in the set must be the one used to sign this JWT. The subsequent certificates each sign the previous one, thus completing the certificate chain. X.509 is defined in RFC 52807 . Transport security is required to transfer the certificates.
Try to change this header to an URL under your control and check if any request is received. In that case you could tamper the JWT.
To forge a new token using a certificate controlled by you, you need to create the certificate and extract the public and private keys:
Then you can use for example jwt.io **to create the new JWT with the created public and private keys and pointing the parameter x5u to the certificate .crt created.**
You can also abuse both of these vulns for SSRFs.
This parameter may contain the certificate in base64:
If the attacker generates a self-signed certificate and creates a forged token using the corresponding private key and replace the "x5c" parameter’s value with the newly generatedcertificate and modifies the other parameters, namely n, e and x5t then essentially the forgedtoken would get accepted by the server.
If the JWT has embedded a public key like in the following scenario:
Using the following nodejs script it's possible to generate a public key from that data:
It's possible to generate a new private/public key, embeded the new public key inside the token and use it to generate a new signature:
You can obtain the "n" and "e" using this nodejs script:
Finally, using the public and private key and the new "n" and "e" values you can use jwt.io to forge a new valid JWT with any information.
The JTI (JWT ID) claim provides a unique identifier for a JWT Token. It can beused to prevent the token from being replayed. However, imagine a situation where the maximun length of the ID is 4 (0001-9999). The request 0001 and 10001 are going to use the same ID. So if the backend is incrementig the ID on each request you could abuse this to replay a request (needing to send 10000 request between each successful replay).
