Escalating from Reader to Contributor in Azure API Management

Regular users with reader-level privileges could escalate these privileges to access the keys of any APIM user via the Azure Resource Manager Rest API. 

These keys enabled users to generate Shared Access Signatures.  They could then:

1.  use to authenticate into the Direct Management API 
2. perform management operations on the API Management resource.

The ARM API is also used during this process. Although this API now restricts users with Reader permissions, older versions would allow these users to:

1.  bypass the restrictions 
2. view all subscription keys that enabled them to talk to APIs exposed via APIM. 
3. read client credentials for any identity provider service principal and interact with the Direct Management API. 

Since then, Microsoft has added a measure that enforces a minimum ARM API version to address the vulnerabilities in older versions. But this has to be applied individually for each resource. 

If this minimum restriction is applied to a newer API, the reader-level user will turn up a “No access” dialogue when they attempt to query for subscription keys. 

However, the bug allows readers to bypass these restrictions by accessing keys belonging to actual admin users, which cannot be deleted and can be used to create Shared Access Signatures and enable further privileged access.

Microsoft may have missed this API endpoint when new API versions were implemented to fix the vulnerabilities in older versions.

It took Microsoft over a month to fix this bug, despite its critical severity level. However, it calls into question - how many other APIs may have similar issues?

Conclusion

One of the most interesting aspects of this vulnerability is that the vulnerability appears on a managemet API of a popular cloud platform. All cloud platforms nowadays are managed via APIs, even when used via the web UI management console. So any vulnerability on a management API affects thousands of accounts by definition. 

Secondly, the vulnerability only appeared on an old, and possibly deprecated, release version of the API. It’s likely that the older, vulnerable version was in use by customers via code or CLI integrations, so Microsoft felt that they had to keep it online. This is a false assumption, however, as vulnerabilities can be fixed, and version-coded URLs can be redirected to patched versions. The time taken from disclosure to fix leaves a lot of risk of exploitation.  

Finally, Microsoft controls which versions of an API are active and available. Yes, customers can change which version they use in their own CLI and code integrations. But customer’s can explicitly deny requests against particular versions, nor can customers block access to older versions of an API. So in the shared responsibility model, this responsibility falls on the cloud service provider. The implications are broad and of high risk. 

What should we consider for our own APIs?

The main keys to consider for situations like this are:

• Visibility - know what APIs are running. Know which versions of APIs are running. If there’s an older version of an API, with vulnerabilities, still running (sometimes referred to as zombie or ghost APIs), know about it.
• Version control and API documentation - this goes together with good visibility and good governance. 

To learn more about API security and see how FireTail can help with your API security posture, schedule a demo here. Or, try it out yourself for free here.