From an Out-of-Scope Bug to Unlocking Lifetime Premium Accounts in Mozilla

Hi, I’m Amr Kadry, a penetration tester and bug hunter recognized by over 45 companies, including Mozilla, CrowdStrike, Canva, and Vimeo. Today, I’m excited to share an intriguing discovery: a business logic vulnerability that, despite being out-of-scope, unexpectedly led me to gain unlimited lifetime premium access to one of Mozilla’s products.

Deep Dive into Mozilla’s Main Domain

I was deep in the process of hunting in Mozilla’s main account domain, accounts.firefox.com. My goal was to thoroughly understand each feature, inspect every request sent to the server, and analyze the server responses in detail.

While testing the Secondary Email feature, I’ve noticed that’s when adding a secondary email, Mozilla sends a 6-digit confirmation code to the new email address. This code is valid for 5 minutes, after which it expires.

Bypassing the Confirmation Code: Failed Techniques and one successful

At this point, I decided to see if I could bypass the confirmation code using a few different techniques. I experimented with manipulating the requests sent to the server, examining responses for potential leaks, and even attempting race conditions by sending rapid, sequential requests to trick the server into confirming the email. Unfortunately, none of these methods succeeded.

However, during this process, I discovered that the confirmation code endpoint lacked rate limiting!

Diving into the Details for Successful Exploitation

Oh wow, this is exciting, but we have a challenge now. How can we brute-force a 6-digit code in just 5 minutes?

Good question! Theoretically, we could use multithreading with a Go script to speed things up. But instead of spending time writing a script, I decided to use the ffuf tool to brute-force the confirmation code by handling the request along with the necessary headers.

But is 5 minutes really enough time to brute-force a 6-digit code?

I didn’t think so, so I decided to dig deeper into the confirmation code’s expiration. After some testing, I discovered that the code doesn’t actually expire right at 5 minutes. There’s a delay, extending up to 10–12 minutes before the code becomes invalid.

This was a game-changer! However, one ffuf session alone wouldn’t be fast enough to cover the entire range, so I set up multiple parallel sessions to boost the speed. I divided the 6-digit range into separate files using the seq command:

Each file was assigned to a different ffuf session, allowing me to brute-force multiple sections simultaneously.

Now, with several sessions running in parallel, the chances of a successful brute-force attempt were looking much better!

I’ve successfully exploited the vulnerability and bypassed the secondary email verification using just two parallel sessions, all from an open shell environment like Google Cloud Shell.

Assessing the Real Impact

But now, let’s ask: What’s the real impact here?

With this bug, I was able to bypass the secondary email verification and can change it to the primary email. But is that enough to make this exploit important?

I’m lucky because I know a lot about Mozilla’s systems. Using this bug, I was able to monitor the email for breaches on monitor.mozilla.org without needing confirmation. By making the secondary email the primary one in accounts.firefox.com, I could skip the usual checks.

Which Mozilla Monitor Product is an open source and can no more about it and that the explanation why that happen from the code

However, I still felt the impact was low, so I decided to leverage it further.

But that requires deeper thought and more effort. What I really want now is to get something more out of this bug, not just stop here!

Now, I asked myself: What if I add a secondary email using a fake account with Mozilla’s custom domain?

Which domain should I use to unlock the features?

Now, let’s dive deeper into the open-source code of Mozilla products to understand which features are unlocked for Mozilla employees based on custom domains.

After some dive deeping searching with the custom domains in the repos, I’ve found some great findings in Relay firefox product open source code

The code explicitly checks if the user’s email ends with @mozilla.com, which would typically be assigned to Mozilla employees. If this condition is met and the feature flag for manage_flags is active, the user is granted permission to manage flags.

it appears that users with @mozilla.com email addresses get access to additional features (like managing flags) that are not available to other users.

so now after adding the secondary email for the email moraa@mozilla.com and make it as a primary email

I logged into my Firefox Relay account and discovered that it had upgraded to a premium account. Here we go!!

Now I can have unlimited lifetime Premium Relay Accounts :))

I submitted the report to Mozilla, and they accepted it as a medium-severity bug. However, I only received a bonus for my efforts rather than the actual reward for a medium-level issue according to the bounty table. Is this scenario really worth just a small bonus instead of the full reward?

I hope you found this write-up beneficial and insightful. I’m always striving to improve my future write-ups and make them even more informative. Feel free to connect with me on LinkedIn or reach out on my X account if you have any questions or need assistance. Looking forward to engaging with you!

LinkedIn: Amr Kadry

X: 0d_3mrr