Easily hack into Azure internal workloads & API using Azure API Management service flaws

The Azure API Management service is a platform that is completely managed and offers businesses the ability to design, administer, protect, and evaluate their application programming interfaces (APIs) in any environment. It offers a centralized location from which APIs can be easily published to both internal and external developers, as well as to partners and employees. With Azure API Management, businesses are able to confidently grow their API program while also ensuring that their APIs are accessible, safe, and function to the best of their abilities. The ability to create schemas for the structure of data that will be sent over the API is included in the administration of APIs. The structure of the data may be validated with the use of these schemas, which companies can employ to assure compatibility between API clients and servers. Using either the Azure API Management site or the REST API, you should be able to build and maintain schemas.

Recent study conducted by the Ermetic research team uncovered three vulnerabilities in the Azure API Management service. On an internal Azure workload, these included two SSRF vulnerabilities, which stand for server-side request forgery, and a file upload path traversal vulnerability. In the API Management developer interface, the vulnerabilities were triggered by using url formatting bypasses and an unfettered file upload feature. SSRF is a vulnerability that gives an attacker the ability to submit a constructed request from a susceptible server to a selected external or internal server or service. An attacker may exploit this vulnerability to get access to sensitive information. Attackers would be able to submit malicious files to Azure’s hosted internal workload as well as to self-hosted developer portals if the file upload path traversal vulnerability was exploited.

Full SSRF on Azure API Management CORS Proxy

Customers are now able to get a schema from a URL and use it in their API thanks to the addition of the “Import from URL” capability in Azure API Management. This feature was built by Azure. When you have finished specifying the URL of the schema, the Azure API Management CORS Proxy will retrieve the schema by sending an HTTP request to the specified URL in order to retrieve it. Through the process of intercepting, modifying, and adding CORS headers, the CORS Proxy enables communication that is uninterrupted across domains.

Attackers might make requests between the service’s CORS Proxy and the hosting proxy itself by utilizing the SSRF vulnerabilities. This would allow the attackers to access internal Azure assets, refuse service, and circumvent web application firewalls.

They were able to access Azure internal services by using this to overcome the redirection in the following ports:

30001 – Authenticated view of the developer portal 

30004 – Azure’s Management API

30005 – Azure’s Kudu API management

30006 – Unpublished developer site (Unauth)

After entering the Ocp-Apim-Url that pointed to their redirect server, they received a visit from the CORS Proxy, which successfully followed their redirect to the following location: http://localhost:30005/test.

Full SSRF on the Azure API Management Hosting Proxy

Users have the ability to specify the frontend, backend, inbound, and outbound processing of the API while they are configuring the service. When configuring an API’s backend service URL in a dynamic manner, the “set-backend-service” policy is what you’ll need to use. The “base-url” parameter’s value is used to determine what the backend URL will be set to when the policy is applied.During the investigation of the functionality, they discovered that the API Management proxy, located at https://apimanagement.hosting.portal.azure.net/, was used in both the incoming and the outgoing processing to establish the rules. A request that is made from the frontend that the user specifies will first be sent to the inbound processing proxy, and then it will be forwarded to the backend that the user has defined.

Abusing the set-backend-service policy and directing it to the desired site for an SSRF exploit, such as http://localhost, is one way that SSRF might be abused.

Unrestricted File Upload Path Traversal in the API Management Developer Portal

Additionally, they investigated the Azure developer portal for the API Management service, and during investigation, they found that the server supported unrestricted file uploads. The authorized mode of the developer portal gives you the ability to submit static files and graphics that may be displayed on your own dedicated portal. In a nutshell, this finding has repercussions not just for Microsoft Azure itself but also for end customers who have independently set up the developer portal. On a portal “publish,” the files are uploaded to a special Azure blob and the developer portal filesystem, both of which are hosted by Azure and are unavailable to Azure users. Through the developer portal, users can access the files under the path that has been specified, as well as under /content/x.png as the default location.

It has come to notice that Azure does not check either the file type or the location of the uploaded files. Authenticated users are able to traverse the path that is indicated when files are being uploaded, upload malicious files to the developer portal server, and perhaps execute code on it by employing DLL hijacking, iisnode config swapping, or any other appropriate attack vector. Authenticated users may also download files from the server.

Azure’s API Management service was made vulnerable due to these three different vulnerabilities, all of which have now been fixed by MSRC.