Broken Access Control

Introduction

As a part of Microsoft coordinated vulnerability disclosures, I would like to share a critical vulnerability within the dynamics portal which could allow an attacker to access personally identifiable information (first name, last name, email address, MPN ID etc.) of users of the Microsoft Dynamics for 365 Partner website.

Technical Details:

Step 0x01: Login to ‘Dynamics 365 for Partners’ portal using my valid partner account:

https://dynamicspartners.xxxxx.microsoft.com/

Step 0x02: The above application invokes different API calls in the background. Let’s closely analyze the following interesting API call, which fetches details of currently logged in user.

Request

Endpoint: /api/Users/email?emailId=maotg@???.onmicrosoft.com
Host: landingapi-prod.azurewebsites.net
Authorization: Bearer eyJ....

The ‘emailId’ parameter by default takes currently logged in user email address:

Response

The application returns first & last name, email address, MPNID, AAD Profile ID, role name etc. of currently logged in user.

Step 0x03: [Vulnerability/Unexpected behavior] One important test case here trying to access other users on the dynamics portal system details using their email address.

The following is unauthorized reading of other users of the system information by using their email address. The application discloses the details of the user without checking for an additional authorization on the API call. For this example, I use email address of my second testing account.

Request

Endpoint: /api/Users/email?emailId=moxxx@???.onmicrosoft.com
Host: landingapi-prod.azurewebsites.net
Authorization: Bearer eyJ....

Response

The application discloses first & last name, email address, MPNID, AAD Profile ID, role name etc. of another application user without authorization. However, in order to exploit this vulnerability, the attacker should know in advanced the email address of other site user of the dynamics portal.

Step 0x04: The following a way to disclose all user data (~112MB) without secondary authorization.

For this test case instead of /api/Users/email?emailId=<email address> I directly invoke the API to /api/Users:

Request

Endpoint: /api/Users
Host: landingapi-prod.azurewebsites.net
Authorization: Bearer eyJ....

Response:

112 megabytes of website users’ detail which is likely over 100,000 users.

Disclaimer

The following blog is for informational and educational purpose only. I am not responsible for the misuse of the information in this blog.

Timeline:

Aug 04, 2021 — Reported to Microsoft

Aug 05, 2021 — Case Manger assigns a case to the defect

Aug 12, 2021 — A fix was completed and communicated to the finder.

Sept 27, 2021 — Finder notification of intent to go public.

Dec 16, 2021 — Approval for write-up

Final Note:

I would like to thank MSRC team who assist and help me throughout this responsible vulnerability disclosure process. Special thanks to Jim & Kriti.

--

--

--

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

How to start staking?

{UPDATE} My Town - High Street Dreams Hack Free Resources Generator

Cloud Data Security: Adopt a Zero Trust Approach

Thoughts on Data Security

API Trialing, Abuse Contact API, and IPinfo at Black Hat and DEF CON

What could the Internet of the future look like?

Joining the Vigor DAC Couldn’t Be Easier. Just Ask Buck!

XXE — TryHackme WriteUp

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Meareg | ማዕረግ | 𐩧𐩴oמארג | 𐩣

Meareg | ማዕረግ | 𐩧𐩴oמארג | 𐩣

Security Researcher

More from Medium

Intigriti’s January 0122 XSS challenge Write Up

Tweet by @Intigriti

How I found High-Priority PII leak through web archive

Timing-Based Username Enumeration: What’s a fix versus mitigation?

No Rate Limiting on OTP sending