Missing Rate Limit on Several Endpoints $1300

Hello, hunters!

In this blog post, I’ll share the journey of uncovering a rate-limit vulnerability on multiple endpoints that ultimately enabled an account takeover. Let’s dive into the details!

Description

Rate limiting is a mechanism designed to control the volume of requests directed at a specific API endpoint within a given timeframe. Its primary purpose is to protect APIs from misuse and ensure system reliability. For instance, rate limiting can prevent brute force attacks by capping the number of login attempts made to an endpoint.

There are generally two types of rate limiters:

• Strict Rate Limiter: This approach blocks all requests once the limit is exceeded, ensuring strict adherence to the set threshold.
• Flexible Rate Limiter: This allows the threshold to be temporarily exceeded for a brief period before throttling requests, offering a more lenient solution.

Rate limiters serve multiple purposes, such as:

• Preventing Resource Exhaustion: Safeguarding systems from being overwhelmed by excessive usage.
• Controlling Costs: Avoiding overuse of pay-per-use services by enforcing request caps.
• Enhancing Security: Protecting APIs from malicious activities, such as automated attacks or spam.

Initial Reconnaissance

I began with the fundamentals — reconnaissance on the target. I launched Burp Suite and carried out the standard steps: checking subdomain, URL crawling, searching for JavaScript leaks, and more. However, this time, the recon process didn’t yield any significant findings.

Hunt Begins

A couple of months ago, I set my sights on a private target — a company specializing in payroll, HR, and time management software. With curiosity and determination, I decided to dive in and begin the hunt.

1st Endpoint Login Form

After conducting some preliminary checks, I decided to intercept the login request for closer inspection. To my surprise, it turned out to be vulnerable to a rate-limiting issue. Without wasting any time, with the help of Intruder I sent 100 consecutive requests. On the 101st attempt — bingo! The vulnerability was confirmed.

Following confirmation from the team, I was rewarded appropriately for this discovery.

2nd Endpoint Bruteforcing password reset tokens

With the confirmation and reward for the first report, I was motivated to dive deeper. I meticulously examined every possible endpoint for rate limit vulnerabilities. During this process, I discovered that the reset link lacked any rate-limiting controls. I intercepted the request, replicated the steps from my previous finding, and, after sending the requests, achieved success once again — this time on the 102nd attempt.

Following validation, the team reviewed this finding and categorized it as a P4. Once again, the report was successfully closed. Got the same reward as above!

Having secured two rewards so far, both classified as P4, I felt determined to push further. I decided to continue my hunt, aiming to uncover something truly impactful and intriguing.

Deep Dive into the Application Flow:

While fuzzing with the application something interesting caught my eye. I always check for session token while testing the target, I saw that they were using MD5 hash for sessions.

“What is MD5 Hashing?
MD5 is a cryptographic hash function that converts data of any length into a unique 128-bit hash. Even the slightest change in input produces a completely different hash, making it essential for data integrity and verification.”

3rd Endpoint Final Reward

There was a bug which can lead to active sessions takeOver (possible account takeover), the application is authenticating the user with sesha cookie value which is MD5 hash used for session, an attacker can easily enumerate the sesha and steal the victims account just by enumerating MD5 session hashes.

Report (Steps to Reproduce)

1. Go to https://my.target.com/locations and capture the request.

2. Send the request to intruder and clear all positions after that select the sesha value as position 1.

3. Go to payloads tab and select the payload type Run time File and choose the MD5 session hash file.

4. Go to options and increase threads if you want this step is optional.

5. Click on Start Intruder and wait for the requests and responses.

After submitting the report, it was triaged within just two hours and classified as a P2. Finally, the persistence and dedication paid off!

I was rewarded $1000 for this third find from the team.

Takeaways

Always conduct a thorough examination of every endpoint, paying special attention to common ones like login, reset links, and, in my case, session management — it proved to be highly rewarding. I hope these insights prove helpful to my fellow hunters. If you enjoyed this article, feel free to follow for more!

Happy Hunting.