Hey, it’s been a long time since I published a bug bounty write-up. I was in an internship period. So, I had a lot of free time. Anyways, this writeup is about a 0-click account takeover and 2FA bypass. Let’s get started. For the sake of NDA let’s assume https://redacted.com is the target.

Account takeover:
- I started testing doing basic things like changing the host header, seeing if I can brute force the token but nothing seems to be working…(I wrote an article a while ago that had my methodology for testing the password reset functionality: https://medium.com/@fatnassifiras45/how-i-was-able-to-take-over-any-account-via-the-password-reset-functionality-ef1659f8b481).
- The request for getting a password reset link looked like this:

• As you can see that the email is getting sent to the server using JSON format in a param named email, So, I thought what if I change the type of that parameter from string to an array. So it would be like this: “email”: [“[email protected]”, “[email protected]”]. Changed the request body to that payload, sent the request, went checking both my emails and fortunately, I received the password reset link on both accounts.

Attack scenario:

• Attacker requests a password reset link, intercept that request, and change the email parameter value to [“[email protected]”, “[email protected]”]
• The password reset link will be sent to both the victim’s and attacker's email accounts therefore the attacker can use it and change the victim’s password.

I made a PoC, reported the issue and it made my day seeing a message like this from the triager:

2FA Bypass:
- Now, Moving to the 2FA mechanism. Here, I enabled the 2FA on my account using the google authenticator app. Yes, the google authenticator app so the code will be 6 digits (1 million possibilities) which would take quite a good time to brute force. Also, not to forget about the rate limit and that Google Authenticator changes the Code every 60 seconds or so. I gave up on brute force as it is not logically possible. And went to the login page put my credentials and intercepted the login request to understand the 2FA mechanism properly and test a few things including:

• Response manipulation (e.g., Change param value from false to true → “success”: “true”.
• Forced browsing (Going directly to the dashboard page in a new tab after authenticating.)
• Code Leakage in response.
• Searching for parameters like `2FA_Enabled` so maybe if I change them to false the server will redirect me directly to the dashboard.

Nothing of the above worked. So, I simply intercepted the response to the login request, surprisingly there were some keys leaked there including the API Key.

And having already read the API documentation of the target I knew how to use these keys. So, here if an attacker had the victim credentials the 2FA mechanism would be useless as the attacker can get the victim’s API Key which would give him the ability to do a lot of actions using various API endpoints.

Sometimes, you only need to take a close look at what the server returns to you :). The program was heavily tested by other bug hunters and they missed the above issues. So, never quit a program if it is already tested because everyone has his own methodology and way of thinking!

Bonus TIP to bypass 2FA: If the target allows API authentication via email and password or BASIC auth (base64Encode(username:password)), try setting up the 2FA and see if you can still authenticate to the API using only the email and password. If it is the case then you already bypassed the 2FA as most APIs will allow you to do the same actions done on the web app.

Shout-out to the dev team for their professionalism, fixing the above issues in less than 2 hours efficiently, and for the bounties :-)!

Here is my Twitter: https://twitter.com/Fatnass1F1ras, Please reach out if you have any questions.

Happy hacking!