Broken Access Controls are everywhere. In application security, they show up in many different ways. Sometimes they come from poorly designed client-side controls, and sometimes from vulnerabilities in server-side behavior.
In this write-up, I will show how I chained two different Broken Access Control vulnerabilities to escalate my privileges from a default user to an admin. Let's get started!
First, when a user logs into the target application, they can see pages like "Admin Panel" or "Statistics (Admin)" in the menu. However, as you might expect, they cannot access these pages. In the front-end, these options are shown in grey and cannot be clicked. When a user tries to click on these areas, they are shown a pop-up message asking them to request access.
We're all thinking the same thing, this is a critical point. Based on my years of experience in application security, seeing a pop-up when a user tries to access a restricted area is not convincing to me. Also, from what I observed, clicking on the "Admin Panel" page did not trigger any immediate HTTP request. It was purely a front-end action. The decision was already being made beforehand.
So, I decided to go back to the very beginning. I refreshed the page and tried to understand what was being loaded for me.
Which pages a user can access is determined during the initial login by the "hasAccessPermission" parameter found in the response of the /api/Pages/GetForUser endpoint, in the application, a real Role-Based Access Control (RBAC) check is not performed. This is a frequently encountered situation.
For access to the admin panel, the /api/Pages/GetForUser: false parameter is changed to /api/Pages/GetForUser: true, and the requests are allowed to proceed in their natural flow. Thanks to this response manipulation, the "Admin Panel" page in the menu has now become clickable. This can be done for all pages in the application.
I was able to access the Admin Panel, but no data loaded. Then I saw two error messages in the top right corner. This made me look again at the HTTP request–response cycle. Even though I couldn't see any data, I could still see all the API endpoints loaded for the admin panel. API endpoints of admin panel was exposed.
"/api/Role/Roles" endpoint caught my attention, it was a simple GET request with no parameters, but it seemed like an endpoint controlling user access to the Admin interface. This request was directly responded with a 403 Forbidden, preventing any data from being returned on the front-end.
So, the goal was simple. I changed the HTTP response to 200 OK, the success parameter to true, and code:200.
Yes, the chain was successfully completed. Access control in the admin application was poorly designed, instead of checking user roles on the backend, it relied on certain changeble parameters. This led to the exposure of API endpoints for the admin panel.
I reviewed the endpoints that could return data, and this flow allowed a normal user to access the admin panel and view or modify users, pages and other functions in the application.
That's all for now. Thanks for reading this far and I hope you liked it!
https://twitter.com/canmustdie https://0xcan1337.github.io/ https://www.linkedin.com/in/cankat-cakmak/