Accidental Bounty Part 2

Not a funny title, I know…😆😆. Well, we’ll be continuing the story of previous blog today. If you haven’t read it yet, please visit https://medium.com/@DarkShooter/accidental-bounty-cd9d903396bb.

After submitting that bug, I thought of doing further testing on the target. I found a login page and signed in to it. While going through the requests (captured in burp) I found an interesting URL, something like this https://example.com/test/auth_token?id=1x332d.

My interest piqued here, I tried making changes to id parameter but it always redirected me to error page. Next was trying the forgot password functionality. Using which I received reset password URL on my email which looked similar to the request above. And testing ‘id’ gave me error again. It was like going to one page just with 2 different approaches🤦‍♂️. This time, I thought of using google dorks to look for something juicy. I tried some dorks but nothing turned up, at which I thought of checking robots.txt file what all can’t be crawled. There was a interesting item exp_authentication_token (expired authentication token) which gave me the idea of using the reset password URL again. This time it redirected me to different URL https://example.com/test/exp_auth_token?id=af23rjn where it said ivalid id and an option to resend the reset password again. Clicking which it asked to enter complete email id. But it also showed the starting and ending letter of email with service provider eg t******0@gmail.com. This time I tweaked the dork I was using previously and so final dork looked like this site:example.com inurl:expired_auth_token and it gave 2 interesting URLs. The URLs were similar to previously mentioned one and hence partial user email id was revealed. This was not very sensitive data but still something is better than nothing.

I also noticed that no matter how many time I use reset password URL it always knew which id is required. That is the exp_auth_token value was matched with one particular email id. This was somewhat serious, as per best practices this shouldn’t happend. If you noticed something robots.txt was trying to prevent the same URL from being crwaled but some time down the line someone changed either robots.txt or parameter name being used in URL which resulted in the exp_auth_token being crawled.

It was a low security issue as nothing major was being shown but still was an issue. Hence a small bounty of 50$ was awared😁.

Thank you all for reading. Have a nice day!!