While performing a pentesting engagement with CyberAR on a cloud solutions web application, I chained a vulnerability and a weird function to reach a critical impact.
The website has some roles for managing project content, let’s say Admin, Team member, and Viewer. The really weird function is that an Admin can edit other admins’ email addresses and also change the whole data in their accounts, like first and last names, email addresses, phone numbers, etc. The email address here allows an admin to take over another admin’s emails by changing their email address and then resetting the password. Hmmm, sounds weird, right? So, it’s dangerous to set anyone in the admin role.
The Admin normally invites a user to become a team member. The user is now a member.
What about response manipulation?
Actually It’s sweet and makes me full 🙂
We have different invitation roles as I mentioned before. The Admin invited a member to control some functions. I tried a response manipulation vulnerability while accepting the invitation.
The `id` of the admin was the same as the id of the member. Maybe it checks the `value` parameter?
I tried to manipulate the response by changing the member to admin.
but it didn’t work as the website redirects to signup page. 1st try has been failed some disappointment reached out.
After further investigation I found a function for modifying the roles in the Admin account. I got excited again for more searching in this function.
I noticed that the request of the role modification function contains the UUID of the member whose role I want to change in the endpoint.
I’ve seen this endpoint before from the member account when I updated the personal data for the member account, and I got the same endpoint as the one in the role modification function.
Sounds great until now. The admin and member can send requests to the same endpoint. But wait for a while; there are different Authorization headers in both requests that may validate the role and decide to take action or not. So, would it work or not? Fortunately, the website was validating the header’s validity only, not the role of each Authorization header.
Immediately, I opened the member account settings and made a small change while intercepting the request. In the request body, I saw a lot of parameters. I deleted them all and pasted `user_type=1`, which is the parameter being sent from the admin account while modifying the role of any user.
Now the member escalated himself to admin!
Time for chaining has come
As they both have the same privileges, they can edit each other. I immediately accessed the admin settings and changed the admin’s email to mine. After resetting the password for the replaced email, I received the reset password URL at the used email. I logged in using my email address and the new password I had set. The admin account opened successfully, giving me control over the projects, other admins’ accounts, and everything!
In this scenario, a security vulnerability was discovered involving role modification and privilege escalation within a web application. The application allowed both admins and members to send requests to the same endpoint for role changes. The issue arose because the system only validated the Authorization header’s validity, not the role of the requester. changing a member’s role to admin and using the same endpoint for role modification, the attacker could escalate his role. By changing the admin’s email and resetting the password, the attacker successfully took control of the admin account and thus had full control over the projects and other admin accounts.
– Understand Role-Based Access Controls (RBAC): Be familiar with the role hierarchy and permissions in the application. This will help you identify where privilege escalation might be possible.
– Check Authorization Header Validation: Verify if the system validates only the header’s validity or if it also checks the role associated with it. In some cases, bypassing role checks can lead to privilege escalation.
– Identify Sensitive Endpoints: Look for endpoints that handle critical operations such as role modifications, user management, or administrative functions. These are prime targets for privilege escalation.
– Analyze Request and Response Bodies: Examine both request and response bodies for parameters that control access levels or roles. Manipulating these parameters can often lead to privilege escalation.
Access control vulnerabilities and privilege escalation
OWASP — Testing for Privilege Escalation
I hope this writeup was clear and useful.
