This latest edition of Exploits Explained walks us through a Synack Red Team member’s discovery of an access control violation vulnerability that led to account takeover. Be sure to follow Synack and the Synack Red Team on LinkedIn for later additions to this series.
Hello everyone!
In this post, I’ll explain an access control vulnerability I encountered while testing a target.
The target web application had a user role assigned for the test. I started by examining the capabilities of the assigned user role. This user didn’t have administrative privileges, but they did have access to the service’s User Management section, which allowed them to view a list of all users in the system as well as some biographical information associated with those users, including their name, surname, address, phone number and email.
My first priority was determining if the user had access to functions like “edit,” “create” or “delete.” They didn’t have access to the “create” or “delete” functions—but they could use the “edit” function to modify the accounts of some, but not all, of the service’s other users. I kept this in mind as I continued to explore the service.
Next, I focused on what information the user could edit.
In the User Management section, I could see the users’ names, surnames, addresses, phone numbers and email addresses. Everything but the email address could be modified; that field was read-only. So, naturally, my first thought was to try changing the email address. I manipulated the email address parameter in the request and sent it, expecting a response. The server returned a 200 OK status, but the change didn’t happen, most likely because the server was verifying whether the user was authorized to perform this action. And mine wasn’t.
The request where I changed the user information used `userId` as a parameter. This parameter identifies which user’s details are being modified.
I changed the `userId` parameter by performing a standard insecure direct object references (IDOR) vulnerability test and discovered that the user was able to change information not only for themselves, but also for users with high-privilege accounts.
Is this enough? Technically, I could have reported it as an IDOR vulnerability. However, I decided to spend more time exploring the application. Identifying access control vulnerabilities often benefits from a deeper understanding of the application and its unique functionalities.
Most other areas of the application contained read-only data specific to the organization. Outside of these, I discovered that the user could edit their own information—except for the associated email address—in the Profile section. There was also a section where the user could change their password by requesting that a multi-factor authentication (MFA) code be sent to the email address associated with their account. An extra protection is configured here.
At this point, I wanted to try something different. I returned to the request where I had changed the information for a high-privileged user. In the body of the request, I added the `password` parameter used when changing the password and entered a password of my choosing. The request responded with a 200 OK status. But did I really change the user’s password? I attempted to log in with the high-privileged user’s email address and the password I set in a different browser, and boom! I successfully logged into the account.
So, I took over a high-privileged account. The important point here was to perform an account takeover from a simple IDOR vulnerability. With access control vulnerabilities, thoroughly exploring the application and understanding its functions often provides a significant advantage.
Thank you for reading!
