Warning over Azure Service Tags vulnerability backed by infosec pros

Security researchers from Tenable have reported what they described as a “high-severity” vulnerability affecting multiple Azure services and warned that Microsoft has “no plans to patch it” despite having issued a bounty.

Attack surface management specialist Tenable said the bug lets attackers "bypass firewall rules based on Azure Service Tags by forging requests from trusted services", but Microsoft said this is a customer configuration issue.

"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" Redmond said, whilst also urging customers to check their security measures.

[Attackers 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 – Tenable.

Microsoft said "we strongly recommend customers proactively review their use of service tags and validate their security measures to authenticate only trusted network traffic for service tags" but after further investigation it found that the tags worked as intended; it has, however, updated its documentation.

Infosecurity professionals have told The Stack that Tenable was absolutely correct to warn that hackers could "abuse" service tags - predefined groups of IP addresses for vetting incoming network traffic - to bypass Azure firewall rules.

The vulnerability affects more than 10 Azure services including its API management plaform. Tenable said attackers can exploit the vulnerability to impersonate trusted Azure services to evade network controls. All Azure customers whose firewall rules rely on Azure service tags are at risk and have been urged to take steps to address the vulnerability immediately.

Liv Matan, senior research engineer at Tenable, told The Stack: “The vulnerability is not complicated to exploit. An attacker would need to send a request from a service to a service that is using a service tag. However, they would need to know if the targeted service is using a service tag in its network configuration, otherwise they have to guess. 

“Currently, there are more than 10 services known to be vulnerable if there are no additional validation controls added by Azure customers.”

Matan said it was “difficult to predict” how many attacks exploiting the vulnerability were likely to occur. (Microsoft said none have been seen in the wild.)

“This level of exposure opens customers up to unnecessary risk,” Matan added. "Given this, we highly recommend that customers act immediately to mitigate the issue. In the worst case scenario, attackers could access internal assets and data.”

Jorge Lamarca, Senior Manager, Threat Detection at WithSecure told The Stack: "Service tags are an alias for Microsoft IP ranges. This concept of an alias is not unique to cloud. Aliases to refer to groups or ranges of IP addresses are a commonplace tool to simplify the definition and maintenance of network ACLs in all kinds of network devices, and virtual cloud features.

"If used in combination with a traditional IP-based network security group, this setup is not concerned with the type of traffic coming in, but only its origin and destination. While very useful, this alone is not enough to vet net the nature of incoming traffic, and the burden of understanding what origins exactly are allowed and ensuring complementary controls are in place is still with the organisation.

“Azure tags are very common, and they allow administrators to trust Microsoft services without having to continuously update the IP ranges that carry their traffic.

"What makes this report particularly interesting is that it not only allowed any person utilising certain Azure services to be able to reach any resource that had a security group rule trusting the IPs for the service, but the case-study presented by the researcher was employing an Azure service that provides the ability to craft HTTP requests in detail, against a web application. The combination of these conditions made what was supposed to be a fully internal-facing application, effectively external-facing.

"Tenable revealed an attack surface most users of Azure service were probably not accounting for, and as such, each organisation must include this fact into the threat model for their Azure assets and decide whether their control posture is sufficient on an asset-by-asset basis."

When asked when Microsoft was correct to avoid issuing a patch, Lamarca replied: "Allowing a group of IP addresses (represented in this case by a service tag), and then seeing traffic coming from the allowed is expected behaviour. This is not a bypass of the normal workings of a control. That said, I don't think that cross-tenant network reachability of assets was an intended consequence of the overall design, but as platforms become more complex, features compound to make for gaps like this.

"This disclosure was related to a heavily utilised feature, and therefore a quick fix is not possible. In our experience, whenever a situation like this is uncovered, the need to add features and configuration defaults to prevent it becomes apparent, and a gradual improvement in default posture is then introduced.”

Sylvain Cortes, VP Strategy, Hackuity, also supported the warning.

"Tenable researchers are correct in identifying the inherent risk of relying on service tags," he told The Stack. "Any vetting method for incoming network traffic that dismisses the reality of user behaviour is insufficient and - in this case - an active vulnerability.

"Service tags are widespread among Azure customers, so take note and take remediation actions now. If history's taught us anything, don't wait for a patch.

"Start with the low-hanging fruit and stick with MSRC's advice: implement authentication/authorisation for traffic and do not rely on firewall rules alone."

Anatomy of a vulnerability

Researchers submitted details of the vuln to the Microsoft Security Response Center (MSRC) in January, earning a bug bounty. 

In February, Microsoft launched a “comprehensive variant hunt, telemetry investigation, and engineering review” to determine a mitigation strategy.

It then told Tenable that the issue was not a server-side request forgery (SSRF) vulnerability or a firewall bypass vulnerability, before uploading service tags documentation changes to Microsoft Learn, its online training and education service  

In a statement, Microsoft played down the severity of the vulnerability and wrote: “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.”

It said that cross-tenant access is prevented by authentication and only represents an issue when authentication is not used. 

“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," Microsoft continued. "No exploitation or abuse of service tags has been reported by a third party or seen in the wild."

How to address the Azure vulnerability

Tenable offered its own advice, urging users to “act immediately”. 

Each service requires different actions to mitigate the issue, so Tenable recommended that users analyse the network rules in Azure environments on each associated service to find Service Tags, before filtering the affected services. 

“Users should assume assets in affected services are publicly facing,” it advised.

Authentication and authorisation layers should then be placed on top of the network controls using service tags to protect assets from exploitation. 

“By ensuring that strong network authentication is maintained, users can defend themselves with an additional and crucial layer of security,” Tenable continued.

Ben Thomas, senior security consult at Insight, shared four recommended actions for readers of The Stack who wish to address the service tags vulnerability. He wrote:

"1) Review network rules: Evaluate current network rules using both Service Tags and IPs, ensuring scope is correct.

"2) Implement authentication/authorization: Ensure robust authentication and authorization for traffic to and from Azure services.

"3) Monitor network traffic: Ensure you are monitoring network traffic for indicators of compromise and anomalies.

"4) Consult updated Documentation: Refer to Microsoft’s updated guidance for detailed steps on securing network configurations effectively."