This Tiny JWT Mistake = Massive Bug Bounty

Summary

This video takes a deep dive into how attackers exploit JSON Web Tokens (JWTs) to bypass authentication in modern web apps. It covers key techniques, such as tampering with algorithms, cracking weak secrets, and exploiting misconfigurations in signing methods. The presenter shares a real-world example of accessing a production site using a JWT from a dev environment due to shared signing keys. Emphasizing the importance of securing development environments, the video also touches on other token formats and session cookie vulnerabilities. Ultimately, it encourages ethical hacking with a focus on maximizing impact and finding significant security flaws.

Takeaways

• 😀 JWTs (JSON Web Tokens) consist of three parts: a header, a payload, and a signature, which are B64 encoded and separated by dots.
• 😀 HS256 (HMAC SHA256) and RS256 are the two main algorithms used to sign JWTs. HS256 uses a shared secret, while RS256 uses a private/public key pair.
• 😀 One attack method involves tampering with the algorithm and setting it to 'none' to bypass the signature verification, although this is less common in modern systems.
• 😀 A more practical attack involves cracking weak secret keys used in HS256 tokens, where developers may use default or common passwords like 'password' or 'secret123'.
• 😀 An advanced attack is algorithm confusion, where an attacker changes the JWT header to switch from RS256 to HS256 and uses an exposed public key as the shared secret to forge the token.
• 😀 Servers should always validate the JWT algorithm to prevent attackers from exploiting misconfigurations or blind acceptance of algorithm changes.
• 😀 A real-world example demonstrates how a dev environment's JWT token, which had the same signing key as the production environment, allowed unauthorized access to the production site.
• 😀 Sharing keys between dev, staging, and production environments is a critical security mistake, as it allows attackers to bypass authentication and access sensitive data or systems.
• 😀 Token reuse between dev and production environments is a common vulnerability, and attackers should explore further possibilities, such as elevating privileges or discovering hidden features.
• 😀 JWTs aren't the only tokens that can be cracked; other frameworks like Django, Flask, and Express use signed cookies or tokens that may also rely on predictable secrets, which can be exploited.
• 😀 When testing web applications, don't stop at JWTs. It's important to fingerprint the backend and identify other vulnerabilities in session cookies or framework-specific tokens for a more thorough assessment.

Q & A

What is the purpose of a JWT (JSON Web Token)?

A JWT is used for authentication and identity verification in web applications. It consists of three base64-encoded parts: a header, a payload, and a signature, ensuring the token's validity and integrity.

What are the two main ways of signing a JWT?

The two main ways of signing a JWT are HS256 (using a shared secret key for both signing and verification) and RS256 (using a private key to sign and a public key to verify).

How does the HS256 signing method work?

HS256 uses a shared secret key for both signing and verification. This method relies on HMAC (Hash-based Message Authentication Code) to ensure the data's integrity and authenticity.

What vulnerability exists when an app does not validate the algorithm in a JWT?

An attacker can modify the algorithm in the token's header to 'none,' remove the signature, and submit any payload, which could trick the server into accepting an invalid token without verifying its authenticity.

How can weak secrets in HS256 tokens be exploited by attackers?

Attackers can crack weak secrets, such as 'password123' or default values, using word lists or by scraping GitHub for exposed secrets. Once cracked, they can modify the token's payload, re-sign it, and bypass authentication.

What is an advanced attack method involving algorithm confusion in JWTs?

In algorithm confusion, attackers change the algorithm in the token header from RS256 to HS256. This allows them to use the public key as the shared secret, enabling them to forge valid tokens without needing the private key.

Why is it critical to validate the algorithm on the server side when dealing with JWTs?

It’s essential to validate the algorithm on the server to prevent algorithm confusion attacks, where the server might accept a forged token because it incorrectly uses a public key as a shared secret.

What vulnerability did the speaker find in the real-world example involving a dev site and a production site?

The speaker found that the dev and production sites shared the same signing key, allowing them to reuse a JWT token from the dev site to log into the production site and bypass authentication.

What is a common mistake developers make when working with JWTs and environments?

A common mistake is sharing signing keys between dev, staging, and production environments, which can lead to serious security vulnerabilities, such as token reuse across different environments.

How can attackers exploit signed cookies or session tokens in web frameworks like Django, Flask, and Express?

Attackers can exploit signed cookies or session tokens by brute-forcing weak secrets or predictable signing algorithms, similar to how JWTs are cracked. Tools like Cookie Monster can automate this process.