Microsoft Security Response Center (MSRC) was notified in January 2024 by our industry partner, Tenable Inc., about the potential for cross-tenant access to web resources using the service tags feature. Microsoft acknowledged that Tenable provided a valuable contribution to the Azure community by highlighting that it can be easily misunderstood how to use service tags and their intended purpose. Although Microsoft initially confirmed the vulnerability and paid Tenable a bounty for their contributions, further investigation into Tenable’s report determined that service tags work as designed and best practices needed to be clearly communicated through service documentation as we had communicated in our follow-up correspondence with Tenable.
Cross-tenant access is prevented by authentication and only represents an issue where authentication is not used. However, this case does highlight an inherent risk in using service tags as a single mechanism for vetting incoming network traffic. Service tags are not to be treated as a security boundary and should only be used as a routing mechanism in conjunction with validation controls. No exploitation or abuse of service tags has been reported by a third-party or seen in the wild per our own investigation.
As always, we strongly encourage customers to use multiple layers of security for their resources, such as monitoring network traffic and authentication. As a result of Tenable’s report, we’ve updated our documentation to remind customers of the function of service tags.
The goal of this update to service tags documentation is to improve our customers’ understanding of service tags and how they function. As such, there is no mandatory action required by customers and no additional messaging provided in the Azure Portal. However, Microsoft strongly recommends that customers proactively review their use of service tags and validate their security measures to authenticate only trusted network traffic for service tags.
Service tags are a convenient way to represent a block of IP space for many Azure services. Resources can use service tags to reference Azure services in their firewall rules, for example to allow traffic from a given service to access the resource.
Some of these services allow inbound traffic via a service tag and contain features that give users control over parts of a web request (i.e., URL path, destination host, etc.). Potentially, an attacker in Tenant A can use these web requests to access web resources in Tenant B if it has been configured to allow traffic from the service tag and does not otherwise provide any form of authentication.
In these cases, impact is determined in part by the following factors:
For example, Azure Monitor Availability Tests service has an ApplicationInsightsAvailability service tag that enables users to configure webtests through a firewall to access their service endpoint(s) and perform synthetics monitoring. Because these webtests use the same public IP addresses in a shared infrastructure to call a user’s service endpoint(s), a user could configure a web request to access a service endpoint from another Azure Monitor Availability Tests subscription. This behavior could enable a malicious actor to send web requests to another user’s service endpoint(s) and the application may process the unintended web request, if:
Service tags represent a range of IP addresses for a given Azure service and are used for network configuration such as firewall filtering, network security groups (NSGs), and user-defined routes (UDRs). This functionality of the service tags is crucial to allow network traffic between the Azure service and a user’s service endpoint(s). Given the flexible use cases for service tags, customers must consider their network traffic between tenants and their specific scenarios for a service.
Service tags are not a comprehensive way to secure traffic to a customer’s origin and do not replace input validation to prevent vulnerabilities that may be associated with web requests. Input validation is used to assure where the traffic originates and who is sending the traffic. Additional authentication and authorization checks must be implemented for a layered network security approach.
Azure customers are highly encouraged to review their use of Microsoft virtual network service tags and evaluate if additional measures must be put in place to secure network traffic between Azure tenants. After a customer has reviewed service tag(s) usage, they can:
Azure Monitor Availability Tests provide a customer with an opportunity to monitor the uptime of their resources. Customers must consider this in their resource monitoring strategy. Using Azure Monitor Availability Tests along with the associated service tag ensures adherence to a standard monitoring strategy.
To prevent the ApplicationInsightsAvailability service tag from passing unwanted network traffic to your service endpoint(s), create a token and add it as a HTTP header in your availability test. Your service can then validate the HTTP header in incoming requests to authenticate that the origin of traffic is from your availability tests. Thus, all other requests without the custom HTTP header would be rejected and dropped. Learn more about this application layer security control for Azure Monitor Availability Tests here.
In addition to the above, some customers may have the following scenario. Company A may provide an API to several industry partners so they can use it in their services or applications. Each of these partners may want to monitor the uptime of Company A’s APIs through Azure Monitor Availability Tests. Thus, Company A will have to decide on their resource monitoring strategy for their APIs and how to communicate that strategy to their industry partners.
In the pursuit of secure-by-design principles, Company A could implement a validation check for their HTTP headers. Company A’s resource monitoring strategy would only be accessible to industry partners with a custom header, ensuring secure collaboration. Alternately, Company A could decide not to require a custom header and instead use their own method of authentication, enabling anyone to monitor their APIs through Azure Monitor Availability Tests.
Microsoft took the following actions after this activity was brought to its attention:
We have provided the timeline of key events associated with this issue as well as highlight our approach to increase available service documentation to customers to prevent this issue:
We appreciate the opportunity to investigate the findings reported by Tenable and thank them for practicing safe security research under the terms of the Microsoft Bug Bounty Program. We encourage all researchers to work with vendors under Coordinated Vulnerability Disclosure (CVD) and abide by the rules of engagement for penetration testing to avoid impacting customer data while conducting security research.
Microsoft has a long history of working with third-party researchers and others across the security community. This is reflected in our Secure Future Initiative (SFI), further promoting transparency in how we work with security researchers and respond to claims of risk associated with our products and platforms services. Microsoft is committed to sharing our analysis of researchers’ claims and providing recommendations to customers and the community.