Day 19: A Tale of 0-Click Account Takeover and 2FA Bypass

The researcher was testing the password reset functionality of a target website (https://redacted.com) when they discovered an email parameter manipulation vulnerability.

Initially, they attempted basic attacks like:
✔️ Host header manipulation
✔️ Brute-forcing reset tokens

However, these did not work.

Then, they analyzed the password reset request, which looked something like this:

🔍 Idea: What if the "email" parameter was changed from a string to an array?

So, they modified the request:

💡 Result: The server sent the password reset link to both email addresses!

1️⃣ The attacker requests a password reset.
2️⃣ They intercept the request and add the victim’s email alongside their own.
3️⃣ The password reset email is sent to both emails.
4️⃣ The attacker uses the link to reset the victim’s password and takes over their account.

🚀 Bug Impact: Full account takeover with zero user interaction!

✅ The researcher reported the bug, and it was classified as a critical vulnerability.

Next, the researcher analyzed the 2FA mechanism, which was enabled via Google Authenticator (6-digit TOTP codes).

Since brute-forcing the 2FA code was impractical due to:
❌ Rate limits
❌ Time-based expiration (every 60 sec)

They moved to response manipulation testing by:
✔️ Changing response values ("success": "false" → "success": "true")
✔️ Forced browsing (attempting to access the dashboard directly)
✔️ Looking for 2FA-related parameters ("2FA_Enabled": "false")

While inspecting the login request response, they noticed that the server returned sensitive information, including an API key!

📌 Exploiting the API Key

Since the researcher had already read the API documentation, they knew that the API key allowed full access to the account, effectively bypassing 2FA authentication.

💡 Impact: If an attacker had the victim’s credentials, they could access the victim’s account without 2FA, simply by using the leaked API key.