In today’s write-up, we will delve into an Account Takeover (ATO) vulnerability and explain how I was able to bypass Cloudflare’s protections to exploit a password reset flow. This process, known as password reset poisoning, allowed me to gain unauthorized access to user accounts.
What is Password Reset Poisoning?
When you forget your password and click “Forgot Password,” the website usually sends a password reset link to your email. This link is supposed to be safe and unique to you. But in a password reset poisoning attack, an attacker finds a way to modify or “poison” the reset link sent by the website. This can allow them to control parts of the reset process, potentially redirecting the link to themselves or manipulating it to their advantage.
How I Identified and Exploited the Vulnerability
Returning to the write-up, here’s how I identified and exploited the Account Takeover vulnerability through password reset poisoning, despite Cloudflare’s protection.
For security reasons, I prefer not to disclose the actual name of the website or program, so I will refer to it as “traget.com”.
I was searching for bug bounty programs on Google using dorking, and that’s when I found a couple of domains that had bug bounty programs. I selected one as my target for bug hunting. Within 15 minutes, I found multiple vulnerabilities on that domain, which I reported.
Then I thought, let’s test for an account takeover vulnerability first. I tried the login page, but had no luck because any payload I entered was blocked by Cloudflare. After that, I considered trying for host header injection, but even after spending a lot of time trying and attempting to bypass it, Cloudflare kept blocking me.
I tried every possible bypass for host header injection, such as adding the “X-Forwarded-Host” header, “X-Forwarded-For,” and “X-Original-Host.” I also attempted to use custom headers and variations like “Forwarded,” “X-Host,” and “X-Forwarded-Port.” Additionally, I tested different combinations of these headers with various payloads to see if I could trick the application into accepting a malicious host header. But I had no luck.
Then, due to rate limiting, the application blocked me for a while. While I was observing the requests and thinking about how I could bypass the protection,
I noticed that the domain going to the host was app.target.com, but the reset link was coming from the domain pay.target.com.
What is the Origin Header and How Does It Work?
The Origin header is an HTTP header that indicates the origin of the request, which includes the scheme (HTTP or HTTPS), hostname, and port number. It is primarily used for security purposes, particularly in Cross-Origin Resource Sharing (CORS) scenarios. The server can use the Origin header to determine the source of the request and decide whether to allow or deny access based on that information.
In this context, I thought it was possible that the server might be using the value from the Origin header for generating the reset link instead of the host from the request. This means that if I could manipulate the Origin header in my requests, I might be able to control the domain used in the reset link.
So, I changed the value of the Origin header from pay.target.com to the URL of my webhook site and then sent the request.
Note: This time, Cloudflare did not block the request, and the server accepted it as well.
However, the website displayed a client-side error saying that the reset email wasn’t sent and to try again.
But when I checked my inbox, I found that I had received the reset link.
Then I clicked on the reset link. As soon as I clicked on it, instead of redirecting me to the website’s reset page, it redirected me to the webhook site domain that I injected in the Origin header, along with the reset token.
If an attacker obtains the reset token, they can use it to reset the password and take control of the victim’s account.
Thanks for reading, and I hope you found my write-up informative. Happy hunting, and remember to test responsibly!
Author : ABDUL REHMAN PARKAR