As I believe anyone here landed to this write-up is a well known to brute-force vulnerability and what a brute force attack is, I am not going to make this write-up a boring one with the couples of dumped HTTP requests, rather I will try to be straight, clear and to the point.
So while hunting in one of the private programs, I came across its endpoint responsible for resetting password through forgot password functionality.
The format of the reset password link was simple:
But what made it an interesting chase for me?
When I tried to fuzz that otp parameter I noticed that all the requests have a response code 302 from the server, which signifies redirection. Enabling 'Follow Redirection' solved the first barrier (obviously location of redirected URL also had not rate limitings), but so far nothing was so interesting until I found that despite of being an endpoint to be vulnerable for brute force, there was no unique difference in the response tab between failed and successful attempts. So the next challenge was for me is that even if I would have came across successful attempt, it was hard for me to differentiate and identify the actual working HTTP request.
Time to ask Google few questions:
I give a thought to google the technicality of this behavior that how a developer is hiding the rendering contents, and first time in a while I get to know the actual difference between View-source and Inspect Element.
The source code was not having any keyword that could differentiate the HTTP response but browser was rendering the elements as expected.
A quick briefing of how View-source is different than Inspect Element:
Suppose you opened a tag <h1> but closed it as <h2>. View-source will fetch an original code as <h2>. But browser will correct it back to <h1>, and therefore Inspect Element will have <h1> rather than <h2>.
Coming back to the topic,
So I started giving thought of how can I get rendered content of my target in View-source and a very beautiful stuff struck into my mind that we call "The Headless Browsers".
I chose PhantomJsCloud.com Standard JSON API due to its ability to render webpages as HTML, PDF, JPEG, PNG, or JSON.
Ideating the attack:
So the idea was that when I'll be accessing the target's rendered webpage through PhantomJsCloud API as HTML, I'll get the keyword that I am looking for in "View-source of PhantomJsCloud.com" as technically now the rendered elements are also belongs to PhantomJsCloud.com as target's webpage is being rendered as HTML inside [PhantomJsCloud.com].
Coda, the final call:
So as my attack was a simple GET based brute force, I crafted my final vulnerable URL with PhantomJsCloud API which was as follows:
Now I simply brute forced the otp parameter of the above crafted URL and successfully identified the working HTTP request responsible to takeover of victim's account.
That was all,
Thank you, hope you enjoyed the reading.