Azure customers whose firewall rules rely on Azure Service Tags, pay attention: You could be at risk due to a vulnerability discovered by Tenable Research. Here’s what you need to know to determine if you’re affected, and if so, what you should do right away to protect your Azure environment from attackers.
Tenable Research has discovered a vulnerability in Azure that allows an attacker to bypass firewall rules based on Azure Service Tags by forging requests from trusted services. Customers who rely on these firewall rules for security are at risk from this vulnerability. They should take immediate action to mitigate the issue and ensure they are protected by robust layers of authentication and authorization.
The vulnerability was discovered initially in the Azure Application Insights service, but we and the Microsoft Security Response Center (MSRC) eventually found that it affects more than 10 other Azure services. In each case, attackers would be able to access other internal and private Azure services.
In Tenable Research’s communication with MSRC about this vulnerability, MSRC explained that Azure Service Tags have security limitations and also updated their documentation to reflect those.
“Service Tags are not sufficient to secure traffic to a customer's origin without considering the nature of the service and the traffic it may send. It is always the best practice to implement authentication/authorization for traffic rather than relying on firewall rules alone,” reads one of the messages MSRC sent to Tenable Research.
The vulnerability
Multiple services in Azure allow the customer to craft web requests. Some even allow users to add headers to the request and to change HTTP methods. This is part of the intended functionality of these services. For example, since the Azure Application Insight Availability Tests Feature tests the availability of applications deployed by clients, clients require full control of the request to create a functional test.
However, this functionality may open the door for a malicious actor to achieve an impact similar to that of a server-side request forgery (SSRF) vulnerability. SSRF allows an attacker to cause a server-side application to make requests to an unintended location, whether internal or external, allowing the attacker, among other options, to reach/expose resources that were previously unreachable.
When a service grants users the option to control server-side requests, and the service is associated with Azure Service Tags, things can get risky if the customer does not have additional layers of protection.
Impact
This vulnerability enables an attacker to control server-side requests, thus impersonating trusted Azure services. This enables the attacker to bypass network controls based on Service Tags, which are often used to prevent public access to Azure customers’ internal assets, data, and services.
Coordinated Disclosure
January 24, 2024 - Tenable discloses to vendor. Automated acknowledgment.
January 31, 2024 - MSRC confirms the behavior as an “Elevation of Privilege” with severity “Important” and awarded a bounty.
February 2, 2024 - MSRC devises a comprehensive fix plan along with a timeline for implementation.
February 26, 2024 - MSRC decides to address the issue via a comprehensive documentation update and addresses more variants of the vulnerability.
March 6, 2024 - Coordinated disclosure in May is agreed upon.
April 30, 2024 - Tenable provides a blog draft to MSRC.
April 30 - May 10, 2024 - Tenable coordinates with MSRC to incorporate technical comments.
June 3, 2024 - Coordinated disclosure.
What are Azure Service Tags?
Per the documentation, which has since been updated by Microsoft, Azure Service Tags simplify network isolation within Azure by grouping specific Azure services IP ranges. These tags can be used to define network security rules and apply these rules consistently across multiple Azure resources. Essentially, Azure Service Tags provide a convenient way to manage access controls, such as firewall rules or network security group (NSG) configurations.
For example, if I as a customer want to allow network access to my private Azure API Management Service, and only from the service itself, or another service I use in Azure, I can do it in two ways as long as these services have associated Service Tags:
- I can specify the IP ranges of the services I want to allow.
- I can use a service tag of the associated service, the “ApiManagement” service tag, to only allow my API Management services to access my API Management.
The second option is more convenient, so it’s safe to assume many – maybe most – customers will choose it. Nonetheless, both options can put customers at risk from the vulnerability we’re describing.
Technical details - Azure Application Insights example
Azure Application Insights is a monitoring and analytics service that helps developers detect, diagnose, and understand issues affecting their web applications and services in real-time.
Azure Application Insights has a service tag associated with it named “ApplicationInsightsAvailability”.
The Application Insights Availability feature allows you to create availability tests for your application or machine.
When creating a new test using Azure Application Insights with the intention of using it for an internal network application or machine, Azure advises customers to use a Service Tag to only allow the Application Insights Availability service to monitor and access your internal application or machine through port 80 or 443:
A naive user will follow the advice, and apply the “ApplicationInsightsAvailability” Service Tag to his private asset in the asset’s Azure network configuration while aiming to achieve network isolation. Behind the scenes, a set of IPs associated with the Application Insights Availability agent are allowed.
The interesting part is the combination of the Service Tag usage and the service’s feature that allows users to control server-side requests:
Attackers can abuse the "availability test" of the "classic test" or a "standard test" functionality. Both functionalities support custom headers and HTTP method change. Attackers can send requests using the availability tests feature of the Application Insights Availability service. Through this, they can access the internal services of cross-tenant victims who blindly trust the Application Insights Availability Service Tag in their firewall rule. Attackers can leverage this to access internal APIs that are now exposed in the victim's service, since the exposed ports are 80/443, which usually host web assets.
Attackers can add custom headers, change methods and customize their HTTP requests however they want.
Proof of concept
Below we outline the steps an attacker would take to exploit this vulnerability on Azure App Services.
Let us say that a user is deploying an internal Azure App Service, that user wants their App Service to utilize the capabilities of Azure Application Insights, but still remain isolated. The user attempts to accomplish this by applying access restrictions to only allow the ApplicationInsightsAvailability Service tag:
An attacker tries to access the internal App Service and gets a forbidden response:
An attacker abuses the described vulnerability in the Application Insights availability tests feature to impersonate the Application Insights service and successfully accesses the victim's internal App service. The attacker can also view the response and add custom headers, which are available through the "standard test" feature:
Affected services - Variants of the vulnerability
After analyzing the security and the trustworthiness of Azure Service Tags through the Application Insights service, and reporting our findings to MSRC, we and MSRC found more variants of the issue in more than 10 Azure services.
We appreciate MSRC’s commitment and work on this matter. Capabilities and risks vary for each service. Those include:
- Azure Application Insights
- Azure DevOps
- Azure Machine Learning
- Azure Logic Apps
- Azure Container Registry
- Azure Load Testing
- Azure API Management
- Azure Data Factory
- Azure Action Group
- Azure AI Video Indexer
- Azure Chaos Studio
The common denominator in these various scenarios is this dangerous combination: a service that has an associated Service Tag and also allows users to control server-side requests.
How to defend against these attacks
First, analyze the network rules in your Azure environment on each associated service, search for the use of Service Tags, and filter the affected services. For the affected services, assume these assets are public.
To defend these assets, add authentication and authorization layers to these. Just as MSRC advised:
“Service Tags are not sufficient to secure traffic to a customer's origin without considering the nature of the service and the traffic it may send. It is always the best practice to implement authentication/authorization for traffic rather than relying on firewall rules alone.”
Second, when configuring Azure services’ network rules, bear in mind that Service Tags are not a watertight way to secure traffic to your private service. By ensuring that strong network authentication is maintained, users can defend themselves with an additional and crucial layer of security. In that case, even an attacker leveraging the vulnerability to reach the target endpoint would have great trouble exploiting that access.
The Azure services we listed in this blog are vulnerable. We advise approaching even other services not listed on this blog with a healthy dose of skepticism as well and check whether a service has the dangerous combination described in this blog.
To read more vulnerability discovery posts like this from the Tenable Cloud Security Research team, please visit here.
Liv Matan
Liv Matan is a Senior Security Researcher at Tenable, where he specializes in application and web security. As a bug bounty hunter, Liv has found several vulnerabilities in popular software platforms, such as Azure, Google Cloud, AWS, Facebook, and Gitlab. He was recognized as Microsoft's "Most Valuable Researcher" and has presented at conferences such as DEF CON Cloud Village and fwd:cloudsec.
