some-image here

From Wayback Machine To Account Takeover

This write-up is going to be about an Account Takeover that i found with the help of wayback machine. This write-up will show you the importance of recon and restesting the patch. I found this bug when i was retesting the patch. So lets get started. The program i was hacking on is an e-commerce website. The website was already well tested and it also had a cloudflare so i couldnt test for injection attacks but the good thing was that the subdomains were also in scope. The program really didnt have any interesting subdomain, most of them were 403 and rest of them are static related to FAQ or empty. I got few csrfs and open redirects on main domain but they all got dup.
One day i received an email that the open redirect report is resolved which means it is fixed and i can try to bypass it. I tried to bypass it but i couldnt. There are few things i do when i get an open redirect or xss in GET parameter, i always try to do three things:

(1) i spray that parameter to other endpoint of the web application.
(2) I always look into wayback machine for old urls to see if it have same or similar parameter.
(3) Google dorks to see if i can get the same parameter in another endpoint.

So I know the parameter which was vulnerable to an open redirect, the name of the paramete was returnURL. I started with wayback machine to see if i can get new urls with the same parameter but i didnt get any new url with the same parameter. The subdomains were also in scope so i thought why not look for the same parameter in other subdomains aswell? I started looking for same parameter which was vulnerable to open redirect in wayback machines for subdomains using a cool tool gau. Luckily i got the same parameter in one of the subdomains which was something like this but when i opened that url it showed me an error of path not being found. The cool things about recon is it have alot of possibilities, like if wayback dont give you anything then you can do google dorks if they failed too you can goto github,pastebin etc and if they also dont give you anything then you can always bruteforce.

But i was in luck when doing google dorks on that subdomain i got alot of endpoints with the same paramter. The one which worked was forget password endpoint, If you request for password reset using this link then you will receive an email with password reset link which will be something like this, and using this you can reset your password which is normal. But if you're already logged into your account and open this password reset then it will redirects you to the home page. when i changed the value of returnURL parameter to "" and opened the passwod reset it redirected me to The password reset url which will redirect me to will be like this yeah i found a new open redirect. I always do screen recording of the bug before submitting it. When i was screen recording it i changed the value or returnURL to my own domain and upon openeing the link it redirected me to my domain which i was expecting.

There is something which i wasnt expecting, When i checked my server logs i saw the password reset tokens there. I didnt know how they ended up there lol. I turned off the screen recording and i tried to open that link again. This time i redirected to my domain again but i didnt get the password reset tokens in my server. I opened that password reset link like 100s of times but i didnt get the password reset tokens on my server logs. I was being redirected to my website but i wasnt getting password reset token in server logs, i was asking myself how could the password reset tokens end up in my server logs on first try? suddenly i thought of using another domain, i quickly opened hookbin website and created a new http endpoint and use that endpoint in returnURL parameter and asked for my password reset. I received the password reset link on my email and when i opened that link i got the password reset tokens on my serever, it worked!

The website only leaking the password reset tokens once for every domain. After confirming this i submiited a nice report. As expected the triagger failed to reproduced it. I submitted another video PoC where i explained and showed every step and the triagger was able to reproduce it and the report was sent to program owner and then he failed to reproduce the issue. The one step which they were missing is that you need to be logged into your account when openeing the password reset link. The program owner asked me to leak his password reset token so here are final steps and attack scenario:

1: I requested a password reset for program owner using this altered link , =//
2: Program owner recieved a password reset link on his email, which was returnURL=//
3: He opened this password reset link in the same browser where he was logged in.
4: He was redirected to which is controlled by me and i received his password reset token on my server logs.

I showed him his password reset tokens and my report was triaged as p2 and i got 800$ bounty for this report. . If you dont understand it or want to give me a feedback please feel free to reach me at my twitter or on Discord, my username on discord is Demon#1841 . If you're reading this, Thank you so much. See you in the next article.