Story of an interesting bug.

Hello again great #bugbounty community! My name is Vedant(Also known as Vegeta on Twitter😁) and I’m a cybersecurity enthusiast and an aspiring Bug hunter :) Today I’ll share you a story about an interesting bug that I found recently. This write-up will be much shorter compared to my other ones but I’m confident that you will enjoy it. So let’s get started,

Little bit about the target:-

My target was a private program and I’m hunting on this program for about a month now. I pretty much done all the recon about the target and already found some really great bugs such as reflected XSS, Blind XSS, SSRF, information disclosures and Stored XSS(This bug is the highest severity and the best one that I’ve found so far. Will surely do a write-up about it soon.) Let’s call it target.com

The Discovery:-

So one day I was just going through all the screenshots of the subdomains of target.com and noticed one subdomain which had a signup page so I opened that subdomain. This subdomain had a customer portal application so I just created an account on it and then started enumerating all the functionalities.

I tried to find bugs like XSS, open redirect, SSRF, IDOR but unfortunately nothing worked. Then I just said to myself that ‘Well if I can’t find high severity bugs, I should try finding low hanging bugs here.’ and started finding bugs like improper session handling and no rate limiting.

I visited the forgot password functionality hoping to find the no rate limiting bug. First I requested one reset password link just to observe the token. I opened the reset password mail from the target and saw that the application provided me a new password which was just random 8 digit password, this was very new to me as I saw such behavior for very first time. Then I just tried to perform the no rate limiting attack on that reset password function and tried to repeat the request 88 times and surprisingly there was no rate limiting in place and I got 88 reset password mails from the target. Well I was happy that at least I found a bug on this subdomain, after some time I just tried to login on that portal with the password that I copied from the first reset password link just to see if I can do it and I wasn’t able to login. After some time I copied the password from the very last reset password mail and tried to login and I was logged in!

So the funny thing here was with every reset password link the user’s password was changing and to make it even worse the application had no rate limiting on forgot password functionality and hence due to this there was a situation like account lockout as that user can’t login with his old password and his new password is changing with every password reset request😂. I was like,

😂😂😂

I was laughing while writing the report and also mentioned in the report that ‘Due to this weird behavior a simple bug like no rate limiting has a huge impact now’😂.

Hope you enjoyed reading this, if you have any doubts regarding this you can contact me here.

Until next time, good bye and keep laughing.