In this blog we describe how we uncovered an SSRF Vulnerability in the Azure DigitalTwins Explorer service, allowing any unauthenticated user to request any URL by abusing the server. We reported this vulnerability to Microsoft on October 8th, and it was fixed on October 17th 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. The vulnerability on Azure Digital Twins existed due to a bug in the User Input Validation that followed one of the requests.
How we found the SSRF Vulnerability
First, we created a new Digital Twins service –
Next, we hit ‘Open Azure Digital Twins Explorer’:
Important Note: There was no need for a remote attacker to create a Digital Twins Resource in order to exploit this SSRF. I’m only creating one for the purpose of this blog. A remote user could access the endpoint without any authorization or authentication from any server (I will demonstrate this further on).
The following pop up alert indicates that our resource is not found within the Azure Portal. I’ll hit “Close” to ignore that for now. As will be explained shortly, even though the service alerted us that we didn’t create a valid service via the Azure Portal, we were still able to abuse the SSRF vulnerability.
Next, we click on the 3D Scenes button:
We noticed the following request was sent behind the scenes:
The response was as follows:
As highlighted in the screenshot above, we noticed the following interesting points:
• This is an Express Based App.
• /proxy/blob endpoint with various query parameters.
• New Header called X-Blob-Host which is set to undefined.
• Internal Server Error 500 revealing the app’s various dependencies and files.
In order to prove the concept of abusing the SSRF functionality, we can remove all headers except for the X-Blob-Host and X-ms-Version.
As mentioned in the beginning of this blog, since the validation was vulnerable, we could tinker with the Header to see what the next outputs would be.
We sent the following request:
And received this response:
We could see that by providing an example blob, a request was being made (getaddrinfo) to the endpoint, meaning that it was indeed checking for:
Knowing this, we tried to send the following request to the server with a crafted payload:
Below is the request, along with the received response:
From the screenshot above you can see that we managed to get the request callback to our Collaborator with the main domain IP address (104.45.84.81).
As mentioned in the Important Note above, although the workflow was started after the Digital Twins service was created via the UI, the same workflow can be even shorter by entering the Digital Twins Explorer without going through the Azure Portal, meaning that the same payload could be also be sent via the Explorer UI without any need for any authentication.
We then entered the 3D Scene endpoint directly, and received the following:
Upon reviewing the various files related to the Digital Twins Service in Github, we found what appeared to be misconfigured settings in the file BlobAdapter.ts, which was located on the following endpoint –
Repository:
There were two main interesting points –
As we can see from the above screenshots:
1) The blobHostUrl Is set to whatever the user had set in the Request Header (req.headers[’x-blob-host’])
2) The service then verified whether the BlobHostUrlObject header ended with the suffix: blob.core.windows.net
Since the blobHostUrl could be manipulated, a remote attacker could then craft a request ending with an SSRF.
Note that there were a few limitations to this use case:
- The response from any desired remote host should be in a specific response Content Type, namely Json.
- The port used must be 443.
- The full endpoint has to be in the following format “https://[remote_host]/.blob.core.windows.net/”
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.
