This is my continued responsible disclosure blog on Microsoft products. If you didn’t read my previous blog, you can get it from here.
Today, I will share how I discover IDOR vulnerability in Microsoft Partner application which exposes all Microsoft Azure Independent Software Vendors.
What is Insecure Direct Object Reference / IDOR?
Insecure direct object reference (IDOR) is a type of access control vulnerability that arises when an application uses a user supplied input to access an objects directly without properly checking permission of a user. The application solely relies on the presence of a valid session.
Suppose, a fictional user ‘Negus’ is fetching his detail information from our vulnerable ‘mynotsecureapp.com’ application. Keep in mind his userId is 1055.
Result: Personal identifiable information of the user retrieved from the backend database:
"First Name": "Negus",
"Last Name": "Ezana",
"Place of Birth": "Bahir Dar",
From the above example, userId parameter is interesting - from attacker or curious user perspective. Let’s say ‘Negus’ is a curious user & he wants to see the details of next user in sequence i.e. userId 1056.
Result: Negus was able to disclose personal identifiable information of ‘Mahelete’.
"First Name": "Mahelete",
"Last Name": "Solomon",
"Place of Birth": "Addis Ababa",
Based on the above example, our curious user was able to read other users’ personal identifier information by circumventing the authorization mechanism. Hence, we can safely say the application is vulnerable to IDOR.
An attacker can exploit the above security vulnerability to extract all user detail information and use it for many nefarious purpose. In a simple term, it leads to a huge financial and reputational damage to owner of the application.
It sounds unrealistic right? Unfortunately, it is a very common security vulnerability. An attacker needs one vulnerable endpoint to exploit, while the defender needs to protect all endpoints (attacker-defender dilemma).
We covered basics of IDOR. In the next section, we will deep-dive into the main topic — exploiting IDOR in Microsoft Partner.
Exploiting IDOR in Microsoft Partner application
Microsoft provides a platform for their independent software vendors to centrally build, manage and sell their solution. Partners can use Microsoft Partner portal for managing publishers, users, commercial market place etc.
In this blog, I will share IDOR vulnerability which exposes all Microsoft Partner users.
Once registered to Microsoft Partner application you can access the Partner portal by directly browsing to its URL — https://partner.microsoft.com
You can fetch the details of sellers under your ‘Organization Profile’. Each seller in your account identified by 8 digit ID. For example, 76xxxx10 is one of my sellerId.
Here is the underlying API request and response used to fetch publisher/seller details. Please note, the sellerId of the currently logged in user is 76????10.
GET /en-us/dashboard/account/<reduct>/<reduct>/<reduct>/<reduct>/76????10/users HTTP/2
Response: The application returns the details of publishers.
Close analysis reveals ‘sellerId’ parameter value seems sequential in nature. Hence, I attempt to read other customer data before and after my sellerId.
My seller id is 76????10 to disclose another user next to my sellerId is just adding 10:
76????10 + 10 = 76????20
GET /en-us/dashboard/account/<reduct>/<reduct>/<reduct>/<reduct>/76????20/users HTTP/2
Response: The application discloses other customers detail without verifying users’ authorization. It is unexpected behavior or security vulnerability.
Another example of user — 76????10-10 = 76????00
GET /en-us/dashboard/account/<reduct>/<reduct>/<reduct>/<reduct>/76????00/users HTTP/2
The application is clearly vulnerable to IDOR. An attacker can fetch randomly any publisher’s detail.
Randomly accessing other Microsoft Partner Information
GET /en-us/dashboard/account/<reduct>/<reduct>/<reduct>/<reduct>/3?????30/users HTTP/2
GET /en-us/dashboard/account/<reduct>/<reduct>/<reduct>/<reduct>/2?????50/users HTTP/2
Automating the Exploit
Since the application doesn’t have rate limiting and the sellerId is sequential, the entire process can be automated to extract thousands of customers detail:
During security review, it was possible to fetch numerous companies publisher information including Microsoft’s different team (blockchain team, AKS Engine team etc.) and other important Microsoft Partners.
- Implement rate-limiting (why we let a user to send thousands of request to a single endpoint within short period time?)
- Utilize a randomized strings to identify objects (user, account, customer etc.)
- Detect and respond anomalies in realtime
- S-SDLC is a key
- Security Code Review ( manual & automated)
- Perform penetration testing in any product before release it to prod
- Logging and monitoring
- Aug 21, 2021 — Reported to Microsoft
- Aug 21, 2021 — Case Manager assigns a case to the defect
- Sep 07, 2021 — Triage
- Sep 10, 2021 — Vulnerability was fixed
- Dec 10, 2021 — Writeup Request