In this blog we describe how we uncovered an SSRF Vulnerability in Azure Functions allowing any unauthenticated user to request any URL abusing the server. We reported the vulnerability to Microsoft on November 12th, and it was fixed on December 9th, 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 Azure Functions
Azure Functions is a cloud service available on-demand that provides all the continually updated infrastructure and resources needed to run your applications (serverless compute). You can use Functions to build web APIs, respond to database changes, process IoT streams, manage message queues, and more.
How we found the SSRF Vulnerability
We started by creating a new Function App –
Once the App Service was ready, we created the Function Code –
After clicking on Functions, we reached the following page –
First, we created the Functions code by providing a sample name and template –
Once the Function App was ready, we selected Code + Test. We could now review the various requests that were being sent, including the two main requests that caught our eye:
https://functions.azure.com/api/passthrough and https://functions.azure.com/api/debug.
By reviewing the code itself, it is mentioned here –
When reviewing the /api/passthrough request we noticed that it was actually sending a GET request to our unique Function (BlobTrigger1.dat) –
Before we were able to exploit this functionality, we noticed that in order to execute the request, there were two parameters that needed to be sent –
By reading the documentation we concluded that the function needed one of the parameters in order to be authenticated to the functions.azure.com host.
To uncover the vulnerability, we decided to remove these two headers from the request so we could send any request we wanted. But before we did, we first needed to check which actual server was being asked to execute our requests –
And to our Burp Collaborator –
We determined that the actual function that was being abused by the SSRF request was –
We could validate this by sending a request to https://www.nba.com. I got the following
response –
In the above screenshot we can see that we received the output of the main NBA website but in France – since our function endpoint is located in france. Meaning that the function itself was the one that executed our requests.
In addition, I concluded that the function was a NodeJS based function. We managed to discover it by sending the request to the following address – https://www.infobyip.com/ to obtain more information on the IP address.
We could see that the User-Agent was axios/0.21.4 which is a Node JS module.
We tried to reach the IMDS service, but were not able to access it. However we were able to successfully enumerate the local ports –
As seen from the above screenshot we were able to find a potential open internal port – 41692.
By enumerating even further we could see that it was possible to reach internal endpoints as shown below –
The Azure Functions SSRF use case taught us to trust our instincts when encountering an interesting endpoint request that is being sent behind the scenes. Once we decided to examine it further by searching for its open source code, we were able to learn and understand the logic behind it and uncover an important 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.
