In this blog, I'm gonna tell you a story, a story about an application logic flaw that let me block new enrollments of the target application. Sounds interesting? lets begin..
The target was a service booking app. Businesses could register by enrolling in a subscription to offer their services on the platform. On the flip side, customers could browse and book these services. I will refer this platform as redacted platform throughout the writeup
So I started poking around.. after a few minutes of testing, I noticed a weird behavior. When I applied for their free trial, the application created an account from the provided email address but no verification was done. Interesting, huh? Doesn’t that sound like a pre-authentication takeover? Oh yes, it does! So, naturally, I tested it with a few other email addresses. And guess what? It worked every single time. So it is a bug, but how impactful? Not much, as victims can easily reset the account’s password and kick me away. Reporting this standalone isn't enough. Developers would probably brush it off with their golden line XD
So I kept this weak point in mind and started exploring other parts of the application. I was looking for the functionalities where the email address is being used so that I can escalate the impact. Some features such as account updates, password changes, email changes, etc commonly use email addresses in their workflow. Unfortunately, there were no such options in the account settings.. Then I started to use the application like a normal user to better understand it. I found some potential IDORs along the way but didn't work. Then, I found something interesting: a staff invitation page. This feature allowed business owners to invite someone by email to join their team
Out of all the inputs and controls of that page, one section caught my eyes
Umm.. Invite and create a redacted account? you really mean “Create”? another pre-auth takeover scenario? No, This time I looked at the thing in a different way, as I knew a standalone pre-auth takeover won't bring me anything.
Creating an account typically requires a password, but the invitation process skipped this entirely. No password was requested, nor was any generated password sent in the invitation email. Instead, the app sent an access link to the invited email address, and clicking this link granted the access to the account.
This made me wonder:
- Does the account only activate when the user clicks the invitation link?
- Can the invitation directly grant access to the account associated with the invited mail, even without victim interaction?
- And since the platform doesn’t verify account creation, Can I preemptively create an account with the victim’s email before they activate it? Maybe after that when the victim clicks and activates the account, I would have the same access to the target business as they have.?
There are 3 possibilities:
- I create account with the invited email and get access directly
- I create account with the invited email but I get access only after the victim clicks the link
- I fail, can’t access anything
With these questions circulating in my head, I decided to put them to the test.
I logged into my business portal and invited the victim as a staff.. before I access the invitation link as a victim, I tried to create an account with the victim’s email as an attacker and I.. FAILED..
Turns out, the app reserved the email as soon as the invitation was sent. Whether the victim clicked the link or not didn’t matter, the email was locked, nobody can create an account with it. At this point, It was very exhausting for me.
So I stepped back for a break, got some fresh air, spent a bit time with family and took a little nap.
Im back again, with a fresh mind and a cup of coffee. I started using the application as the invited staff. This time, switching my focus toward CSRFs. I generally thought of testing account deletion and the organization leave function. But.. As I mentioned before, there is no function for changing the email or password, nor is there any feature to leave the business or delete your account. Something clicked in my mind, the same previous scenario but a different perspective.
If an business owner invite you to their business as a staff, a account is already created for you. You cant leave the business nor you can delete the account.
What if you are a legitimate customer? You are planning move to the redacted platform soon. If the attacker invites you to their business, you can’t sign up for your business by any chance! You can't create an account, as an account with your email is already created along with the invitation. Thinking of accepting the invite and then leaving the attacker-controlled business? No my guy, that’s not possible, neither you can delete the account. You are basically stuck.
It’s a bit ironic here. The main purpose of the invitation function is to bring people to the platform. In this case, if someone invites you to the platform, you can’t join it :3
Attack Scenario
On the redacted platform, the attacker creates an account as a business. Invites the victim as staff, blocking them from the platform. Now the victim who is a potential customer of the redacted platform, can’t create an account for their business. Frustrated, they move to a competitor platform of the redacted platform, shortening revenue for the redacted platform.
What did you think? eh, it's just another low impact bug.. blocking other’s account creation.. not even a takeover.. blah.. blah..
But here comes the main impact. The easy to exploit nature of this bug makes it a dangerous weapon. all you need is to send a post request to the invitation endpoint and the email address you wanna block as the payload and that’s it. As a worst possible state, there is no rate limiting either. Imagine there is an attacker waiting for you with this wordlist..
Final Thoughts
I know I could’ve written a shorter blog. But I wanted to take you on the same journey I went through during testing — the highs, the lows, and the “aha” moments.
Sometimes, a bug is more impactful than it seems at first glance. It’s all about perspective.
Checkout my next writeup, where I escalated the pre-auth takeover mentioned above
