Hi everyone it’s Yasser again (AKA Neroli)

My brother was learning programing and I was teaching him some stuff, and he wanted to get started into bug-bounty, so I guided him (I will share you simple tips that I told him to do to get started), Let’s go

We picked a target with many roles so we can play around with Access Control Misconfigurations, which we did the target was allowing us to create an organization and give permissions for each user,

My brother started to play with the roles and test each permission blindly, (it’s not the best practice but for someone who is new he was trying to see an issue).

My brother found a role called Database Administrator

so opening the docs to understand what this permission allows us to do showed the following

hmmm interesting, as a user can access database and edit it, but at the same time we wasn’t able to control any user permissions or change it

[email protected] is Database Administrator
[email protected] is Full Admin

Database administrator cannot change users permissions or invite user

but the admin can

Now we know that the Database Administrator can Access Database, and having a look at the requests being sent we found that it contains a Graphql query so why cannot Database administrator execute these queries?
so when I told my little brother that he was like

After intercepting the request which is responsible for inviting users

we and noticing the graphql query

we used the same request with Database Administrator user cookie we noticed that the request sent successfully!

my brother was so happy that he found his first bug on a production that many users use, we were on discord and he was so loud XD.

1. login as Database Administrator
2. create temp account
3. copy the above request and send invitation to the created account
4. accept the invitation from the new account and you will be a full admin

Note that the roles in the request are static ids so we can get them by creating a temp organization and intercept the request.

after that we found that the issue is also applicable on the edit user permissions request so we got 2 ways to do it

but h1 says it’s duplicate and the same issue (Please drop comment on that!)
anyway we still arguing about this point wish us luck :).

the report at first closed as N/A bcs the triager didn’t followed the steps and choose wrong role so he got forbidden response,

and we resubmitted it and also got N\A bcs the other triager thought that roles ids are dynamic and change from organization to another so we cannot get the values unless we got a full admin account.

My brother was really disappointed truly and I was struggling for a week to show the triagers that the issue is valid,

Finally we got triaged with medium severity and a bounty of $500.

I hope the triage process be more smooth, if i didn’t argued .. the issue was just going to be N/A.

• when u are testing Access Control Issues always try to understand every role, not just testing randomly.
• when u believe in the issue try to make the report as clear as u can, triagers facing a huge amount of reports every day and they don’t understand how every application works.
• you want to make money… don’t be rude with the triagers, I always go to h1 support and they always help.

Wait for our writeups we got an Xss from path traversal, good bye.