How I Got My First Swag

How I found a vulnerability that got me my first Swag.

You’re likely familiar with the role of rate limiting in mitigating brute-force attacks. However, security mechanisms aren’t always as robust as they seem. Back in 2021, while analyzing a password reset feature, I discovered a subtle yet impactful vulnerability that effectively nullified rate limiting. The key exploit? A carefully placed null byte (%00), which allowed me to bypass the restriction entirely. This finding not only reinforced the importance of scrutinizing security controls but also earned me a spot in a responsible disclosure program, along with a well-deserved T-shirt as a token of appreciation.

The Exploit Unfolds

It started as a routine assessment of the password reset functionality on vulnerable.com, driven by a simple question: How effectively does this site enforce rate limiting? As it turned out, not very well. By appending a null byte (%00) to the end of an email address, an approach I had come across in a HackerOne report, I was able to completely bypass the rate limiter. This oversight allowed me to submit an unlimited number of requests, highlighting a critical weakness in the platform’s security controls.

Here’s how I did it:

Step 1: Go to the password reset page.

Step 2: Enter a valid email, like user@example.com.

Step 3: Append a %00 at the end, so it reads as user@example.com%00.

Step 4: Hit submit. Voila!, no rate limit in sight. Rinse and repeat.

Why Does This Work?

The null byte (%00) is akin to the quiet observer in a room; easily overlooked yet capable of causing disruption when unnoticed. In this case, the backend failed to properly sanitize or handle it, allowing the rate limiter to remain oblivious to its presence. Instead of rejecting it as malformed input, the system simply processed my request as if nothing were amiss. A subtle yet significant oversight—one that underscored a critical gap in the platform’s security posture!.

The Impact

So, what’s the worst that could happen?

Flooding the system with requests: Flooding Without proper rate limiting, an attacker could flood the password reset page with requests, putting pressure on the server and potentially locking out legitimate users.

Credential Stuffing Attacks: More seriously, this vulnerability could enable credential stuffing attacks, where hackers try large volumes of known username/password pairs to gain access to accounts. Yikes.

How to Fix This

Sanitize Inputs: Ensure any input, especially email addresses, rejects %00 and other unexpected characters. The null byte should be like “No entry” to your system.

More Rate Limiting, Please: Apply rate limiting consistently, regardless of weird inputs. Don't let the system get too comfortable with strange characters.

Double-Check Your Backend Logic: Make sure your backend isn’t giving a free pass to odd characters. If something smells fishy, it’s probably best to block it outright.

The “T-shirt” Reward

Now comes the rewarding part; I reported the vulnerability and, along with earning a place in the Hall of Fame, I received my first swag: a T-shirt. But beyond the perks, it’s the impact that truly matters—helping strengthen security while continuously expanding my knowledge. And for those in the bug bounty space, the occasional swag is just a small bonus on the journey of making the web a safer place.

And that’s how I earned my first swag by ingeniously bypassing a protection mechanism with a simple yet effective code. I hope this write-up provided valuable insights. Thank you for taking the time to read through!.