Rate Limit Bypass Leads to 0 Click ATO

Hello to all security researchers and esteemed bounty hunters. Welcome to my second write-up. I hope you find it enjoyable.

As you can see in the title, the vulnerability I discovered relates to bypassing Rate Limit, which leads to account takeover.

The vulnerability I discovered involves the unauthorized takeover of user accounts. This security flaw allows an attacker to bypass the Rate Limit mechanism, which is designed to prevent excessive access attempts. By exploiting this vulnerability, an attacker can gain unauthorized access to user accounts, potentially compromising sensitive information and taking control of the account. It is crucial to address this vulnerability promptly to ensure the security and privacy of user accounts.

Let me start from the beginning. redacted.com (Due to the sensitivity of the program, I am required to use redacted.com as the target website.) had the functionality of user registration and login, allowing me to create an account and sign in. Additionally, there was a password reset feature that would send a 6-digit code to our email address. Initially, I began brute-forcing the password, but unfortunately, after around 20 attempts, I encountered a block and was prompted to solve a CAPTCHA.

In this case, various tests can be performed, including adding the X-Forwarded-For header. However, before conducting such tests, I realized that redacted.com is behind Akamai’s firewall. Therefore, I decided to let go of such tests and tried to think outside the box.

So, I started exploring further, and after performing subdomain discovery operations, I came across a subdomain that was an exact replica of the original website in terms of design and template. I decided to create an account there and see what the differences were.

However, when I tried to create an account, I encountered an error message saying, “Your email already exists.” This raised suspicion that the databases of the two websites are identical.

To verify this, I went back to the original website and created another account using the same email. Then, I attempted to create another account on the second website (the replica) with the same email. Once again, I received the message, “Your email already exists.”

Therefore, it can be concluded that the second website is essentially an identical instance of the first website, and their databases are the same.

However, when attempting to log in to the second website, we were unable to log in and received a “Forbidden” error, preventing us from logging in.

I started examining the request being sent during the login process and compared it to the request made on the original website to identify any issues that might be present.

Unfortunately, I didn’t find any differences between the two requests, and the requests were exactly the same. However, I noticed two interesting header that caught my attention:

X-Apollo-Operation-Name: Login

These header were used during the login process in the original website and worked fine, but they didn’t work on the second website. Additionally, during the password reset process on the original website, the word “ResetPass” was used instead of “Login”.

I speculated that these could be separate services, so I tried using the password reset service in the login section. Therefore, my header looked like this:

X-Apollo-Operation-Name: ResetPass

After sending this request, I successfully logged into my account and was able to access my account information on the second website, which was exactly the same as the information displayed on the original website. This confirmed that the websites indeed shared the same database.

Then, using the same “ResetPass” header, I attempted to send a request to the “ForGetPassword” endpoint to receive a code via email, and the code was successfully sent (in normal circumstances, if we wanted to reset the password, it would display “forbidden” and use the Login service for password reset, preventing us from testing this feature).

I have a feeling that this website was a testing site for developers, not intended for regular users to access.

By changing the header from “Login” to “ResetPass,” we gained the ability to perform password resets, and we were able to successfully reset the password.

The interesting part of the story is that no matter how many times I sent password reset requests, I didn’t encounter any rate limits, and I could easily perform brute-force attacks without any restrictions.

It seems that another issue present in this scenario was that the verification code would expire after 10 minutes. However, this was not a problem for us since there is no rate limit anymore. Therefore, as an attacker, we could divide the range from 000000 to 999999 into 10 parts (this is just an example, it could be more or less) and perform brute-force attacks using 10 different instances simultaneously, similar to a real attack, to hijack the victim’s account.

I submitted the POC and explained the vulnerability to the triager. After extensive evaluations, the issue went through a triage process, and after 14 days, I received my bounty reward.

I hope this write-up has been informative for you, and I encourage you to continue honing your skills.

Respect to all night hunters around the world.