BOOK THIS SPACE FOR AD
ARTICLE ADPrivilege Escalations
It’s a vast application with tenants and user roles. For testing basic privilege escalations first, I created two accounts: admin user and least privilege user. Least privilege user is the user with zero permissions or the least possible access.
I have been hacking this app for the last 3 months so I became aware of most of the API calls, objects and error codes.
There is a search functionality with a common endpoint architecture for every object: GET /api/v1/EMAIL/search. Here, the object code is EMAIL for searching emails. Similarly, there are many object codes that I got in my burpsuite history like PHONE, USER, INVOICE, PHOTO, DOCUMENT, etc.
I read the API docs of the application and found that all the object codes are documented for every version of the API.Copy the object codes into a file (objCodes.txt).Copy the cookies/auth-token of the least privileged user (LPU), who doesn’t have access to most of the objects.Take the HTTP request GET /api/v1/EMAIL/search into Repeater and substitute it with the session of LPU.Send this request to Intruder, and set the object code EMAIL as the payload position. Use objCodes.txt for the wordlist. Start intruder attack.I got around 40+ 200 status codes. Later, I figured out that many of the objects are still visible to LPU in the UI as well. LPU has some default access inside this app.Time to filter out, which object codes shouldn’t have read access as per docs but the API call is giving 200 OK and the whole response.This took around 15–16 hrs to filter since it was a lot of work to review all of the features and docs properly.I got 4 privilege escalations at the end.Every IDOR or priv esc is not a vulnerability if the data is already public.Always save your burpsuite projects to keep track of operations, query names, endpoints, methods, error codes, etc.Always review the API docs, JS files and organization’s GitHub for fetching operation names, objects, query names or endpoints.