How I Exploited a Hidden Race Condition to Bypass Licensing and Claim All Subdomains on the target

0_oNoProblem
3 min read3 days ago

--

السَّلاَمُ عَلَيْكُمْ وَرَحْمَةُ اللهِ وَبَرَكَاتُهُ

Hi and welcome back to another report! My name is Ahmed Ehab though in the bug bounty community, They call me Nopr. Today, I’m excited to share a detailed case study of a race condition bug I discovered on a platform we’ll call example.com.

Lets breifly explain what is a race condition before starting.

A race condition occurs when the outcome of a process depends on the timing or sequence of events, typically due to multiple concurrent operations executing without proper synchronization. In web applications, this lack of coordination can allow an attacker to bypass intended restrictions like rate limits or resource allocation by triggering the vulnerable function repeatedly before the system can update its state

Now lets get STARTED.

The Scenario In our case, example.com has a function to register a subdomain for a project a key part of their licensing and deployment system. Initially, I tested the function that registers the subdomain for my project. Surprisingly, that function did not exhibit any race condition vulnerability.

Not one to give up easily, I dove deeper into the application. I recalled that there was another page accessible right after logging in that asked if I wanted to claim a domain. Curiosity got the better of me, so I decided to test that page manually. And boom it worked!

Here’s a brief rundown of what happened:

  1. Initial Testing:
    I started with the obvious function for subdomain registration, but it turned out to be secure.
  2. Deeper Dive:
    I then explored another registration page that appeared right after login. This page directly asked if I wanted to claim a domain for my project.
  3. Approach:
    I captured the final HTTP request from this page before it was sent. Instead of sending it immediately (which would register a subdomain), I dropped the request, then modified it with different subdomain names. I used a tool to send multiple modified requests concurrently a classic single-packet attack to trigger a race condition.
  4. Result:
    Sadly It was a non-deterministic race condition (not every concurrent request succeeded), with enough attempts, I was able to bypass the intended limitation. Eventually, I managed to reserve more subdomains than allowed.
  5. Bypass:
    But I won’t stop here I tried multiple things and one of them worked to bypass that limitation you can simple send each request multiple times so the chances is higher to take that subdomain.

Key Takeaways for Fellow Bug Hunters

  • Don’t Settle for the Obvious:
    If the primary function seems secure, look for alternative or hidden functions that serve the same purpose. Developers sometimes overlook these less prominent pathways.
  • Manual Testing is Crucial:
    Automated tools are invaluable, but nothing beats a good manual exploration combined with fuzzing techniques. Capture, modify, and experiment with HTTP requests to uncover hidden vulnerabilities.
  • Share and Learn:
    Every bug, whether it’s triaged or fully rewarded, is an opportunity to learn. Document your process, share your findings, and help improve the overall security landscape.

Final Thoughts

Sadly my report got duplicated:

but still It was a good learning opportunity Alhamdulillah and in sha allah I will keep going. Happy hunting and remember, every bug is a lesson.

--

--

0_oNoProblem
0_oNoProblem

Written by 0_oNoProblem

Im Ahmed Ehab. i'm a bug hunter my trying to gain experience and share what i learnt.

No responses yet