Azure API Management flaws highlight server-side request forgery risks in API development

Microsoft recently patched three vulnerabilities in its Azure API Management service, two of which enabled server-side request forgery (SSRF) attacks that could have allowed hackers to access internal Azure assets. The proof-of-concept exploits serve to highlight common errors that developers could make when trying to implement blacklist-based restrictions for their own APIs and services.

Web APIs have become an integral part of modern application development, especially in the cloud. They allow services to communicate and exchange data, non-browser clients such as mobile apps and IoT devices to securely access data and perform operations on behalf of users, and companies to abstract older server backends and quickly interconnect them with modern apps and services. APIs are standardized and easy to interact with rather than relying on custom and legacy protocols that were not built for the web.

With companies pushing out APIs in production at a rapid pace in recent years, the number of attacks targeting them has spiked as attackers increasingly realize that insecure APIs might offer a backdoor into databases and internal infrastructure. According to global content delivery network provider Akamai, the number of attacks targeting APIs and web applications grew 2.5 times in 2022 compared to 2021. One of the emergent attack vectors over the past two years has been SSRF. The ProxyLogon, ProxyNotShell, and OWASSRF flaws in Microsoft Exchange servers are notable examples that have seen massive exploitation.

Over the past two years, Akamai has seen a steady increase in both attack attempts and authorized vulnerability-scanning traffic looking for SSRF vulnerabilities in software other than Microsoft Exchange,” Akamai said in a recent report. “‘In addition, we saw a daily average of 14 million SSRF attempts probing our App & API Protector customers’ web applications and APIs, suggesting the growing prevalence of this vector. It is worth noting this growth and the potential impact that SSRF exploitation poses to organizations.”

SSRF via Azure API Management proxies

Microsoft’s Azure API Management is a service that allows companies to expose services hosted on Azure or inside their private networks as APIs and to monitor them. It’s a service aimed at API developers that consists of an API gateway, a management plane, and a developer portal.

In an SSRF attack, the attacker must find a way to use the application’s functionality as a proxy to access internal resources, piggybacking on the server’s privileged position and access to the internal network. In other words, if an application or API allows users to supply an URL and will then crawl that URL and return the response, an SSRF attack is possible if additional security measures are not taken.

Azure API Management has such a feature. It allows users to specify a schema for the structure of JSON or XML data that’s expected to be exchanged through the API they deploy. However, according to researchers from security firm Ermetic, the service can also be instructed to determine the schema automatically by making a request to a user-supplied URL, this feature being called “Import from URL.” “Once you have specified the URL of the schema, the Azure API Management CORS proxy retrieves the schema from the specified URL by sending it an HTTP request,” the researchers said in their report.

Cross-origin resource sharing (CORS) is a mechanism based on HTTP headers that allows a web server to indicate to browsers other origins (servers) from where resources such as scripts are allowed to be loaded. The CORS proxy in this case intercepts requests and modifies the CORS headers to make sure that cross-domain requests between portal.azure.com and other servers are allowed.

Once they found this feature, the Ermetic researchers thought to provide http://localhost or http://127.0.1.1 (the loopback address) as the remote URL for fetching a schema to see if the CORS proxy would reach out internally to the server itself, achieving SSRF. This resulted in a HTTP 403 error (Forbidden), suggesting there was a blacklist in place.

Then the researchers registered a domain called localhost.me and then edited its DNS records to point to 127.0.1.1. So, when the CORS proxy tried to access http://localhost.me, it would first resolve the DNS and try to access the returned IP address, which points back to itself bypassing the blacklist. This worked. The response reflected back by the CORS proxy was HTTP error 404 (Page not found), meaning the server no longer refused the request but didn’t have a page to serve.

The researchers also found that they could add custom headers to their requests and these would be proxied by the CORS proxy to the target server, opening the door to even more complex attacks. Then they tried to access the internal server on different port numbers, not the default 80 to probe if other services might be running on custom ports and noticed that when they tried port numbers that included “300,” such as 300, 3000, or 30000, they got error 403 Forbidden again.

“We understood that if a regex [regular expression] exists specifically for those ports, some important services must be listening on those ports,” the researchers said.

A regex is a search-and-match rule that can be used to build blacklists. For example, the rule could match any URL that includes the term localhost and a port number formed from 300 in the request. The researchers inferred that if a regex exists, it must apply to a value called “Ocp-Apim-Url” in the request headers that defines the URL the CORS proxy reaches out to. Therefore, they used a URL to a domain they controlled which then redirected the proxy back to http://localhost:30001 for example.

This worked and bypassed the blacklist yet again, allowing the researchers to discover and access internal services on different port numbers: 30001 – Authenticated view of the developer portal, 30004 – Azure’s Management API, 30005 – Azure’s Kudu API management, 30006 – Unpublished developer site (unauthenticated). Kudu is the engine that powers some management features of the Azure App Service, a service for hosting and deploying web applications on Azure.

SSRF vulnerabilities reveal blacklisting weaknesses as a defense

This SSRF vulnerability via CORS proxy is similar to one found by researchers from Orca Security in the same service back in November. Ermetic reported its findings to Microsoft in December and thought that it might be the same vulnerability. However, their exploit bypassed the fixes Microsoft put in place after Orca reported the original flaw, making it a separate vulnerability. This highlights the difficulties in relying on blacklisting techniques such as regex as a defense mechanism for these types of features, as there are always multiple ways to bypass them.

The Ermetic researchers didn’t stop their analysis there and found a second SSRF, this time in the Azure API Management Hosting Proxy — a different proxy that’s used to dynamically configure the backend service URL for an API when creating it.

“When a request is sent from the frontend that the user specifies, the request will be sent to the inbound processing proxy and then to the specified backend,” the researchers said. In the process, the proxy will make modifications to the request based on policies defined by the user for inbound and outbound processing.

The researchers found that a user could configure the set-backend-service policy to point to http://localhost instead of their real API backend service URL, therefore tricking the proxy to direct requests received from the API frontend to itself.

“Since we had control over the frontend and inbound processing policies, we could send the SSRF with an HTTP verb/method and custom headers of our choosing,” they said. “We were able to access an internal HTTP port 80 for a POC [proof-of-concept].”

For both vulnerabilities, the researchers stopped their investigation to avoid harm to internal services and infrastructure or risk accessing sensitive data through the SSRF probing that normally would require authentication.

Path traversal vulnerability in API Management Developer Portal

Finally, the researchers were also able to find an unrestricted file upload feature in the API Management Developer Portal that resulted in path traversal. This had the potential to impact any self-hosted API Management developer portals deployed by end users as well on their own infrastructure.

“We found that Azure does not validate the file type and path of the files uploaded,” the researchers said. “Authenticated users can traverse the path specified when uploading the files, upload malicious files to the developer portal server and possibly execute code on it using DLL hijacking, iisnode config swapping or any other relevant attack vector.”