iTranslated by AI
Spoofing Risks in Multi-tenant Services
Recently, following a security risk report from Tenable[1], Microsoft updated and added to the documentation for some Azure services. Details of the background and specifics are published in the following official blogs.
- Improved Guidance for Azure Network Service Tags | MSRC Blog
- Abusing Service Tags to Bypass Azure Firewall Rule
At first, I also thought, "Oh, it's just about Azure," but as I read further, I realized it wasn't limited to Azure. In other words, it was simply explaining a risk that any user utilizing multi-tenant services must be wary of.
In this article, I will try to explain the situation using as little Azure-specific terminology as possible, hoping it serves as an opportunity for more people to become aware of this risk.
TL;DR
Here are the conclusions upfront.
- In multi-tenant services, access control relying solely on IP addresses may be insufficient.
- Implement authentication and authorization at the application layer based on Zero Trust or defense-in-depth principles.
- For example, send credentials using request headers and verify them on the server side.
Assumed Scenario
Consider a multi-tenant cloud service where multiple tenants (Tenant A, B) are running different applications. The application execution platform is equipped with Access Control (ACL) functionality for traffic.
Also, there is a situation where requests are generated for the application from a specific service within the cloud. For example, you might imagine health check communications from a monitoring service to an application, or integration from a serverless architecture front end to a back end.
Furthermore, this specific service is a multi-tenant service, and its specification is to randomly use a specific global IP address range as the source of requests.
The above diagram illustrates these assumptions.
From Tenant A's perspective, they expect that as a result of configuration, operations, or requests to the preceding "multi-tenant service," requests will eventually go from the "multi-tenant service" to the application owned by Tenant A. Therefore, they have configured the ACL as follows:
- Allow if the request source is within the IP range of the "multi-tenant service."
- Deny everything else.
What is the Problem?
The settings described above do not fully account for the risk of multi-tenant services being used for spoofing.
The diagram above shows how an unexpected request is generated by a malicious user. For example, an attacker can succeed in an attack with the following preparations:
| Examples of Multi-tenant Services | Attacker's Preparation |
|---|---|
| Monitoring service | Set Tenant A's application as the monitoring target |
| CDN service | Set Tenant A's application as the origin server |
| Event-driven computing service | Code it to issue requests to Tenant A's application |
How to Deal with It
The root cause is fully trusting the multi-tenant service.
Even if requests come from a specific IP address range, you should check the content of the request. Access control based on IP address perimeters (perimeter security) has its limits. While the specific mitigation methods will vary by service, the general policy remains the same: implement authentication and authorization at the application layer. This is consistent with the principles of Zero Trust and defense-in-depth.
To provide more concrete examples, I will introduce two instances of how this is handled in Azure.
Azure Front Door
Azure Front Door is a CDN service using facilities in edge locations[2] owned by Microsoft.
Azure Front Door is assigned a unique value (Front Door identifier) for each resource, which is transmitted to the origin server side as a request header (X-Azure-FDID). Therefore, the origin server can ensure the security of the delivery source by only allowing requests that have this information.
Azure Monitor (Application Insights)
One of Azure's monitoring functions is the Application Insights availability test. This is a solution for monitoring the availability and responsiveness of web applications. It periodically generates HTTP/S requests to specific endpoints and records the response status.
Since you can include custom headers/values in the monitoring HTTP/S requests, you can use this feature to mitigate spoofing risks. The specific procedure is described in the document below.
Summary
In this article, I have explained the challenges and solutions for access control in multi-tenant services. Specifically, I explained that access control based simply on IP address ranges is insufficient and vulnerable to attacks such as spoofing.
To prevent this, it is necessary to implement authentication and authorization at the application layer based on the principles of Zero Trust and defense-in-depth. For example, I introduced methods such as verifying identification information using request headers in Azure Front Door and using custom headers in Azure Monitor availability tests to confirm that requests are legitimate.
To ensure security in a cloud environment, it is important to combine multiple measures to minimize risk. Please consider reviewing and strengthening your company's security measures based on the methods introduced here.
References
- Improved guidance for Azure network service tags | MSRC Blog | Microsoft Security Response Center
- Azure service tags overview | Microsoft Learn
- What is an IP-based Access Control List (ACL)? - Azure Virtual Network | Microsoft Learn
-
A cybersecurity company with vulnerability assessment solutions (https://www.tenable.com/) ↩︎
-
Currently, there are 192 edge locations in 109 cities. https://learn.microsoft.com/en-us/azure/frontdoor/edge-locations-by-region ↩︎
Discussion