Private Endpoints mal configurados criam condição de negação de serviço por DNS
Pesquisadores da Palo Alto Networks (Unit42) detalharam uma limitação arquitetural na implementação de Azure Private Endpoint/Private Link que pode causar falhas de resolução DNS e, por consequência, negar serviço a recursos de produção.
Como a condição ocorre
O problema aparece quando um Private Endpoint é criado para uma storage account em um VNET (por exemplo, VNET2). O Azure gera automaticamente uma zona DNS privada ligada àquele VNET. Se essa zona é vinculada também a outro VNET (VNET1), a lógica de resolução do Azure passa a forçar que as resoluções de nome usem a zona privada.
Se não houver um registro "A" correspondente para a storage account no contexto do VNET1, a resolução falha e máquinas virtuais em VNET1 deixam de resolver o hostname da storage account — mesmo que o endpoint público permaneça inalterado. O efeito prático é uma condição de DoS por resolução DNS.
Alcance e cenários de ataque
- Palo Alto estima que a limitação afeta mais de 5% das storage accounts do Azure.
- Três cenários de ocorrência: configuração interna acidental, implantação de Private Endpoints por terceiros (provedores de segurança) e uso malicioso por atores com acesso ao ambiente (deployed endpoints como vetor de DoS).
Impacto operacional
Além da perda de conectividade imediata com storage accounts, há risco secundário quando outros serviços dependem desses recursos: Azure Functions, contêineres, Key Vaults (e processos que dependem de segredos) podem falhar, interrompendo pipelines e operações críticas.
Mitigações e limites
Microsoft reconheceu a limitação e fornece duas mitigações parciais:
- Fallback to internet: opção que permite cair para resolução via internet público quando não existir registro na zona privada — o que, porém, contradiz o princípio de tráfego pelo backbone do Azure.
- Inserção manual de registros DNS: criar registros "A" nas zonas privadas afetadas, solução operacionalmente custosa e de baixa escala para ambientes grandes.
A Unit42 recomenda que defensores identifiquem recursos vulneráveis utilizando consultas no Azure Resource Graph Explorer para localizar virtual networks ligadas a zonas DNS privadas e storage accounts com endpoints públicos ativos. Combinar essas consultas com varredura de rede ajuda mapear a superfície afetada.
O que falta
As fontes descrevem o mecanismo, a estimativa de alcance (>5% de storage accounts) e as mitigações conhecidas, mas não apresentam evidências públicas de exploração ativa em larga escala. Não há detalhes sobre eventuais ferramentas de exploração; o risco real dependerá de controles de acesso ao tenant e de políticas de gestão de DNS/Private Link.
Recomendações práticas
- Auditar ligações de Private DNS Zone entre VNETs e inventariar storage accounts com endpoints públicos.
- Considerar políticas de controle de quem pode criar Private Endpoints no tenant.
- Planejar alternativas operacionais caso opte‑se por aplicar o fallback ou pelo preenchimento manual de registros DNS em larga escala.
Equipes de nuvem e segurança devem tratar essa limitação como risco operacional e incluir verificação de Private Link e DNS em avaliações de arquitetura de rede no Azure.