BOOK THIS SPACE FOR AD
ARTICLE ADHi 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
asamaaly70@gmail.com is Database Administrator
dragonx159753@gmail.com 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.
login as Database Administratorcreate temp accountcopy the above request and send invitation to the created accountaccept the invitation from the new account and you will be a full adminNote 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.