A vulnerability (or just Azure working as intended, depending on who you ask) in Microsoft’s cloud may allow miscreants to bypass firewall rules and gain access to other people’s private web resources.
The problem, discovered by Tenable’s research team, stems from Service Tags, an Azure construct.
These tags can be used to group IP addresses used by Azure services, making it theoretically easier to control network access to and from those resources. For example, if you want a specific Azure service to communicate with your private web application, you can use a service tag to allow only that specific service’s connections to the app through a firewall.
Microsoft suggests that when Azure users create these types of security policies, they apply them to service tags rather than to individual Azure IP addresses.
Tenable believes these tags could be abused by a rogue Azure customer to gain access to other customers’ stuff – a cross-tenant attack – if those victims rely on Service Tags in their firewall rules. However, Microsoft will not solve the problem because Redmond does not consider the problem to be a vulnerability. Instead, Microsoft believes the case is a misunderstanding of how it decides to use “service tags and their intended purpose.”
But after Tenable disclosed the issue in January, Microsoft confirmed it was an “elevation of privilege bug,” with a “major” severity level, and paid Tenable a bug bounty.
A month later, Microsoft developed a “comprehensive solution” and a timeline for implementation, according to Tenable, but later decided to tackle it alone with “a comprehensive documentation update.” It seems the Windows giant thinks the security weakness with service tags is best addressed with combined layers of security controls.
“We appreciate working with Tenable to responsibly disclose the inherent risk associated with using service tags as a single mechanism for vetting secure network traffic,” a Microsoft spokesperson said. 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 encourage customers to proactively review their use of service tags as described in our blog.”
So instead of a patch, Microsoft has published “enhanced guidance” for Azure Service Tags in the documentation.
From a security perspective, addressing gaps – whether a communication gap or a technology gap – is critical to ensuring user safety
“Further investigation into Tenable’s report revealed that service tags are working as designed and that best practices should 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 “according to our own research, no exploitation or misuse of service tags has been reported by a third party or seen in the wild.”
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 ten other Azure services, we are told. These include Application Insights, DevOps, Machine Learning, Logic Apps, Container Registry, Load Testing, API Management, Data Factory, Action Group, AI Video Indexer and the platform’s Chaos Studio.
This isn’t the first (or even second time) the two security shops have feuded 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 release a patch in this case, or to call it a vulnerability. However you describe it, he said, it must be addressed to ensure user safety.
“Many customers use Azure Service Tags to achieve network isolation,” says Matan The register. “Our new discovery has shown how attackers can break that isolation and reach internal customer assets. From a security perspective, addressing gaps – whether a communication gap or a technology gap – is crucial to ensuring user safety.”
For the nitty-gritty details of the security weakness, see the Tenable advisory. In summary, users may send customizable HTTP requests to web applications through various Azure services, and those applications trust the requests because they come from a service covered by a service tag.
So we’ve come to believe that it’s possible for an Azure user to manage the HTTP requests sent by an Azure service to another customer, and if that other customer blindly trusts the request – because it comes from a service covered by a service tag – it reaches the victim’s app, potentially allowing the rogue user (let’s say) to remotely control or monitor that app.
“When a service gives users the ability to manage server-side requests, and the service is tied to Azure Service Tags, things can get risky if the customer doesn’t have additional layers of protection in place,” Tenable warned.
To prevent this type of abuse, Microsoft recommends adding authentication and authorization controls and not relying solely on firewall rules.
For example, customers using Azure Monitor Availability Tests, which allows them to monitor the uptime of their resources, would do the following:
The bottom line, according to both vendors, is that multiple layers of security must be implemented to protect valuable resources and data. ®