This is my second write-up. You can check out my first writeup which is on Account Takeover through Stored XSS.
So let go,
I was recently hunting on private RDPs which I find through making my own google dorks. You can find them here: https://github.com/tushar-arch/Bug-Bounty-Dorks/blob/main/Bug-Bounty-Dorks.txt
I found a program that was launched only a few days ago. And I started subdomain enum and fired nuclei in the background while I go through the target manually.
I want you guys to please look into this vulnerability. i.e: Token does not invalidate after email change which is p5 according to BugcrowdVRT
We will get back to this in a while….
So, I quickly signed up on the application and went through every functionality. After getting an idea of the application flow. I prepared myself to test the main app. I quickly fired up the Burp in the background and the first thing I tested was the signup functionality.
The application should not allow these because if your email is [email protected], you own all dotted versions of your address: [email protected] And nobody can register an account on Gmail with the dotted version of your email. So the application should have not allowed me to do it. But unfortunately, it did.
So after making 2 accounts when I tried to request the password token for [email protected], it goes to the inbox of [email protected] also when I tried to change the password, due to some backend logic the password for both the accounts gets changed.
I could have reported it as it is but the impact is quite low and I don’t have any attacking scenario to show the impact to the security team. So I kept searching and thinking of an attacking scenario.
After some time the email change functionality got my eye. So, you know I what I am gonna do ?
I signed up with a temporary email and requested a password reset. Now I changed the email. But the password reset token which is sent on the temporary email can still be used to change the password.
It’s a p5 according to the Bugcrowd VRT, but here it’s not
Now things are getting interesting!!!!
So I made the attacking scenario Step by Step:
- I sign up with any email.
- I request a password reset token to the email.
- Login and change the email to the victim’s email. ie: [email protected] [ Given that victim has an account with [email protected]] as the application allows us to make the account with dotted versions.
- Now Go to the email inbox of the previous email and try to change the password.
- When I Changed the password. It got successfully changed and when I tried to log in to[ [email protected]] with the new password. I was able to log in.
What happened here is: When I changed the email to [email protected][which the application allowed me even if the [email protected] is already registered] the password token got chained to both the accounts.
I quickly made a good report with the Video POC and reported it. And after a few days, it got triaged and fixed. I was awarded $$$$.
Thanks for reading this and please ignore any mistakes.
01 November, 2021 — Reported
09 November, 2021 — Triaged
11 November 2021 — Fixed and Bounty Awarded $ 1000
Follow me on : Twitter: https://twitter.com/tusharSharma_0