A vulnerability in Azure allows attackers to bypass firewall rules relying on Azure Service Tags. By forging requests mimicking trusted services, attackers can exploit service tags permitted through a user’s firewall if additional validation controls are absent.
It grants access to a user’s Azure service and potentially other internal Azure services, as the attacker’s control over server-side request forgery enables the impersonation of trusted Azure services.
The development lifecycle is impacted as several Azure services are affected. Application monitoring (Application Insights) and code management (Azure DevOps) are hindered.
Training and deploying machine learning models (Azure Machine Learning) are restricted. Logic workflows (Azure Logic Apps) and container image storage (Azure Container Registry) are unavailable.
Performance testing (Azure Load Testing) and API management (Azure API Management) are down, and data pipelines (Azure Data Factory) cannot be created or executed. Alert notifications (Azure Action Group) are disrupted.
Video analysis with AI (Azure AI Video Indexer) is unavailable, and chaos engineering experiments for resilience testing (Azure Chaos Studio) are on hold.
Researchers have discovered a flaw in Azure that makes it possible for attackers to circumvent the firewall rules that are designed to protect internal services.
While they consider this a high severity issue due to potential data breaches, Microsoft categorized it as an elevation of privilege with an “important” severity rating, likely because their system focuses on exploitability and Microsoft believes additional authentication is needed for full compromise.
Both parties agree that service tags alone are insufficient for security and recommend layered defenses including authentication and authorization.
Microsoft identified a vulnerability in their service tags that could potentially bypass firewall rules. To address this, they created centralized documentation to educate users on secure usage patterns for service tags.
However, this doesn’t eliminate the underlying vulnerability. To mitigate the risk, users should implement additional security layers like authentication and authorization on top of the existing network controls managed by service tags.
Tenable identified a vulnerability and reported it to the vendor on January 24th. After MSRC confirmed and rewarded the finding, they initially planned a targeted fix and opted for a broader solution, including updated documentation and addressing more vulnerability variations by March 6th.
A coordinated public disclosure was then scheduled for May, with Tenable submitting a draft blog post in late April and collaborating with MSRC on revisions until early May, and the vulnerability was ultimately disclosed publicly on June 3rd.
Also Read:
