Full Report
While browsing Shodan one day, they noticed a subdomain associated with Microsoft - guest.microsoft.com. Once logged in via a phone number, no information was given. This seemed like it wasn't meant to be publicly accessible. Looking at the Burp Suite logs, they found an interesting API relating to their previous stays: /api/v1/config/ with a JSON parameter called buildingIds. Since they had not visited any buildings, none of the information was provided, though the array of buildings was empty. By providing an ID of 1, they were able to see some building information. Surprisingly, a lot of building information was provided: access codes in some of them, address/building name, parking info, GPS coordinates, QR code data, Microsoft employee emails, etc. After iterating over more IDs, they found buildings from Israel to the United States. They wanted to increase the impact some more. After some more effort reversing the JavaScript, they found the API /api/v1/host. By providing an email, PII about the employee, such as phone number, office location, mailing address, and more was provided. The same issue existed on guests based upon their email as well. They couldn't find any exposed APIs around explicit visits, so they tried digging further. They tried for some path traversals via secondary context vulnerabilities. After using ..%2f..%2f..%2f or ../../../ URL encoded, they were able to get an Azure functions page. But why!? The proxy was decoding the URL encoded / and being used by the actual Azure function. Neat! After some directory brute forcing, they got a 500 error at /api/visits/visit/test. Eventually, they managed to get this working to retrieve a wide range of invitation and meeting information. Sadly, they got nothing for the vulnerability: it was moved to review/repo, fixed, and no payment was ever made. Regardless, it was a good set of vulns!
Analysis Summary
# Vulnerability: Microsoft Guest Check-In API Exposure of Sensitive Data via Insecure Direct Object Reference (IDOR) and Path Traversal
## CVE Details
- CVE ID: N/A (Not officially assigned/disclosed as of this summary)
- CVSS Score: N/A (Severity assessed based on impact)
- CWE: CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor), CWE-22 (Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'))
## Affected Systems
- Products: Microsoft Guest Check-In Service (hosted on `guest.microsoft.com` and utilizing `dwp.azure-api.net` endpoints).
- Versions: Unknown. The vulnerability exists in the API implementation layer of the service discovered by the researcher.
- Configurations: A user logged into the guest portal via a phone number.
## Vulnerability Description
This submission details multiple vulnerabilities found across several API endpoints related to Microsoft's Guest Check-In service, leading to large-scale data exposure:
1. **Insecure Direct Object Reference (IDOR) in `/api/v1/config/`**: By iterating through sequential or varied `buildingIds` in a POST request to this endpoint, the system exposed detailed information for numerous Microsoft physical locations globally. This data included **access codes, GPS coordinates, building addresses, parking information, and Microsoft employee emails (aliases)**.
2. **IDOR in `/api/v1/host/:EMAIL`**: Using valid Microsoft employee emails discovered from the previous step, this endpoint exposed **Personally Identifiable Information (PII)** of the host, including full name, phone number, office location, mailing address, and Employee ID. A similar endpoint, `/api/v1/guest/:EMAIL`, exposed PII for guests.
3. **IDOR/Forced Retrieval via `/api/visits/visit/:visitId` (via Path Traversal)**: The researcher discovered that the application's proxy was decoding URL-encoded slashes (`%2f`) before the Azure Function endpoint, enabling Path Traversal attempts (e.g., `..%2f..%2f..%2f`). This was leveraged to access the broader API structure, specifically finding the `/api/visits/visit/test` action. By supplying valid `visitId`s (obtained from partial lookups), the attacker could retrieve extensive details about specific visits, including **invite IDs, batch IDs, conference room details, and specific guest registration/scheduling information**. Replaying this on the `/group/` endpoint exposed details about **presenters (emails/names) and guest counts**.
## Exploitation
- Status: PoC available (demonstrated via sequence of API calls in the report). **Not reported as exploited in the wild.**
- Complexity: Low (Authenticated session required, but information access required simple sequential/iterative requests or basic path traversal knowledge).
- Attack Vector: Network (Requires access to the authenticated guest portal).
## Impact
- Confidentiality: **High** (Exposure of internal building plans, access controls, and sensitive PII/contact details for thousands of employees and guests).
- Integrity: Low (No evidence of data modification).
- Availability: Low (Service disruption minimal, only API queries were performed).
## Remediation
### Patches
- The report mentions the vulnerability moved to review/repo and was **fixed**. Specific patch versions or advisory numbers were not provided in the source material, as this was a direct researcher report.
### Workarounds
- **Immediate Action:** Restrict HTTP methods to expected parameters only. Implement strict input validation on all ID parameters (`buildingIds`, `visitId`, etc.) to exclusively allow known, valid values (whitelisting).
- **Path Traversal Mitigation:** Ensure all input used in path construction by server-side code (especially proxies or Azure Functions) is fully sanitized or URL-decoded *only* at the intended point, not by an intermediary proxy/component that might expose raw components to backend logic.
## Detection
- **Indicators of Compromise (IoCs):**
- High volume of sequential requests to `/api/v1/config/` using incrementally numbered `buildingIds`.
- Extensive use of API endpoints like `/api/v1/host/:EMAIL` or targeted calls to sensitive endpoints like `/api/visits/visit/:visitId`.
- Detection of URL-encoded path traversal sequences (`%2f`, `..%2f` or `../`) in request paths hitting APIs that should only respond to direct resource identifiers.
- **Detection Methods and Tools:**
- API Gateways and WAFs should monitor for anomalous request patterns like deep enumeration of numerical IDs or unauthorized path traversal sequences targeting internal API functions.
## References
- Vendor advisories: None provided in the source document.
- Relevant links - defanged: `gist.github.com/bribes/fea1718f19ea81edf374edb7a8ef43d4`