True Stories of the TRC

Becoming an Admin Through Broken Access Control Policy

Many applications on the Web have role-based access controls, with different functionalities for each role which determines what a user can do and which content they see. For example, a simple form application has three roles of administrator, moderator, and user. A healthcare web portal has a larger role list including doctor, patient, nurse, pharmacist, administrator, etc.

Applications with multiple role types are expected to have proper access control policies implemented so that each role can only access and use its own functions and content. Breaching this expectation denotes a vulnerability known as Insufficient Authorization.

This vulnerability results when an application does not perform adequate authorization checks to ensure that the user is performing a function or accessing data in a manner consistent with the security policy assigned to their role. Depending on which application functionality is vulnerable, it could be possible to launch a privilege escalation attack. I will be demonstrating such an exploit I found during an assessment of an application from a manufacturing client.

The application in question was a Single Page Application where content is provided via JSON calls. The page primarily consisted of a control panel featuring different functionalities depending on the user’s role. To test for Insufficient Authorization, I used credentials for both an admin-level account and a customer-level account. The goal was to see whether the customer-level account could access and/or execute functionalities that should be restricted to the admin-level role.

On the admin-level account, the application had a section titled “Admin Management” that hosted various administrator functionalities such as managing user roles and user accounts. Gaining access to this functionality from the customer-level account would prove useful to an attacker. Targeting the managing user roles functionality, I gathered the requests for both viewing and modifying user roles with the following commands.

 

Viewing User Roles:

GET
http://spa.web.site/commonapi/api/userroletype/getuserroletype

Modifying User Roles:

POST http://spa.web.site/commonapi/api/userroletype/save
mapUserID=016&roleList%5B0%5D%5BroleID%5D=1&roleList%5B0%5D%5BroleName%5D=admin&roleList%5B0%5D%5Bregion
ID%5D=1&roleList%5B0%5D%5BregionName%5D=North+Region&createdBy=016&modifiedBy=016&localStoreID=002&userID=016

 

Next, I switched over the customer-level account to test if these requests could be sent successfully. Starting with the request for viewing user roles, I sent the request to the server and got back the same response as I did on the admin-level account. This response showed that there was no access control in retrieving content.

I then sent the request to modify user roles, attempting to set the user ID of the customer-level account ID to the role to admin. Again, the server returned the same response as it did for the admin-level account, which allowed the customer-level account I was emulating to be upgraded to an admin-level account. This shows also that there was no access control for modifying content. These permissions showed me that the application was vulnerable to Insufficient Authorization.

In order to remediate this issue, an access control policy should be implemented for the application. The principle of least privilege is a good metric for establishing the proper limitations for each account role. Least Privilege states that running code should only have the permissions needed to complete the tasks and no more. Whether it is reading or modifying resources on the application, user accounts should only be able to perform these operations if their assigned roles allow them to do so. Enforcing such an access control policy will prevent the issues shown where users can read sensitive data or perform a privilege escalation attack.

Tags: DAST, Manufacturing, Penetration testing, Vulnerability assessment, web application security