In this blog we describe how we uncovered an important Server-Side Request Forgery (SSRF) Vulnerability on Azure API Management Service, allowing any authenticated user to request any URL abusing the server. We reported this vulnerability to Microsoft on November 12th, and it was fixed on November 16th 2022.
This vulnerability is one of four instances discovered by Orca Security between October and December 2022, where we found that different Azure services were vulnerable to a Server Side Request Forgery (SSRF) attack.
About the Azure API Management Service
Azure API Management consists of an API gateway, a management plane, and a developer portal. These components are Azure-hosted and fully managed by default. Azure API Management enables digital experiences, simplifies application integration, underpins new digital products, and makes data and services reusable and universally accessible.
How we found the SSRF Vulnerability
We started by creating a new API Management Service:
Once the service was created, we could go to the main service page and look at the various requests that were being sent –
We noticed that the POST request was being sent to the following endpoint –
We then sent a request to validate that it was actually the server that was sending the requests by looking up its IP address from https://www.ifconfig.me:
We were able to send a request to my Burp Collaborator – lower left side of the screenshot below – and receive the callback from the vulnerable server as can be seen on the right side of the screenshot.
The following headers, which were attributes of the newly created service were being sent as well –
Ocp-Apim-Service-Name: ssrfpoc (newly service name)
Ocp-Apim-Resource-Group: lidor-rg (resource group)
Ocp-Apim-Url: null/internal-status-0123456789abcdef (null=since the newly developer portal is not yet ready, the request is being sent to null, this is the Header that will be abused). Ocp-Apim-Method: GET (Request Method)
Ocp-Apim-Subscription: 5cd1****-****-****-****-********c611 (Subscription)
Side note: There are various undocumented headers that are being used and generated by Azure Services, especially by the API Management service. This was revealed in various JS files that were received by the server behind the scenes. For example, I could review the following JS file –
To provide a simple proof of concept of the SSRF, we could send a simple GET request to:
Since we were able to retrieve any endpoint we sent a request to, we tried to access the IMDS (Instance Metadata Service) and Azure Wire endpoints. The Azure Wire endpoint is an internal static IP address (22.214.171.124) that Azure Services use to communicate through the WAAgent. It is responsible for various networking rules, such as inbound and outbound rules for the service. If a remote attacker is able to query the Wire Server, they may be able to obtain information about installed extensions, certificates, and their corresponding private keys
The IMDS (Instance Metadata Service) endpoint – 169.254.169.254 – provides information about currently running virtual machine instances which can be very interesting information for an attacker. We wrote more about this in a blog post about the Oracle SSRF vulnerability we found last year. However in this case we did not manage to access the IMDS, so instead we enumerated the internal ports (there were several more ports, but the screenshot below gives an indication of the enumeration process) –
Open ports found:
The above information could be validated based on the various responses from the different ports, and from one of the responses that was received by the server –
We were able to review each of the open internal ports, and enumerate and discover even more sensitive data, but for now we’ll focus on port 30005.
The 30005 port was found to be https://apimanagement-cors-proxy-prd.scm.azure-api.net/
This could be validated from both Internal and External Endpoints –
The difference was that by sending the request from within the server using the SSRF vulnerability, we managed to uncover internal endpoints and services – something that would not be possible if we were trying to reach the same endpoint externally.
For example, since this was a Kudu Git server, we could assume that it was using the Git client to upload and save various deployments from the portal.
Hence, we knew for a fact that we could try the git-upload-pack command and send it directly to the server since we authenticated –
Moreover, we could review the git-scm documentation –
By understanding the various git-scm requests we could send to the server, we then tried to send a request to the remote repository to list the refs.
In summary, we were able to retrieve the Git client version, the empty refs list and the different git-scm capabilities. From here, there would be several possibilities for further exploitation:
- Try to upload a remote repo. (something similar to this – https://infosecwriteups.com/git-lfs-exploit-for-remote-code-execution-cve-2020-27955-e8f4786163c3)
- Enumerate various sensitive files within the Kudu SCM server.
- More documentation abusing the SCM services and endpoints can be found here: –https://github1s.com/projectkudu/kudu/blob/98ad238b860f81a4cb4e3419c8785a58ba68e661/Kudu.Services.Web/App_Start/NinjectServices.cs
- The above example only focused on port 30005 and the Kudu Git SCM Server, which was only one of the many internal ports that were found open (such as 5985 etc.)
About Orca Security
The Orca Cloud Security Platform identifies, prioritizes, and remediates risks and compliance issues across your cloud estate spanning AWS, Azure, Google Cloud, Alibaba Cloud, and Kubernetes. Instead of layering multiple siloed tools together or deploying cumbersome agents, Orca delivers complete cloud security in a single platform. Sign up for a complimentary cloud risk assessment or request a demo to get started today.