How I Earned $23,000 by Exploiting JWT Realm and File Overwrite Vulnerabilities

Background

The target site uses JSON Web Token (JWT) for authentication. After logging into the main site a regular user receives a JWT. Reconnaissance (JavaScript analysis, Burp Suite capture, Wayback Machine endpoint collection, sub‑domain enumeration) identified an admin sub‑domain admin.test.com. Examining app.js (≈200 k lines) revealed two JWT realms: test-user for normal users and test-dashboard for the admin dashboard.

JWT Realm Tampering

Principle

Decoding a normal user token shows the claim realm=test-user. The server verifies only the JWT signature and does not strictly validate the realm claim, allowing it to be changed to test-dashboard.

Exploitation Steps

Log in to test.com and obtain a regular user JWT.

Intercept the login API request to /api/v1/login and modify the request body’s realm field to test-dashboard.

POST /api/v1/login HTTP/1.1
Host: accounts.test.com
Content-Type: application/json

{"email":"[email protected]","password":"<password>","realm":"test-dashboard"}

Decoding the altered JWT shows realm=test-dashboard; using this token logs into the admin dashboard.

Authorization Header Bearer Removal

Fuzzing Discovery

Fuzzing the admin /upload endpoint (switching ffuf to POST) uncovered the upload functionality.

Key Finding

When sending Authorization: Bearer <JWT>, removing the literal word Bearer still yields a 200 response, indicating the server does not enforce the Bearer prefix.

POST /upload HTTP/1.1
Host: admin.test.com
Authorization: <JWT>
Content-Type: multipart/form-data; boundary=----WebKitFormBoundarypxxxxxx

------WebKitFormBoundarypxxxxxx
Content-Disposition: form-data; name="destination"gallery/
------WebKitFormBoundarypxxxxxx
Content-Disposition: form-data; name="file"; filename="poc.txt"
Content-Type: Text/plain

------WebKitFormBoundarypxxxxxx--

The upload succeeds with a 200 response.

File Path Discovery

Analyzing Burp Suite history and response headers shows the returned href points to a CloudFront URL such as https://xxxxxxxx.cloudfront.net/gallery/xxxxxxxxx. The gallery segment matches the destination parameter used in the upload request. Accessing https://xxxxxxxx.cloudfront.net/gallery/poc.txt confirms the file is publicly reachable.

Arbitrary File Overwrite

Vulnerability Principle

Amazon S3, when configured to allow overwriting existing objects, permits an attacker to replace critical files. The target CloudFront domain hosts JavaScript, HTML, Windows executables, and PDF files, all of which can be overwritten.

Exploitation

Overwrite a JavaScript file to inject malicious code for stored XSS.

Replace an executable or PDF to embed a trojan.

Overwrite request (same as the earlier upload but with the malicious payload):

POST /upload HTTP/1.1
Host: admin.test.com
Authorization: <JWT>
Content-Type: multipart/form-data; boundary=----WebKitFormBoundarypxxxxxx

------WebKitFormBoundarypxxxxxx
Content-Disposition: form-data; name="destination"gallery/
------WebKitFormBoundarypxxxxxx
Content-Disposition: form-data; name="file"; filename="poc.txt"
Content-Type: Text/plain
Arbitrary File Overwrite
------WebKitFormBoundarypxxxxxx--

Command‑line verification confirms the file content has been replaced.

Key Findings

JWT realm claim can be altered because the server validates only the signature.

Authorization header “Bearer” keyword can be omitted due to lax header format validation.

S3/CloudFront default configuration permits file overwrite enabling modification of existing resources.

Systematic fuzzing uncovered these issues , e.g., the removal of “Bearer”.