Tenable Research has reported a vulnerability in Microsoft Azure service tags that “allows an attacker to bypass firewall rules … by forging requests from trusted services.”
“The vulnerability was discovered initially in the Azure Application Insights service, but we and the Microsoft Security Response Center (MSRC) eventually found that it affects more than 10 other Azure services,” according to the report, released June 3. “In each case, attackers would be able to access other internal and private Azure services.”
The report quoted an unnamed Microsoft employee contacted by Tenable as saying: “Service Tags are not sufficient to secure traffic to a customer’s origin without considering the nature of the service and the traffic it may send. It is always the best practice to implement authentication/authorization for traffic rather than relying on firewall rules alone.”
The fix for this issue is for CISOs to add authentication layers to protect the service tags. And therein lies the complexity — is this a situation in which Microsoft should add authentication natively before the service is enabled or should CIOs and CISOs add their own authentication so they can decide how much friction they can afford to impose on third parties and end-users?
Microsoft’s decision not to address issue may be the right one
Brian Levine, a managing director at Ernst & Young, said Microsoft’s decision in this case “may not be unreasonable.” He said that he has heard from a lot of enterprise CISO clients that they don’t necessarily want vendors imposing authentication on everything.
“You can always increase authentication requirements, but companies have to balance strong authentication against user frustration /rebellion,” Levine said. “Every situation is different and complex so at times it is best to let the customer figure out the right balance, as opposed to security providers mandating a particular strong level of authentication for all situations.”
Josh Morganthall, the Microsoft practice manager at security managed service provider Blue Mantis, agreed that Microsoft likely made the right call. Still, he said, “This is a big deal” because about 75% of enterprises today are not adding the needed authentication around network traffic handled by Azure tags.
The tags “don’t work intuitively the way they should. [Enterprise IT and security leaders] thought this was sufficient. This was assumed to work in a certain (secure) way and when you get right down to it, it doesn’t.”
Authenticating network traffic that is being allowed through by Azure service tags “is a good setup for organizations that have the maturity to manage these decisions on their own,” Morganthall said.
Paul Robichaux, senior director of product management at cloud security vendor Keepit, agreed that Microsoft’s decision not to address the vulnerability was reasonable. “I think Microsoft called this one correctly. This isn’t nothing, but it’s not a big deal either. It is a theoretical vulnerability if you’re using Azure service tags as a single point of control.”
“But if someone walks in your office wearing a polo shirt with your company logo, you don’t automatically give them free run of the place,” Robichaux said. “Trusting service tags as the only control mechanism is the same thing. You could do it, but you wouldn’t. Instead, you’d have other authentication methods used in parallel.”
Exploiting the vulnerability is straightforward
The Tenable report said the potential method for exploiting the vulnerability is straightforward. It noted that multiple Azure services allow customers to craft web requests, some even allowing users to add headers and change HTTP methods.
“For example, since the Azure Application Insight Availability Tests Feature tests the availability of applications deployed by clients, clients require full control of the request to create a functional test,” the report said.
“However, this functionality may open the door for a malicious actor to achieve an impact similar to that of a server-side request forgery (SSRF) vulnerability. SSRF allows an attacker to cause a server-side application to make requests to an unintended location, whether internal or external, allowing the attacker, among other options, to reach/expose resources that were previously unreachable.”
Azure advises customers to use a Service Tag to only allow the Application Insights Availability service to monitor and access an internal application or machine through port 80 or 443, the report said.
“Attackers can send requests using the availability tests feature of the Application Insights Availability service. Through this, they can access the internal services of cross-tenant victims who blindly trust the Application Insights Availability Service Tag in their firewall rule.”
That would allow an attacker to access internal APIs in the victim’s service, “since the exposed ports are 80/443, which usually host web assets.”