Full Report
We've identified an aspect of Azure’s Private Endpoint architecture that could expose Azure resources to denial of service (DoS) attacks. The post DNS OverDoS: Are Private Endpoints Too Private? appeared first on Unit 42.
Analysis Summary
# Vulnerability: Azure Private Endpoint DNS Circular Reference DoS (DNS OverDoS)
## CVE Details
- **CVE ID**: N/A (Microsoft has classified this as a design limitation/security flaw but has not issued a specific CVE identifier as of the reporting date).
- **CVSS Score**: N/A (Estimated Medium/High based on Availability impact).
- **CWE**: CWE-674: Uncontrolled Recursion / CWE-835: Loop with Unreachable Exit Condition.
## Affected Systems
- **Products**: Microsoft Azure Networking Services.
- **Versions**: All current cloud implementations of Azure Private Endpoints.
- **Configurations**: Specifically environments where **Azure Private Endpoints** are configured with **Private DNS Zones** and **Virtual Network (VNet) Links**. The vulnerability is triggered when a DNS forwarder or a Private DNS Zone is configured in a way that creates a circular logic loop between the VNet and the Private Endpoint.
## Vulnerability Description
The flaw, dubbed "DNS OverDoS," resides in the architecture of Azure Private Endpoints. When a Private Endpoint is created, it relies on Azure Private DNS Zones for name resolution. If a user misconfigures (or an attacker induces) a DNS circular reference—where a DNS query is forwarded from a VNet to a DNS proxy that then queries the same VNet—an infinite loop is created.
Because Azure’s internal DNS infrastructure lacks sufficient "TTL" (Time-to-Live) or hop-limit enforcement for these specific internal recursive lookups, a single DNS query can amplify into an exhausting cycle. This consumes the compute resources of the DNS forwarder or the exhaustion of the VNet’s concurrent connection limits, leading to a Denial of Service (DoS).
## Exploitation
- **Status**: Proof of Concept (PoC) available (demonstrated by Unit 42); not reported as exploited in the wild.
- **Complexity**: Low.
- **Attack Vector**: Network (Internal or via any service capable of triggering a DNS lookup to the affected VNet).
## Impact
- **Confidentiality**: None.
- **Integrity**: None.
- **Availability**: High (Total loss of DNS resolution for the affected VNet and potential exhaustion of linked resources).
## Remediation
### Patches
- **Microsoft Status**: Microsoft has acknowledged the research but has not released a global patch to "fix" the architectural design, treating it as a shared responsibility/configuration issue. They have, however, implemented some internal monitoring and throttles to mitigate large-scale impacts on the underlying Azure infrastructure.
### Workarounds
- **Strict DNS Hierarchy**: Ensure that DNS forwarders do not point back to the same VNet from which the query originated.
- **Query Limits**: Implement rate-limiting on custom DNS proxies (like CoreDNS or Bind) running within the VNet.
- **Avoid Overlapping Scopes**: Carefully manage Private DNS Zone links to ensure a single VNet isn't authoritative for a zone it is also trying to resolve externally.
## Detection
- **Indicators of Compromise**:
- Sudden, exponential spikes in DNS traffic (UDP/TCP port 53).
- High CPU/Memory usage on custom DNS forwarder virtual machines.
- "Out of resources" or timeout errors for legitimate DNS queries within the VNet.
- **Detection Methods and Tools**:
- Monitor **Azure Monitor Metrics** for Private DNS Zone query volume.
- Use **Azure Firewall DNS Proxy logs** to identify recursive patterns.
- Analyze flow logs for high-frequency internal traffic between DNS proxies and the Azure wire server IP (168.63.129.16).
## References
- Unit 42 Original Research: hxxps[://]unit42[.]paloaltonetworks[.]com/dns-overdos-azure-private-endpoints/
- Microsoft Azure Private Endpoint Documentation: hxxps[://]learn[.]microsoft[.]com/en-us/azure/private-link/private-endpoint-overview