Exploiting JWT Vulnerabilities

Hello! Welcome back to our course on penetration testing and bug bounty hunting.

In our previous lesson, we thoroughly examined the anatomy of a JSON Web Token. You learned how to deconstruct a JWT into its three core components: the header, payload, and signature. We established that the signature's primary role is to guarantee the token's integrity, not its confidentiality.

Today, we're taking the next logical step: breaking that integrity. This lesson focuses on the learning outcome: Exploit JWT vulnerabilities such as weak secrets, algorithm confusion (alg=none), and signature stripping. We will explore three common but critical implementation flaws that can allow an attacker to bypass authentication, escalate privileges, and take over user accounts. These are fundamental skills for any web application pentester.

1. The Root of the Problem: Trusting User Input

All the vulnerabilities we'll discuss today stem from a single, classic security mistake: the server implicitly trusts metadata sent from the client. Specifically, the server trusts the alg (algorithm) parameter in the JWT header. As you'll see, an attacker who can control the algorithm used for verification can often bypass the signature check entirely.

2. Attack #1: Signature Stripping via the none Algorithm

The JWT specification includes an option for an unsecured JWT where the alg parameter is set to none. This means the token has no signature. While intended for situations where the token's integrity is verified by other means, if a server's JWT library is misconfigured to accept tokens with alg: "none", it creates a critical vulnerability.

An attacker can simply take a valid JWT, decode it, change the payload claims (e.g., set "admin": true), modify the header to {"alg": "none"}, and resubmit it without a signature. The server, trusting the header, would "verify" the token by doing nothing, granting access based on the forged claims.

As demonstrated, the practical steps are:

1. Intercept a request containing a JWT.
2. Send the request to a tool like Burp Repeater.
3. Decode the JWT's header and payload.
4. Change the alg value in the header to none (case-insensitivity might also work, e.g., None, nOnE).
5. Modify the payload claims as desired (e.g., change user ID, role, etc.).
6. Re-encode the header and payload.
7. Construct the new token by joining the modified header and payload with a dot, and then adding a final dot but omitting the signature entirely.
8. Send the modified request with the forged token.

This is often one of the first things to test for when you encounter a JWT.

3. Attack #2: Cracking Weak Symmetric Secrets

When a token uses a symmetric algorithm like HS256, both the server and the token creator use the same single secret key. If this key is weak, guessable, or a default value, an attacker can brute-force it.

Once an attacker discovers the secret key, they have complete control. They can create and sign tokens with any payload they wish, making them indistinguishable from tokens generated by the server.

How to Brute-Force a Secret

You can use tools like hashcat to perform an offline brute-force attack. Since this doesn't require sending requests to the server, it is fast and stealthy.

The process is straightforward:

1. Obtain a valid JWT signed with HS256 from the application.
2. Save the full JWT string to a file.
3. Use a tool like hashcat with a wordlist of common secrets (like the one from jwt.secrets.list mentioned in the article, or even rockyou.txt).
   • The command is: hashcat -a 0 -m 16500 <your-jwt-file> <your-wordlist-file>
4. If hashcat finds a match, it will output the secret key.
5. With the secret key, you can now use a tool (or a script) to forge a new token with a modified payload and sign it with the cracked key. Websites like jwt.io are also great for this; you can paste the decoded parts and the secret, and it will generate the new signature.

4. Attack #3: Algorithm Confusion (RS256 to HS256)

This attack is more subtle and powerful. It exploits a flaw in how some libraries handle tokens signed with asymmetric algorithms (like RS256) versus symmetric ones (HS256).

Here's the breakdown:

• Normal RS256 Verification: The server signs the JWT with its private key. To verify it, the server uses the corresponding public key. The public key is often made available to clients (e.g., at a /.well-known/jwks.json endpoint).
• The Attack: An attacker takes a token signed with RS256, changes the alg in the header to HS256, and then signs the token using the server's public key as the secret.
• The Flaw: When the misconfigured server receives this token, it sees alg: "HS256". It now expects a symmetrically signed token. The library's verification function looks for the secret key to use. Instead of its private key, it fetches what it thinks is the right key for this token—which is the public key. It then uses this public key to validate the HS256 signature.
• Since the attacker also used the public key to sign the token, the signature verification succeeds.

The key steps for this attack are:

1. Obtain a JWT from the target that is signed with RS256.
2. Find the server's public key. This is often exposed at a well-known endpoint like /jwks.json, /certs, or may be hardcoded in client-side JavaScript files.
3. Modify the JWT's header, changing the alg from RS256 to HS256.
4. Modify the payload claims as desired.
5. Sign the new token using the HS256 algorithm, providing the server's public key as the secret.
6. Submit this forged token to the application.

Conclusion

You've now learned three powerful techniques for exploiting JWTs by attacking the signature verification process. These are not theoretical attacks; they are found regularly in bug bounty programs and penetration tests, often with high impact.

Key Takeaways:

• Signature Stripping (alg=none): A simple but effective attack where you tell the server there is no signature to check. Remember to remove the signature part of the token.
• Weak Secrets: For symmetric algorithms (HS256), a weak secret is a fatal flaw. Use tools like hashcat to crack them offline.
• Algorithm Confusion: A more advanced attack where you trick the server into using its public key as the secret for a symmetric signature check.
• The fundamental rule for developers is: never trust the alg header from a client-side token. The server should always enforce a specific, expected algorithm.

Next Lesson Preview:

We have focused on attacking the authentication token itself. In the next lesson, we will shift our focus to a different class of vulnerability that exploits ambiguities in how servers process HTTP requests. You will learn to identify and exploit HTTP Request Smuggling vulnerabilities, a powerful technique used to bypass security controls, poison web caches, and access internal systems.