Account Takeover + A Bonus Vulnerability
Hello everyone, In the article I will explain how I was able to takeover any account of redacted.com. This attack is very much similar to Host Header Injection but app was using websockets so its a little different.
So, there was feature in the login portal by which users can login by requesting a login link to their emails means user just have to click on the link received and he will be logged in automatically without need of password.
So, when I entered my victim’s and clicked on “Send me a login link”, the websocket request looked like this:
Here you see that in the “params” there are two parameters email and a link like:
And the login link victim received was like this:
Notice that the first part of the link was same as in websocket request.
So, I modified the link to something like this:
[\”email@example.com\”,\”mycollarboratorlink.net\”] and sent the request.
Luckily the link victim received on mail was :
See that the login link has been modified to my burp collaborator link. Now as soon as victim click on this this, I will get his login code on my burp collaborator.
By using this I can easily get the login code and append it to the “https://www.redacter.com/login?quickLogin=”
This way I was able to takeover any account. Another thing is the app allows changing the email in the profile section. So after logging the victim account attacker can change the email and its PERMANENT ACCOUNT TAKEOVER.
What’s the Bonus Vulnerability??
The 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.
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-