🔥Some Privilege Escalations + Logic Flaws Led to (DoS, Organization Takeover & more)

Some good privilege escalations, logic bugs that I've discovered at multiple pentest engagements led to critical/high impact findings

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

So, let's get to it. Today's story is about the most 6 interesting bugs that I've found in 4 pentest engagements in the last 2 months (I've found more, but those are the ones you'll like xD)

---

0x1 [PrivEsc] Agent Can Send Messages to Admin Private Inboxes

The admin here can create an inbox widget and add it to the organization website, then assign it to himself/any user, and they'll be the only users authorized to access this inbox/send messages.

Sure, I tried to send the send message request using the agent cookies (attacker/unauthorized user) and it didn't work (403 forbidden).

So the next level is looking for another function that does the same thing (or similar) as sending messages, and that function should be vulnerable to privilege escalation.

After some time of reading the docs & using the app, I found a function that adds a label to an inbox, so I took the request to my repeater, put the inbox ID and the required parameters, and it worked.

So, what's the deal? The interesting thing here about the label is that when you change an inbox label, the label name will be sent to the conversation as a message, so we can send messages to private inboxes through this vulnerable function.

---

1x1 [PrivEsc] Low Privilege Member Can Take Over Any Team

The second application is also a CRM. A low privilege member can't invite members/himself to any team in the company.

But he can invite users to the company through the endpoint /api/v1/companies/<company_id>/company_users_api/.

So, when we try to invite a new user to the company, we got something interesting in the response, a new parameter:

"group_memberships": [
  {
    "group_id": null,
    "is_group_admin": false
  }
]

After crawling the app for a couple of minutes, I figured out that the group_id is the team ID, so I tried something nice.

I invited a new user through the endpoint /api/v1/companies/<company_id>/company_users_api/ (which I can do), but with adding the previous parameter to the request, replacing the group_id with the owner team ID, and changing is_group_admin to true.

Now the new invited user (attacker2) is an admin at the owner team. He can easily delete him, taking over the team.

---

2x1 [PrivEsc] Custom Role Attacker (Group Manager) Can Remove Owner from Admin Group Leading to Organization Takeover

The 3rd application is also a CRM. The difference here is that the app assigns the permissions for users through groups.

The admin group is the full permissions group, and..

Big note: no one can remove the owner from the admin group, even the owner himself or another admin.

I tried to remove the owner through the main endpoint /api/v1/users/groups/000000000000000000000000, but it didn't work (403 forbidden).

So I need to bypass this. What can I do? Right, look for another feature/request/endpoint that can do the same thing but with another logic.

After some time crawling/using the app, I found this request that allows me as a group manager (authorized to edit any group, but unauthorized to remove the owner from the admin group) to edit groups for a given user.

I sent the request with an empty group_id parameter, then sent it & it worked perfectly (200 OK).

Now the owner has no permissions, the group_manager has all the company permissions, taking over it.

---

2x2 [PrivEsc] Attacker with Only Invite Permissions Can Make Himself an Admin

At the same application, a user who has the permission to only add/remove users can't invite admins or assign users to any group.

I just added the parameter group_ids to the request, added the admin group ID (000000000000000000000000), so I invited myself as an admin to the company, escalating my privileges.

---

2x3 [Logic Flaw to DoS] Attacker Can Prevent All Users from Inviting New Users by Sending Parallel Requests

While testing the same previous permissions, I was trying to force the application to do something wrong/opposite to its logic.

So, there's something you need to know about - there was a license system. The free plan has only 5 licenses/users to invite.

At first, I tried to bypass that using a race condition technique and invite 50 users, but it didn't work the way I wanted. It gave me (402 payment required) - it only invited 2 users (limit is 5).

Okay, wait a moment. When I deleted the invited 2 users, I tried to invite a new user (now I have 2 licenses), but I'm encountered by the error You have exceeded the invite limit.

So the backend here didn't invite the whole 50 users (402 payment required), only invited 2 users. But when it comes to counting them, the backend sees them as 50 users, and it prevents any more invites.

---

3x1 [DoS] Complete API DoS via Uploading a PHP File

This one won't be accepted in bug bounty, but it was the first time I've seen it, so I'll share it with you

Another CRM app has an upload function that only accepts PDF, PNG, JPEG files. However, this was just a client-side validation.

The first thing that came to mind is trying to upload a PHP shell. I tried and that's what happened.

Every time I upload a PHP file, I get 502 bad gateway. At first, I thought it was some sort of validation or something, but when I tried to use the app functions after this PHP upload, it gives me (50* server errors) on a certain API, so we got our DoS.

But here's the thing: the API was down only for 15-20 mins, not a big deal. By automating this using Bash/Python, we can send the same request every 20 minutes to make the API permanently unavailable.

---

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