BOOK THIS SPACE FOR AD
ARTICLE ADThe above vulnerability was reported and fixed within 2 working days. The fix they implemented was that attacker cannot modify the host in the link as now the request seems like this:
See that there is now no “https://www.redacted.com/” in the request , only “/login” is there. When you sent this request the link I received was combination of the host address “https://www.redacted.com” + “/login/ + “quickLogin=XXXXXXXXXXXXXXXXXXXXXXXX”. The first and last part was automatically added by the app in the backend.
Now, here is the fun part: I still has middle part i.e. “/login” under my control means I was still able to modify it and the changes were reflecting the link received. So I thought of injecting attacker’s login code while making request from the victim’s account.
Firstly I requested login link from the attacker’s account, copied the token and modified the request to this:
Changed “/login” To “/login?quickLogin=attackers_token?ref=\”
Notice that I added attacker’s login token while requesting login link from the victim’s account.
When I sent this request, the link victim received in his mail was this:
See that the attacker’s login token is successfully added in the link. Now when victim clicks on this link, he gets logged in to the attacker’s account without knowing.
This way, I was able to exploit a single vulnerability in two different ways.
Timeline:
30 Jan 2021 : Reported account takeover
31 Jan 2021 : Acknowledged
2 Feb 2021 : Fixed and $$$
2 Feb 2021 : Reported another one
3 Feb 2021 : Acknowledged
4 Feb 2021 : Fixed and $$$
Thanks for reading.
Have questions? Reach me out at-