Tanuki: Admin Account Takeover via Mass Password Update

Objective

Take over the admin account by exploiting a flaw in the password change functionality that allowed updating multiple accounts at once.

Recon

Logged in as a regular user on Tanuki, a flashcard study app. The Account Settings page had a standard Change Password form.

Captured the password change request in Burp Suite. The request body looked like this:​ {​ "username": "Seth", "newPassword": "12345678" }

The username field in the request immediately stood out — why does a password change need to specify a username? The server should already know who you are from your session token.​

Exploitation

Step 1 — Try changing username to admin directly​

Swapped "username": "Seth" for "username": "admin": { "username": "admin", "newPassword": "12345678" }

Response: 403 Forbidden — "You can only change your own password"

Step 2 — Try passing username as an array

The server was accepting a username field in the body. What if it accepted multiple values? Wrapped both usernames in an array: { "username": ["Seth", "admin"], "newPassword": "12345678" }

Response: 200 OK — "accounts_updated": 2

The server updated both accounts with the same new password.​

​Step 3 — Log in as admin Used admin / 12345678 to log in. Access granted.

Step 4 — Capture the flag Navigated to the Admin Dashboard. The flag was in the admin's email field: bug{GE6GtUA5Gj83iJXvfyag3tpXvXXtcX2g}

✅ **Flag captured.**​

What Didn't Work

• Directly setting username to "admin" → 403, server validated ownership for a single value
• The array bypass worked because the server iterated over the list without re-checking ownership for each entry​

Key Takeaway

The server checked if the first username matched the session user but didn't validate the rest of the array. Passing multiple usernames bypassed the ownership check entirely.

Fix: Password change endpoints should never accept a username parameter — the identity should come from the session token only. If bulk updates are needed, they require admin-level authorization per account.

OWASP: A01 Broken Access Control · A04 Insecure Design