A vulnerability — or just Azure working as intended, depending on who you ask — in Microsoft’s cloud potentially allows miscreants to wave away firewall rules and access other people’s private web resources.
The issue, discovered by the research team at vulnerability assessment outfit Tenable, stems from Service Tags, which are an Azure construct.
These tags can be used to group together IP addresses used by Azure services so that in theory it’s easier to control network access to and from those resources. For instance, if you want a specific Azure service to interact with your private web application, you can use a Service Tag to only allow in that specific service’s connections through a firewall to the app.
Microsoft suggests that when Azure users create these kinds of security policies, they apply them to Service Tags instead of to individual Azure IP addresses.
Tenable thinks these tags can be abused by a rogue Azure customer to access other customers’ stuff – a cross-tenant attack – if those victims rely on Service Tags in their firewall rules. Microsoft, however, isn’t going to fix the issue because Redmond does not rate the issue as a vulnerability. Instead, Microsoft believes the matter is a misunderstanding regarding how one decides to “use Service Tags and their intended purpose.”
Yet after Tenable disclosed the issue in January, Microsoft confirmed it was an “elevation of privilege flaw,” with an “important” severity level, and paid Tenable a bug bounty.
A month later, according to Tenable, Microsoft developed a “comprehensive fix” and a timeline for implementation, but then later decided to address it with only “a comprehensive documentation update.” The Windows giant, it seems, thinks the security weakness with Service Tags can best be solved with combined layers of security controls.
“We appreciate the collaboration with Tenable to responsibly disclose the inherent risk in using Service Tags as a single mechanism for vetting secure network traffic,” a Microsoft spokesperson told The Register.
“We encourage customers to take a multi-layered security approach when it comes to validating their security measures to authenticate only trusted network traffic for Service Tags,” the spokesperson added.
“We strongly recommend customers proactively review their use of Service Tags as outlined within our blog.”
So instead of a patch, Microsoft has published “improved guidance” for Azure Service Tags in its documentation.
From a security standpoint, addressing gaps — whether it be a communication gap or a technology gap — is crucial in ensuring users’ security
“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,” the Windows maker argued.
In that blog post, Microsoft notes that “no exploitation or abuse of Service Tags has been reported by a third-party or seen in the wild per our own investigation.”
Tenable, meanwhile, published its own technical description of the issue, along with a proof-of-concept scenario that could be used to exploit this issue using Azure App Services.
In addition to that Microsoft cloud service, the vulnerability affects at least 10 other Azure services, we’re told. These include the platform’s Application Insights, DevOps, Machine Learning, Logic Apps, Container Registry, Load Testing, API Management, Data Factory, Action Group, AI Video Indexer, and its Chaos Studio.
This isn’t the first — or even the second time — the two security shops have squabbled over Redmond’s bug disclosure habits or larger infosec practices.
Tenable senior research engineer Liv Matan declined to comment specifically on Microsoft’s decision not to issue a patch, or call it a vulnerability, in this case. No matter how you describe it, he said, it needs to be addressed to ensure users’ security.
“Many customers are using Azure Service Tags to achieve network isolation,” Matan told The Register. “Our novel discovery exposed how attackers can breach that isolation and reach internal customer assets. From a security standpoint, addressing gaps — whether it be a communication gap or a technology gap — is crucial in ensuring users’ security.”
For the nitty-gritty details of the security weakness, see the Tenable advisory. In summary, it boils down to the fact that users are allowed to send customizable HTTP requests to web applications via various Azure services, and those applications trust the requests because they come from a service that’s covered by a Service Tag.
Thus, we’re led to believe, it’s possible for one Azure user to control the HTTP requests sent by an Azure service to another customer, and if that other customer blindly trusts the request – because it’s coming from a service covered by a Service Tag – it reaches the victim’s app, allowing the rogue user to (say) potentially remotely control or monitor that app.
“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,” Tenable warned.
To prevent this type of abuse, Microsoft recommends adding authentication and authorization checks and not only relying on firewall rules.
So, for example, customers using Azure Monitor Availability Tests, which allow them to monitor uptime of their resources, would do the following:
The bottom line, according to both vendors, is to implement multiple layers of security to protect valuable resources and data. ®