Welcome back to another writeup. I want to share how I chained two IDORs together to take over any user account without any interaction. This came from two programs I hacked in 2021. One of them was a helpdesk app where I spent a few months and found many issues. The app had three roles: admin, manager, and user. Admins manage everything, managers have most access except org settings, and users only do assigned tasks.
An admin can create departments and assign managers to them. Departments may represent new hires, salaries, or projects. Admins can also add or edit users, change their email, change passwords, and lock accounts. I found one IDOR in the department assignment flow and another in the user edit flow. Each alone looked small, but together they allowed a full account takeover.
The first IDOR was in the assign department action. The flow was simple. You create a department, add a manager, and click save. The request contains the manager ID. By changing that manager ID to another manager's ID, the app would add that manager to the department. In short, I could add a manager from another organization into my department. That manager was not part of my organization it belonged to a different org. That distinction matters because it means we can target managers who are external to our own org.
I considered submitting the first IDOR as a low impact issue, since it mostly lets you spam managers by adding them to many departments. I documented it and moved on. Next I checked the user edit feature where admins can change a user or manager's email and password. I captured a password change request in Burp and noticed the request included the user id.
I replaced the id with the manager id from my second test account and sent the request. The server returned 200 and the password changed. I was able to log in to that manager account with the new password. At first it looked like a clear P1, but when I started recording a video proof it stopped working. During the PoC the request returned 403 instead of 200. I wondered why it worked before and not during the video.
It turned out the password change only worked for managers who were currently in my department. In my first successful test I had previously added that manager into my department using the first IDOR. During the PoC I tried to change a manager who was not in my department and got 403. That is when the chain became clear: to change a manager's password you first have to add that manager into your department using the department IDOR. After adding them, the user edit IDOR works and allows password updates.
I recorded a clean reproduction where I first used the department assign IDOR to add the target manager into my department. Then I modified the password change request to target that manager id and got 200. I logged into the manager account using the new password and captured the session. I wrote a concise report and submitted it with a video PoC. After a few days the report was triaged and accepted as P1.
Both IDORs were simple on their own. The department assign IDOR let me add managers into my department by changing an id in the request. The user edit IDOR let me change password and email by replacing the id. When combined, they gave me account takeover. Because the first IDOR lets you bring in managers from other organizations, the chain can be used to target accounts that do not belong to your org. In practice I verified the same technique allowed takeover of admin accounts from other organizations as well admins were reachable by the same flows and could be targeted using the chain.
It took some persistence to notice the link between the two flows. The lesson I want to share is do not ignore small findings. Try to connect them. If one flow seems harmless on its own, ask how it might be used together with other actions. That mindset often turns small issues into high impact findings.
If you have feedback or questions DM me on Linkedin Sheraz Khalid. Thanks for reading. I will see you in the next writeup.