Unauthorized user leads to modify email

Hello, bug hunters, security professionals, and loyal readers of Saello Write Up. In the world of cybersecurity, we often encounter various levels of user access rights. However, what happens if a role with intermediate access rights, like a "Manager," turns out to have a hidden capability to take over the accounts of regular users? Today, I will dissect a critical finding: a combination of Insecure Direct Object Reference (IDOR) and Broken Access Control on "the platform we'll call X" that allowed this to happen.

Initial Investigation: Identifying Manager Interaction Points with User Data

My first step was to map out the functionalities a Manager had concerning other users. I found a feature in the Manager's panel that allowed updating some minor details of a Regular User, for example, their username and department. Let's call the endpoint for this function /api/v1/manage/update_user_profile.

When I tried to change the department of a Regular User (with ID 123), the request sent via Burp Suite looked like this:

Legitimate Request by Manager:

HTTP

POST /api/v1/manage/update_user_profile HTTP/1.1
Host: platform-x.com
Authorization: Bearer [MANAGER_TOKEN]
Content-Type: application/json
{
  "user_id": "123",
  "profile_data": {
    "username": "Udin",
    "department": "Sales"
  }
}

The server responded with a 200 OK, and the Regular User's username and department were successfully updated. The UI displayed fields such as username, department, and email, but the Manager was only allowed to change the username and department; there was no option to change the Regular User's email.

Hypothesis: Bypassing Restrictions Through an Additional Parameter

Looking at the JSON structure and the existing endpoint, a question arose:

1. Does this /api/v1/manage/update_user_profile endpoint only validate my role as a Manager to access it?
2. Or, does it also strictly validate every field within profile_data that I am allowed to change for the target user_id?

My hypothesis was the possibility of a Mass Assignment vulnerability compounded by IDOR. This meant I could already target a specific user_id (the IDOR component was present and legitimate for some fields). Now, what if I tried to slip the email field into the profile_data object, even though the UI does not allow it for the Manager role?

Execution: Covert Operation to Change a Regular User's Email

I took the previous legitimate request in Burp Repeater and modified the JSON payload. I kept the user_id of the Regular User I wanted to target, but within the profile_data object, I added an email parameter with a new email address that I control.

Modified Request by Manager:

HTTP

POST /api/v1/manage/update_user_profile HTTP/1.1
Host: platform-x.com
Authorization: Bearer [MANAGER_TOKEN]
Content-Type: application/json
{
  "user_id": "123",
  "profile_data": {
    "username": "Udin",
    "department": "Sales", 
    "email": "budi123@example.com" 
  }
}

With bated breath, I sent this request. And... a 200 OK response greeted me again! The server accepted the changes without complaint.

The final step was verification. I attempted to verify by triggering the "Forgot Password" feature for that regular user.

And sure enough! The email address for the regular user (123) had been successfully changed by my Manager account. I now had full control over the email associated with that Regular User's account.

Impact of the Vulnerability: From Manager to Account Controller

A Manager's ability to change a Regular User's email address without authorization is a vulnerability with a very high impact:

1. Full Account Takeover: A Manager can easily take over any Regular User's account by changing their email and then initiating a password reset.
2. Unauthorized Access to Sensitive Data: Once an account is taken over, the Manager gains access to all data and functionalities available to that Regular User.
3. Potential for Further Abuse: Compromised accounts can be used for malicious activities, spreading misinformation, or even as a stepping stone for further attacks within the system.
4. Insider Threat Risk: A malicious Manager (an insider threat) could abuse this flaw massively without being detected for a long time.

Technical Root Cause Analysis

This vulnerability is a classic combination of:

• Insecure Direct Object Reference (IDOR): The endpoint allowed the Manager to specify the target user_id they wanted to modify.
• Mass Assignment / Field-Level Broken Access Control: The /api/v1/manage/update_user_profile API endpoint failed to perform sufficiently strict validation on every field sent in the profile_data payload. Although the Manager role was verified for accessing the endpoint and specific user objects, there was no check to see if the Manager was authorized to change the email field for that user. The API should have only processed fields explicitly allowed for modification by the Manager role (like username and department in this example) and ignored or rejected other fields like email.

In conclusion, findings like this demonstrate that even with seemingly well-defined systems of roles and access rights, critical vulnerabilities can still emerge if validation is not performed comprehensively at every layer.

Stay vigilant and happy hunting!

Regards,

Saello