Page cover

🟧Logic flaw led to PrivEsc: I used a feature to bypass a restriction

Exploiting a logic flaw to bypass the admin restriction allowed me to add members to a private chat group using an existing feature.

Hello, friend! This is mrhashimamin. And I’m back today with a new write-up for you, ma amigo <3.

Alright, let’s get to it. This is about another bug I found in the scam program I mentioned in my last write-up. This time they paid quickly—unlike last time. xD

Anyway... As you know, team-manager.cloud is an app for team management, blah blah blah. But this write-up is about chaining two separate parts of the app (as they see it) to get a solid Privilege Escalation.


To get the whole idea, you need to know about the two parts I’ll talk about: chats and playbooks.

  • Chats are, well, chats xD—messages between members and coworkers (both public and private).

  • Playbooks are like predefined workflows. They help you define, organize, and document complex, repeatable tasks.

For example, the steps you take during an outage, a software release, or even onboarding a new team member can all be turned into a playbook.


So, the story starts with me messing around with the permissions the admin grants (or doesn’t grant) to users and trying to bypass them in different ways.

Something caught my attention: as an admin, you can stop members from managing (adding, removing, or updating) chat members.

That got me thinking—how can I bypass this and add new members if the admin turns that permission off?

Sure, I thought maybe it was just a client-side restriction, so I tried sending the request again. But nope, it gave me the ugly 403 error. So, I moved on and kept testing other functions over and over.

A couple of days later, I shifted my focus to the playbook functions. And here’s where something new came up—you need to know about playbook runs.

A run is just the execution of a playbook. You can either start each run in a new chat or choose to use the same chat for multiple runs. So, do you want to try harder and combine two things to find a good bug? Well, that’s exactly what I did.

Okay, here’s what I did: I created a playbook, started a run for it, and set up a new run chat while creating the run. I was using it like a real user but with a hacker’s mindset xD. And guess what? I found my Goldfish.


One of the run features lets me (as a member-role user) turn on an option to automatically add members to the run chat when they’re added as participants to the run. Are you thinking what I’m thinking?

Yeah, exactly! I’m thinking about using this feature to automatically add members to any private chat I want. But how? Here’s my little attack scenario:

  1. The admin removes the permission for managing chat members.

  2. The attacker creates a playbook.

  3. The attacker creates a playbook run and links it to any private chat they want (must be a member in it) using the chat ID (this isn’t the bug—it’s a feature).

  4. The attacker turns on the option to automatically add new participants to the run chat (another existing feature).

  5. The attacker adds a new participant to the run.

  6. The new participant gets added to both the run and the run chat (the private chat).

And here’s the bug: the backend didn’t validate whether the admin gave members permission to manage chat members or not.

To make it easier to understand, I made a little diagram to show the flaw I described.


Impact?

  • A member-role user can add members to public or private chats without the admin’s permission.

  • This bypasses admin-imposed restrictions, breaking the role-based access control system.


That's the story for today. I hope you find this write-up useful. Thanks, and keep hacking 3>

Last updated