Jan 17, 2023
As part of the Orca Research Pod efforts, we regularly research various cloud provider services and capabilities to help our customers keep their assets safe and secure in the cloud. During our research into several Azure services, we found four instances where different services were vulnerable to a Server Side Request Forgery (SSRF) attack. Alarmingly, two of the vulnerabilities did not require authentication, meaning that they could be exploited without even having an Azure account.
SSRF attacks can be particularly dangerous since a successful execution can result in an attacker accessing or modifying internal resources as well as submitting data to external sources.
As soon as we discovered the vulnerabilities, we reached out to the Microsoft Security Response Center (MSRC), who promptly fixed the reported issues. Microsoft has confirmed that the vulnerabilities have been remediated, which is why we are now disclosing the details of the vulnerabilities we found.
In this blog, we will describe how we found each of these SSRF vulnerabilities and were able to take advantage of these flaws to access various internal endpoints in some of the Azure Services.
Below we have provided an overview and timeline of the vulnerabilities we found in the four different Azure services.
|Affected Service||Severity||Unauthenticated||Date reported||Status|
|SSRF #1||Azure Digital Twins||Important||Yes||October 8, 2022||Fixed (October 17, 2022)|
|SSRF #2||Azure Functions App||Important||Yes||November 12, 2022||Fixed (December 9, 2022)|
|SSRF #3||Azure API Management||Important||No||November 12, 2022||Fixed (November 16, 2022)|
|SSRF #4||Azure Machine Learning||Low||No||December 2, 2022||Fixed(December 20, 2022)|
A Server-Side Request Forgery (SSRF) is a web security vulnerability that allows an attacker to abuse a server-side application and make requests to read or update internal resources as well as submit data to external sources.
There are three main types of Server-Side Request Forgery (SSRF) attacks:
All four SSRF vulnerabilities we discovered belong to the third category which is Full SSRF (aka Non-blind SSRF. To give you an idea of how exploitable these vulnerabilities are, Non-blind SSRF flaws can be leveraged in many different ways, including SSRF via XXE, SSRF via SVG file, SSRF via Proxy, SSRF via PDF Rendering, SSRF via vulnerable query string in the URL and many more.
It is important to note that no matter the type of SSRF attack, each SSRF vulnerability can be used to gain unauthorized access to sensitive information or launch further attacks against a target. Therefore, it is important for organizations to properly secure their servers and networks to prevent these types of attacks.
In the diagram below, we show the different communication flows between the attacker, the vulnerable server and a web server in an SSRF attack.
For each of the vulnerabilities, I describe how we discovered it and the potential damage it would have allowed an attacker to cause.
1. Unauthenticated SSRF on Azure Digital Twins Explorer
2. Unauthenticated SSRF on Azure Functions
3. Authenticated SSRF on Azure API Management Service
4. Authenticated SSRF on Azure Machine Learning Service
In 2020, Microsoft implemented several measures to mitigate the impact of SSRF attacks on its Azure platform.
One such measure was the introduction of requirements for accessing the instance metadata service (IMDS) endpoint. To prevent unintended or unwanted redirection of IMDS requests, Microsoft now requires that such requests:
In addition, Microsoft has implemented an “Identity Header” for the App Service and Azure Functions. These services provide an internally accessible REST endpoint for token retrieval that can be accessed by apps with a managed identity using a standard HTTP GET request. To make this endpoint available, apps must define two environment variables:
By implementing these measures, Microsoft has significantly reduced the potential damage of SSRF attacks on its Azure platform.
Generally speaking, finding an SSRF vulnerability can be very rewarding for a remote attacker. The simple fact that by abusing such a vulnerability, attackers can reach internal endpoints and services, and even potentially reach a sensitive endpoint such as the IMDS of the server – could be devastating for the organization (see the infamous 2019 Capital One attack).
But it’s not just limited to the IMDS – SSRF can also allow an attacker to access local ports on the vulnerable server, potentially leading to further compromise of the system. For example, we were able to access local endpoints in various services.
So how can organizations protect themselves against this type of attack? The key is to ensure that all input is properly validated, and that servers are configured to only allow necessary inbound and outbound traffic. In addition, by keeping your cloud environment secure – for instance by enforcing proper cloud security hygiene, adhering to the principle of least privilege, patching vulnerabilities and avoiding misconfigurations – you can further limit the damage an attacker can achieve.
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.