Demo Environments Are Not Always Harmless: A Case Of Account Takeover Via JWT Secret Reuse

Demo environments are often considered safe since they contain dummy data, but they can be a goldmine for attackers. In this case, an Account Takeover (ATO) was possible due to the reuse of JWT (JSON Web Token) secrets across demo and production instances of the same application.

The Setup:

Production Subdomain: `AppName.domain[.]com` (login-only, no registration).
Demo Subdomain: `AppNameDemo.domain[.]com` (allowed account creation without email validation, reset every 24 hours).

The Attack Flow:

Identify Target: Noticed identical applications on both subdomains.
OSINT Recon: Gathered a list of potential admin emails.
Demo Account Creation: Registered accounts on the demo subdomain using admin emails.
JWT Extraction: Retrieved JWTs issued by the demo environment.
JWT Replay Attack: Tested these JWTs on the production subdomain.
Success: One JWT granted access to the production environment due to shared JWT signing keys.

Why It Worked:

The same JWT secret was used across demo and production instances.
No proper isolation between environments, allowing token reuse.

You Should Know:

How to Test for JWT Secret Reuse

1. Extract JWT from Demo Environment:

Register an account on the demo site.
Capture the JWT from authentication requests (e.g., using Burp Suite or browser DevTools).

2. Decode the JWT:

echo "YOUR_JWT_TOKEN" | jq -R 'split(".") | .[0],.[1] | @base64d'

This reveals the header and payload (though the signature remains secure if the secret is strong).

3. Brute-Force Weak Secrets (if needed):

Use tools like `hashcat` to test common JWT secrets:

hashcat -m 16500 -a 0 jwt.txt rockyou.txt

4. Replay in Production:

Use `curl` to test the stolen JWT:

curl -H "Authorization: Bearer STOLEN_JWT" https://AppName.domain.com/api/user

Mitigations for Developers:

Use Unique Secrets: Always generate different JWT secrets for demo, staging, and production.
Environment Isolation: Ensure demo environments cannot interact with production systems.
Token Validation: Implement strict issuer (iss) and audience (aud) claims in JWTs.

Bonus: Hunting for IDOR/BOLA in Demo Sites

Demo sites often expose API endpoints. Use tools like `grep` or `jq` to extract endpoints from network traffic:
```
tcpdump -i eth0 -w traffic.pcap 
```

Then analyze with Wireshark or `ngrep`:

ngrep -q -d eth0 "GET|POST"

What Undercode Say

Demo environments, though seemingly harmless, can be a critical weak link if not secured properly. Always:
– Audit JWT Implementations: Check for secret reuse across environments.
– Monitor Token Issuance: Log and alert abnormal JWT usage.
– Enforce Strict Access Controls: Even in demo setups, apply the principle of least privilege.

Key Commands to Remember:

Extracting JWTs from Traffic:

tshark -r traffic.pcap -Y "http.authorization" -T fields -e http.authorization

Testing JWT Validity:
```
jwt_tool STOLEN_JWT -T -v 
```

Forcing Logout (Invalidate Tokens):

redis-cli KEYS "jwt:" | xargs redis-cli DEL

Expected Output:

A compromised admin account due to JWT reuse, leading to unauthorized access in production. Always segregate demo and production secrets!

Relevant URLs:

References:

Reported By: Martinmarting Demo – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

Join Our Cyber World:

💬 Whatsapp | 💬 Telegram

Listen to this Post