Hey, I’m Abhisek. Back with another write up. This write up is based upon my bug hunting tactics of increasing impact of information disclosure. With no further delay, Let’s start *_*
As usual, I took a program and started checking it. Generally I like looking for authentication related bugs.
Now, Look these concepts. Information Disclosure vulnerabilities allows attacker to take advantage with the leaked piece of information. If the site is using GET method requests with sensitive information in its parameters, Then the site is vulnerable for information disclosure. It is because those information could get leaked through Web logs, Referer header, and More.
Okay, Learnt a lot? Nope actually. We haven’t learnt yet, we just read it. How we practically exploit this scenario?
So now, Let’s get back to the target. I requested for a password reset on redacted.com, It sent me a reset link to my email. Copied, Turned on proxy(Ex.Burpsuite) and Opened.
Wait, before changing password look the http history. Guess what, Password reset token is leaked to 3rd party !
But wait, Even if the attacker gets the reset token. He/She will be only able to reset password and will not be knowing “email id (or) username” to login again.
Just kidding, Back to content. Again checking the HTTP requests, You know one of the request was leaking the user_id. Unless you find the email or username related to user_id its complete waste.
Then just went on browsing the site, There was a information disclosure again. And now it leaked user_id, email, username.
Now, You must get what I’m gonna say !
Yes, If attacker gets those two requests. He would be able to take over the account. Woah ?! But SHIT HAPPENS
Wrote a 2 page long report with all proof of concept and Company staff comes in contact, “Although the behavior described in your submission appears to be valid. They are our trusted 3rd parties”
Okay, End your excitement here. I’m Done on this write up !
In this field consistency is important, Stay Active. Bye bye *_*