Bug Chain: pre-auth takeover to permanent access.

Grey here! In this blog, I’ll share how I escalated a normal pre-authentication account takeover into a permanent access backdoor. Let’s dive in!

So, the main story began when I was testing a booking application where businesses can sign up to offer their services for customers to browse and book them. A few minutes after I just started testing the application, a weird behavior caught my eye. The application creates an account from the provided email on the free trial application form without verifying the ownership. What does that mean? Can I create an account with any email address I want? Doesn’t it sound like a pre-auth takeover? I tested the possibility and every time I was successful at taking over.

Now what? What's the impact here? Even If I can take over an account before the victim does, One password reset is enough to overthrow my access, what else can I do here? Down the rabbit hole we go, so I started to dig deeper. I was trying to escalate it’s impact somehow. This digging led me to another vulnerability with a higher impact. I was able to block users from accessing the platform by exploiting a logic flaw in the invitation feature.

Logic Flaw: Using Invitation Function to Block Other Accounts

After that finding, I learned that there were multiple roles in the business portal. Out of curiosity, I started to test the authorization. I tried adding a member as the owner and tried to execute the same function with a low-privilege cookie, I started a service as a manager and then tried the same from a basic staff account. Out of all these authorization-associated functions, one particular function caught my attention. owner and manager can delete other classes of accounts, the owner can delete the manager’s account but the owner can’t delete his own account. Yes, there was no self account deletion function as a general.. But, can another owner account delete my one? There is no option to invite others as an owner on the platform. All the roles that can be invited are: Manager, Reception, Staffer, and Basic Staffer.

But there was no option to invite an owner. Therefore I started testing for it.

I invited an email as a manager and captured it’s HTTP request. There was a string named staff_access_level in the request, this string determines the access level of the invited user.

POST /core/v2/business_api/me/businesses/1380404/resources
Host: subdomain.redacted.com

{
  "name": "Attacker2ndEmail",
  "staff_cell_phone": "",
  "staff_email": "secondmail@attacker.com",
  "staff_access_level": "manager",
  "description": "",
  "position": "",
  "send_invitation": true,
  "services": [],
  "staff_user_exists": false,
  "photo": null,
  "type": "S"
}

I replaced the value of staff_access_level string with owner and forwarded the request

To my surprise, it actually worked! the inviting restriction was only implemented in the front end, there was no such prevention in the back end. But the main question is still unanswered, Can you delete an owner account with another owner account?

The answer is NO. The application was intended to run with a single owner for each business. With a couple of owners in the same business, the application logic was breached. There was no delete button..

What does all of this have to do with pre-auth takeover escalation? If you can add another owner to the business that the owner yourself can’t delete afterward, what does that mean? everything clicked in my mind at this moment..

If I create an account using the victim’s email address and then add another email I control as an owner to the platform, it answers all the questions. The victim can’t remove my other owner account due to the logic flaw and I would have a permanent backdoor to the victim’s business.

I put this theory to the test. Created an account with the victim’s email as an attacker. Invited my second email with owner privilege exploiting the misconfiguration. Finally recovered the password of the victim’s account to see if could still access the business. And yeah! The access was there! the victim cannot disrupt my backdoor either.

Thanks to this bug, I’m basically the co-owner now. I can peek, poke, and prod around — no take-backs, no escape. It’s my business too :3

Until next one..