Race Condition to Bypass Rate-Limiting: A new technique made by Nillsx

Hi, Security Researchers!

First of all, I hope you’re doing well today. In this article, I’ll walk you through how I chained multiple vulnerabilities (Rate-limiting bypass with race condition and host header injection, and non-expiring password reset link) to create a powerful exploit. This vulnerability can easily be overlooked. Before we dive into the technical details, let me introduce myself for those who don’t know me.

Whoami❓

Hello, my name is Nillsx. I am a self-taught and bilingual Brazilian who has been deeply involved in studying cybersecurity to help create a safer internet and assist companies in keeping their users protected from cyber threats. My experience includes identifying vulnerabilities such as Reflected XSS (RXSS), Insecure direct object references (IDOR), One Time Password Bypass (OTP Bypass) and SQL Injection (SQLi).

Without wasting any more time, let’s dive into the article!

Introduction

This time, I was searching for vulnerabilities in a bug bounty program on the Intigriti platform. While reviewing the scope, I came across a subdomain which, due to the program’s guidelines, we’ll refer to as carbrand.redacted.com. Upon accessing the domain, I noticed a login and registration section, and from there, I knew exactly what to do.

Time to exploit

I decided to create a account with the name “nillsx-victim@intigriti.me”. I then began a reconnaissance process on the application. After some exploration in the logged-in session, I returned to the login page and started testing the “Forgot password” feature. I captured the request sent to initiate a password reset and began my exploration.

Initially, I sent a password reset link to my email and forgot about it. After analyzing the request (about two minutes later), I decided to send another link. I used the most recent link in my email to change my password. After updating the password, I noticed the first link and thought, “Why not try opening it?” To my surprise, clicking the link redirected me to the password change page again. I was shocked.

I decided not to change the password right away and instead updated my email from “nillsx-victim@intigriti.me” to “nillsx-victim2@intigriti.me”. After the email change, I returned to the unused link and used it to change my password. When I returned to the main site, I found my actual session closed, and my password had been changed — even though the reset link was sent to nillsx-victim@intigriti.me, the account was now associated with nillsx-victim2@intigriti.me. Them i decided to know how the flow works.

I returned to the saved request in my Burp Suite and attempted to send two consecutive reset links for further testing. When I sent the two links with a minimal time interval, I noticed that only one link arrived in my email. With this in mind, and knowing it would be ideal for the triager to have clear step-by-step reproduction steps, I began searching for a way to bypass the rate limiting imposed in this area.

Rate-limiting bypass with Race condition and Host Header Injection

At this point, I was trying everything to make the race condition work, as I only needed two immediate requests to succeed. I labeled the requests as “request 1” and “request 2”, grouped them in a tab as shown in the image below, and set them to be sent in parallel. I then began testing various injections:

Eventually, I decided to use Burp Collaborator to test for password reset poisoning. By injecting the Burp Collaborator link in this format: “burpcollaborator.carbrand.redacted.com” I received two links simultaneously in my email. Although the password reset poisoning didn’t work, I discovered a unique way to bypass protections against race conditions.

If you’re interested in using this technique and manage to find a valid bug or something similar, feel free to email me. I’d be thrilled to know that a technique I developed helped the community.

Proof of Concept (PoC)

Description

The application contains a vulnerability in the password reset mechanism, allowing an attacker to bypass request limitations through a combination of Host Header Injection and a Race Condition. This ultimately enables an Account Takeover, even after the account’s email and password have been changed.

Steps to Reproduce

2. Initiate a password reset request:

3. Set up multiple requests in Burp Suite:

4. Trigger a race condition:

5. Observe the result:

6. Reset the password:

7. Log in and change account details:

8. Exploit the outdated password reset link:

9. Verify account takeover:

Key Observations

I was quite excited to have discovered something new and unexplored. However, the report ended up being marked as “out of scope” due to the requirement of a compromised user account. And because the race condition didn’t have a big role in this, they say that make a separate report wouldn’t be great. Despite this, the discovery itself made it all worthwhile.

In conclusion, always look for different ways to approach something you already know how to do. Never underestimate your knowledge.