In this write-up, I will explain how I was able to chain five vulnerabilities that lead to one link click account takeover.

I discovered these vulnerabilities in a private program, I will name it: target.com, Before we keep going on explaining we should consider that these vulnerabilities occurred due to a wrong application of the reset-password method via API and other internal functions.

While I was doing recon in this target, I realized that this app uses different API’s to manage functionalities and methods, So I chose to test main methods such as sign-in and reset-password methods, I wasn’t able to recognize weird implementations in the sign-in method, So I directly tried to reset my account via the reset-password method.

After resetting my account password, I realized that there is a weird “to” JSON parameter in the reset-password method request.

And after checking my reset-password email, I was able to validate that this parameter is reflecting in the reset-password link.

I made further requests to make sure the parameter is reflected in the reset-password link, And I was right.

I thought about escalating this into open-redirect which lead to leakage of the reset-password secret code, So I tried Host header injection via Host header, Referer header, Origin header, and Host injection in “to” JSON parameter value, I wasn’t able to inject my own host, This means I should find internal open-redirect in the same target host which lead to leakage of the reset-password secret code.

After testing some methods and functionalities, I was able to identify two internal open-redirects in those endpoints:

https://target.com/api/otc/login?response_type=code&client_id=web&redirect_uri=https://host/https://target.com/api/oidc/preauthorized?response_type=code&client_id=web&redirect_uri=https://host/

Those open-redirects leakages another secret code and it’s a vulnerability by itself, But I chose to escalate this into a one link click account takeover.

After injecting one of those open-redirects into the reset-password link via the “to” JSON parameter value.

I was able to redirect the reset-password secret code and other secret code to my own host by one reset-password link click via the reset-password email.

And here we are, The code in the path is the reset-password secret code, And the code in the query is the other secret code, All leaked into my host.

But wait, While I was testing the reset-password method, I was able to identify two other vulnerabilities, Those vulnerabilities made it obvious that I will be able to force the user to click on the poisoned link, Which leads to the user account takeover.

The first vulnerability is lack of rate-limiting in the reset-password request, I was able to send more than 2000 request, Which will DDOS the user email, And force him to click on the poisoned reset-password link, Which leads to leakage of the reset-password secret code.

The other vulnerability is the lack of invalidating reset-password secret code, And this means I will be able to use the reset-password secret code as much as I want, And this code wouldn’t be invalidated, This means even if the user requests another reset-password secret code and reset his password, The reset-password secret code leaked to my host will be valid and usable.

I was able to chain five vulnerabilities: Two internal open-redirect, Resources injecting in the reset-password link, Lack of rate-limiting in the reset-password request, And lack of invalidating reset-password secret code, I was able to escalate them into one link click account takeover.

Report (Nov 23rd).
First response (Nov 24th).
Duplicate (Dec 1st).