In this blog we describe how we uncovered an SSRF Vulnerability in the Azure Machine Learning service, allowing any authenticated user to request any URL abusing the server. We reported this vulnerability to Microsoft on December 2nd, and it was fixed on December 20th, 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.

How we found the SSRF Vulnerability

First, we created a new workspace in the Azure Machine Learning service via the https://ml.azure.com endpoint –

Once created, we navigated to the ‘Data’ dashboard to upload various assets to my Workspace. We clicked on the Data dashboard in the left pane menu, and selected ‘Create’

In the Create Data asset Wizard, we named the new asset and selected File(uri_file) and hit Next.

We continued by selecting ‘From a URI’ in order to upload my newly designated file –

Then, we specified a sample HTTPS endpoint (could also have been an HTTP) and hit Next (before doing so we toggled ‘Skip Data Validation’ –

Finally we hit ‘Create’ –

Before hitting Create, we made sure that my Intercept was set to ON –

We saw that the first request was the /saveddatasets/tieredpreview. We looked for further requests.

The second request was – https://ml.azure.com/api/eastus2/data/v2.0/subscriptions/5cd1****-****-****-****-********c611/resourceGroups/lidor-rg/providers/Microsoft.MachineLearningServices/workspaces/ssrf/datacall/preview

This request was being passed through the /datacall/preview. Similarly to the the streamcontent endpoint that I will focus on next, the preview endpoint used the “Path” + “File Name” scheme in its response –

While the streamcontent used the “Path + Contents” schema –

The final endpoint that was being passed through was the /datacall/streamcontent?streamInfoColumnName=Path&maxBytes=5000000

We could see that the POST request that was being sent contained the following body –

We could then remove all the non-relevant parameters, except the “dataUri” –

I sent the above request to the server, and received the response below –

The response content was in Base64 format, so we decoded it –

We sent a new request, this time to the https://orca.security endpoint –

And again, decoding the response provided us with the content of the website –

As we can see from the above base64 decode, we were able to retrieve any endpoint via the SSRF vulnerability.

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.