$1300 - Story of IDOR and Privilege Escalation

$1300 - Story of IDOR and Privilege Escalation

source cover : securiumsolutions.com

Hello world,

Before start reading on this article, please keep in mind that I write this article for educational purpose only. Ok so let's started!


So I was dorking for a bug bounty program on google using this google dork site:.tld inurl:security intext:reward shortly I found a target that have maximum bounty $1000 for critical bug and acknowledgment only for low bug. The target was used UUIDs as identifiers, so it's hard to find IDORs & CSRFs bug. The target was a web application used for creating and sharing code projects. The user can create they own organization and invite another user to their workspace. There are 4 roles on the workspace :

Viewer - Can only views all projects and members of a workspace
User - Execute notebooks and change input cell values in project
Editor - Create and edit projects in a workspace. Can't add or edit organization
Admin - Full access to the workspaces, projects, can manage organization.

Since the target didn't accept the disclosure, let's assume the target as target.tld.

Time to Hunt

So I went to target.tld and doing basic things like register user and logged in to dashboard. I was noticed that there was a settings & members menu so I came up to. I can invite any user to my organization, there was 4 roles in members so I invited my second test account as Viewer user role to the organization. I fired up burpsuite and capture all requests on my Admin user and send it to repeater.

Privilege Escalation

Now I accept the invitation from my Admin user and logged in to the account. Noticed that I can't do anything except views all project and member of workspace. I opened the repeater tab and see if there was an interesting graphql endpoint, I noticed that Admin user can edit the user role so I went to my Admin user and make a request to graphql endpoint then send it to repeater. Now as Viewer user I make any request and change the body request to this :

{"operationName":"EditMemberRole","variables":{"team_id":"TEAM_UUID","user_id":"USER_UUID","user_role":"admin"},"query":"mutation EditMemberRole($team_id: String!, $user_id: String!, $user_role: TeamRole!) {\n editMemberRole(team_id: $team_id, user_id: $user_id, user_role: $user_role) {\n user_id\n user_role\n __typename\n }\n}\n"}

I send the request and know what? yeah I was able to edit my user role even didn't have access to do that. I write the PoC and reported the bug to the company and then continue to find other bugs.


After a while spending time to write a PoC and reported the bug, I opened a repeater tab again and saw there was a graphql endpoint with operationName InviteMembers :

{"operationName":"InviteMembers","variables":{"team_id":"TEAM_UUID","invitees":[{"email":"","user_role":"admin"}]},"query":"mutation InviteMembers($team_id: String!, $invitees: [Invitee!]!) {\n inviteMembers(team_id: $team_id, invitees: $invitees) {\n invitesSent\n invitesSkipped\n __typename\n }\n}\n"}

There was an interesting parameter that called team_id I have to test that if there's any IDORs bug if I change the value team_id to another team_id I can joined to another organization as Admin, but I need to know another team_id, as I mentioned above the target was used UUIDs as identifiers so the impact of IDORs is significantly reduced. But I didn't gave up. I take a break for 10 minutes go get some water and food. While take a break I was think what if the team_id is indexed on internet? So I went to this website web.archive.org and scanning for all endpoint of the target.tld/* https://web.archive.org/cdx/search/cdx?url=*.target.tld/*&collapse=urlkey&output=text&fl=original for those who didn't know what it is, this website known as tools for scanning subdomain and URLs endpoint. #CMIIW
So I search for some keywords like workspace and I came accross the team UUIDs was being indexed. gotcha! Now I have all of another team UUIDs.

So I make a PoC, I used my second account for testing. I deleted my second test account in the Admin user workspace. Now I create a new own workspaces. Let's assume that UserA is Admin of workspaceA and UserB is Admin of workspaceB. Let's assume that UserB was found workspaceA UUIDs on indexed page.
Now I came up to my repeater tab again and send another request. I change the value team_id to UserA team UUIDs then I send the request and you know what? the server returned http 500 internal error response. I frustrated at that time D:
But wait.. when I go to my settings & members on UserA account I got noticed that the user have successfully invited even the server returned http 500 internal error response. The problem was a missing await on a function that responsible on auth checks in javascript, so the code continued and sent the invitation email. Then I reported the bug to the company and the bug was triaged and accepted as critical because of the posibillity of large-scale exploitation based on enumerating the team IDs on indexed pages.


For this case I have to don't give up to myself. I Keep in mind, maybe there was a gold when I choose gave up.

Timeline :

- Sep 13th 2022 - Reported Privilege Escalation vulnerability
- Sep 13th 2022 - First response and validated the bug was valid and eligible for bounty
- Sep 13th 2022 - Vulnerability fixed and awarded $300 USD.
- Sep 13th 2022 - Reported IDOR vulnerability
- Sep 19th 2022 - The vulnerability was accepted as critical and has been fixed, awarded $1000 USD + acknowledgments to Hall of Fame pages.

Follow me on twitter :