Improved Guidance for Azure Network Service Tags

Summary

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.

Technical Details

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:

• Whether the victim service performs an auth check of its own
• How much of the request body can be controlled by the attacker
• Whether the response content can be viewed by the attacker

Example: Azure Monitor Availability Tests

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:

1. the malicious actor had access to a tenant that enabled the ApplicationInsightsAvailability service tag and
2. the target service endpoint does not perform any of its own authentication checks.

Customer Guidance  

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:

• Review the new best practices article for Microsoft service tags and follow specific guidance if provided by a service.
• Review Azure security fundamentals documentation to ensure that their Azure platform and infrastructure are set up with general and security best practices in mind.
• Review Azure Monitor documentation to ensure that their Azure platform and infrastructure has appropriate monitoring controls enabled to collect, analyze, and respond to system events.

Example: Azure Monitor Availability Tests with Authentication Check  

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’s Response and Timeline of Events

Microsoft took the following actions after this activity was brought to its attention:

• Microsoft performed a comprehensive variant hunt, telemetry investigation, and engineering review of this issue which influenced the mitigation strategy
• Azure services with inbound service tags updated documentation to include information about their service tag(s) use cases and/or guidance to confirm network traffic
• Azure documented best practices for service tags in a general article

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:

• 24 January 2024: Tenable submits a potential security vulnerability though the MSRC researcher portal.
• 31 January 2024: MSRC confirms the observed vulnerability and awards a bounty to Tenable.
• 2 February 2024: Microsoft reviews the issue and started to perform a comprehensive variant hunt, telemetry investigation, and engineering review of this behavior to determine a mitigation strategy.
• 26 February 2024: Microsoft communicates our customer disclosure strategy and commitment to enhancing Azure services’ service tag documentation to address the issue.
• 6 March 2024: Microsoft and Tenable agree to a coordinated disclosure for this issue.
• 31 March 2024: Microsoft concludes our comprehensive variant hunt, telemetry investigation, and engineering review for this issue.
• 3 April 2024: Microsoft expresses in written feedback to Tenable that this issue is not a SSRF vulnerability.
• 3 May 2024: Microsoft expresses in written feedback to Tenable that this issue is not a firewall bypass vulnerability.
• 10 May 2024: Microsoft made the service tags documentation changes publicly available on Microsoft Learn.
• 3 June 2024: Microsoft and Tenable disclose this issue to the public.

Acknowledgement

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.

References

• Questions? Open a support case through the Azure Portal at aka.ms/azsupt
• Learn more about Azure Virtual Network Service Tags at Azure service tags overview | Microsoft Learn
• Learn more about Azure security fundamentals at Azure security fundamentals documentation | Microsoft Learn
• Learn more about Azure Monitor at Azure Monitor documentation - Azure Monitor | Microsoft Learn