Full Report
Azure API connections allow for cloud-based access to an API behind a logged-in proxy. This allowed for the website to not worry about OAuth dance on Slack and other types of apps. They contain different roles, such as reader. While reviewing one of the requests, they noticed two fields: testLinks and testRequests. This was a generalized way to test the APIs to ensure they were functional. In the case of a credential change, this would be a useful thing for the application and user to know. The developer specifies the path of the request and the method to use. Unfortunately, this is too generic. This is just a proxy now! Any path can be specified, even if the role shouldn't have access to it. This is a case of a user being able to control information they shouldn't because the developer made it modular. Using this, the reader could query more sensitive information than intended on data resources. Azure key vaults, SQL database queries, Jira information, and other extra data could be queried. From what I gathered, the user needs the reader's permission to do this. So, a privilege escalation in the same account but nothing more. The response was funny to me. Initially, it was closed but the author reopened the issue to get it approved. They reported these as two findings: one got paid out and another closed as a duplicate. Overall, good write-up!
Analysis Summary
# Vulnerability: Azure API Connections Unauthorized Proxy Access
## CVE Details
- **CVE ID**: Not assigned (Reported via Microsoft Bug Bounty)
- **CVSS Score**: Not explicitly provided (Estimated Medium/High based on privilege escalation and data access)
- **CWE**: CWE-285: Improper Authorization; CWE-441: Unintended Proxy or Intermediary (Confused Deputy)
## Affected Systems
- **Products**: Microsoft Azure API Connections (Managed Connectors)
- **Versions**: Cloud-based service (Pre-patch versions prior to January 2025)
- **Configurations**: Any Azure API Connection (e.g., Slack, Jira, Key Vault, SQL) where a user has "Reader" role permissions.
## Vulnerability Description
Azure API Connections utilized undocumented endpoints (`/extensions/proxy` and `/dynamicInvoke`) intended for testing connectivity. The application logic was overly modular and failed to enforce granular authorization checks.
A user with only **Reader** permissions—which should typically only allow viewing metadata—could use these endpoints as an authenticated proxy. By manipulating the `path` and `method` fields in a request to the Azure Management API, an attacker could force the connection to execute arbitrary API calls against the backend service (e.g., Slack, Jira, SQL) using the connection's stored credentials (OAuth tokens).
## Exploitation
- **Status**: PoC available (Reported and fixed)
- **Complexity**: Low
- **Attack Vector**: Network (via Azure Management API)
## Impact
- **Confidentiality**: **High** (Allows reading sensitive data from connected third-party SaaS and internal Azure resources like Key Vaults or SQL databases).
- **Integrity**: **High** (Depending on the connector, the proxy allowed `POST/PUT/DELETE` methods, enabling modification of data).
- **Availability**: **Medium** (Potential to delete resources or trigger rate limits on critical APIs).
## Remediation
### Patches
- **Microsoft Fix (Jan 2025)**: Microsoft updated the API Connection logic to restrict requests. Specifically, the `/extensions/proxy` endpoint was disabled for arbitrary requests, and restrictions were placed on the `testRequests` functionality to prevent generic proxying.
### Workarounds
- **Least Privilege**: Ensure users are granted the minimum necessary RBAC roles. Avoid granting "Reader" access to resource groups containing sensitive API Connections to users who do not require it.
- **Resource Isolation**: Place API Connections in dedicated Resource Groups with strict access control lists (ACLs).
## Detection
- **Indicators of Compromise**: Monitor Azure Activity Logs for unusual `POST` requests to the `extensions/proxy` or `dynamicInvoke` endpoints, especially those originating from users with low-privilege roles.
- **Detection Methods**: Audit logs for Managed Connectors (Microsoft.Web/connections) for unexpected outbound traffic patterns to backend SaaS providers.
## References
- **Original Research**: hxxps[://]binarysecurity[.]no/posts/2025/03/azures-weakest-link-api-connections-spill-secrets
- **Vendor**: hxxps[://]management[.]azure[.]com