Evitar entradas DNS pendentes e controlo de domínios
Este artigo descreve a ameaça de segurança comum da aquisição de subdomínios e as etapas que você pode tomar para atenuá-la.
O que é uma aquisição de subdomínio?
As aquisições de subdomínios são uma ameaça comum e de alta gravidade para organizações que criam e excluem regularmente muitos recursos. Uma aquisição de subdomínio pode ocorrer quando você tem um registro DNS que aponta para um recurso do Azure desprovisionado. Esses registos DNS também são conhecidos como entradas "DNS pendentes". Os registos CNAME são especialmente vulneráveis a esta ameaça. As obtenções de controlo de subdomínios permitem que os intervenientes maliciosos redirecionem o tráfego destinado ao domínio de uma organização para um site que realiza atividades maliciosas.
Um cenário comum para uma aquisição de subdomínio:
CRIAÇÃO:
Você provisiona um recurso do Azure com um nome de domínio totalmente qualificado (FQDN) do
app-contogreat-dev-001.azurewebsites.net
.Você atribui um registro CNAME em sua zona DNS com o subdomínio
greatapp.contoso.com
que roteia o tráfego para seu recurso do Azure.
DESPROVISIONAMENTO:
O recurso do Azure é desprovisionado ou excluído depois que não é mais necessário.
Neste ponto, o registro
greatapp.contoso.com
CNAME deve ser removido da sua zona DNS. Se o registro CNAME não for removido, ele será anunciado como um domínio ativo, mas não roteará o tráfego para um recurso ativo do Azure. Agora você tem um registro DNS "pendurado".O subdomínio pendente,
greatapp.contoso.com
, agora está vulnerável e pode ser assumido sendo atribuído a outro recurso de assinatura do Azure.
AQUISIÇÃO:
Usando métodos e ferramentas comumente disponíveis, um agente de ameaça descobre o subdomínio pendente.
O agente de ameaça provisiona um recurso do Azure com o mesmo FQDN do recurso que você controlava anteriormente. Neste exemplo,
app-contogreat-dev-001.azurewebsites.net
.O tráfego que está sendo enviado para o subdomínio
greatapp.contoso.com
agora é roteado para o recurso do ator mal-intencionado, onde ele controla o conteúdo.
Os riscos de aquisição de subdomínios
Quando um registo DNS aponta para um recurso que não está disponível, o próprio registo deve ser removido da sua zona DNS. Se não for excluído, é um registro de "DNS pendurado" e cria a possibilidade de aquisição de subdomínio.
As entradas DNS Dangling possibilitam que os agentes de ameaças assumam o controle do nome DNS associado para hospedar um site ou serviço mal-intencionado. Páginas e serviços mal-intencionados no subdomínio de uma organização podem resultar em:
Perda de controle sobre o conteúdo do subdomínio - Imprensa negativa sobre a incapacidade da sua organização de proteger seu conteúdo, danos à marca e perda de confiança.
Recolha de cookies de visitantes desavisados - É comum que as aplicações Web exponham cookies de sessão a subdomínios (*.contoso.com). Qualquer subdomínio pode acessá-los. Os agentes de ameaças podem usar a aquisição de subdomínios para criar uma página de aparência autêntica, enganar usuários desavisados para visitá-la e coletar seus cookies (até mesmo cookies seguros). Um equívoco comum é que o uso de certificados SSL protege seu site e os cookies de seus usuários contra uma aquisição. No entanto, um agente de ameaça pode usar o subdomínio sequestrado para solicitar e receber um certificado SSL válido. Os certificados SSL válidos concedem-lhes acesso a cookies seguros e podem aumentar ainda mais a legitimidade percebida do site malicioso.
Campanhas de phishing - Os agentes mal-intencionados geralmente exploram subdomínios com aparência autêntica em campanhas de phishing. O risco se estende a sites mal-intencionados e registros MX, o que pode permitir que agentes de ameaças recebam e-mails direcionados a subdomínios legítimos associados a marcas confiáveis.
Outros riscos - Sites mal-intencionados podem ser usados para escalar para outros ataques clássicos, como XSS, CSRF, CORS bypass e muito mais.
Identificar entradas DNS pendentes
Para identificar entradas DNS em sua organização que possam estar pendentes, use as ferramentas PowerShell hospedadas no GitHub da Microsoft "Get-DanglingDnsRecords".
Esta ferramenta ajuda os clientes do Azure a listar todos os domínios com um CNAME associado a um recurso existente do Azure que foi criado nas respetivas subscrições ou inquilinos.
Se os CNAMEs estiverem noutros serviços DNS e apontarem para os recursos do Azure, forneça os CNAMEs num ficheiro de entrada para a ferramenta.
A ferramenta dá suporte aos recursos do Azure listados na tabela a seguir. A ferramenta extrai, ou toma como entradas, todos os CNAMEs do locatário.
Serviço | Type | FQDNproperty | Exemplo |
---|---|---|---|
Azure Front Door | microsoft.network/frontdoors | propriedades.cNome | abc.azurefd.net |
Armazenamento de Blobs do Azure | microsoft.storage/storageaccounts | propriedades.primaryEndpoints.blob | abc.blob.core.windows.net |
CDN do Azure | microsoft.cdn/perfis/pontos de extremidade | propriedades.hostName | abc.azureedge.net |
Endereços IP públicos | microsoft.network/publicipaddresses | propriedades.dnsSettings.fqdn | abc.EastUs.cloudapp.azure.com |
Gestor de Tráfego do Azure | Microsoft.Network/TrafficManagerProfiles | propriedades.dnsConfig.fqdn | abc.trafficmanager.net |
Azure Container Instance | Microsoft.ContainerInstance/ContainerGroups | propriedades.ipAddress.fqdn | abc.EastUs.azurecontainer.io |
API Management do Azure | microsoft.apimanagement/serviço | properties.hostnameConfigurations.hostName | abc.azure-api.net |
Serviço de Aplicações do Azure | microsoft.web/sites | properties.defaultHostName | abc.azurewebsites.net |
Serviço de Aplicativo do Azure - Slots | microsoft.web/sites/slots | properties.defaultHostName | abc-def.azurewebsites.net |
Pré-requisitos
Execute a consulta como um usuário que tenha:
- pelo menos acesso ao nível do leitor às subscrições do Azure
- acesso de leitura ao gráfico de recursos do Azure
Se for um Administrador Global do inquilino da sua organização, siga as orientações em Elevar o acesso para gerir todas as subscrições do Azure e grupos de gestão para obter acesso a todas as subscrições da sua organização
Gorjeta
O Azure Resource Graph tem limites de limitação e paginação que você deve considerar se tiver um ambiente grande do Azure.
Saiba mais sobre como trabalhar com grandes conjuntos de dados de recursos do Azure.
A ferramenta usa o processamento em lote de assinaturas para evitar essas limitações.
Executar o script
Saiba mais sobre o script do PowerShell, Get-DanglingDnsRecords.ps1, e baixe-o do GitHub: https://aka.ms/Get-DanglingDnsRecords.
Remediar entradas DNS pendentes
Revise suas zonas DNS e identifique os registros CNAME que estão pendurados ou assumidos. Se os subdomínios estiverem pendentes ou tiverem sido assumidos, remova os subdomínios vulneráveis e mitigue os riscos com os seguintes passos:
Na zona DNS, remova todos os registos CNAME que apontem para FQDNs de recursos que já não estão aprovisionados.
Para permitir que o tráfego seja roteado para recursos sob seu controle, provisione mais recursos com os FQDNs especificados nos registros CNAME dos subdomínios pendentes.
Reveja o código da aplicação para obter referências para subdomínios específicos e atualize as referências de subdomínios incorretas ou desatualizadas.
Investigue se ocorreu algum comprometimento e tome medidas de acordo com os procedimentos de resposta a incidentes da sua organização. Dicas e melhores práticas para investigar:
Se a lógica do seu aplicativo resultar em segredos, como credenciais OAuth, sendo enviados para subdomínios pendentes ou se informações confidenciais de privacidade forem transmitidas para esses subdomínios, há a possibilidade de esses dados serem expostos a terceiros.
Entenda por que o registro CNAME não foi removido da sua zona DNS quando o recurso foi desprovisionado e tome medidas para garantir que os registros DNS sejam atualizados adequadamente quando os recursos do Azure forem desprovisionados no futuro.
Evitar entradas DNS pendentes
Garantir que sua organização tenha implementado processos para evitar entradas DNS pendentes e as aquisições de subdomínios resultantes é uma parte crucial do seu programa de segurança.
Alguns serviços do Azure oferecem recursos para ajudar na criação de medidas preventivas e são detalhados abaixo. Outros métodos para evitar esse problema devem ser estabelecidos por meio das práticas recomendadas ou dos procedimentos operacionais padrão da sua organização.
Habilitar o Microsoft Defender para Serviço de Aplicativo
A plataforma integrada de proteção de carga de trabalho na nuvem (CWPP) do Microsoft Defender for Cloud oferece uma variedade de planos para proteger seus recursos e cargas de trabalho do Azure, híbridos e multicloud.
O plano do Microsoft Defender para Serviço de Aplicativo inclui deteção de DNS pendente. Com esse plano habilitado, você receberá alertas de segurança se encerrar um site do Serviço de Aplicativo, mas não remover seu domínio personalizado do registrador de DNS.
A proteção DNS pendente do Microsoft Defender for Cloud está disponível independentemente de seus domínios serem gerenciados com o DNS do Azure ou um registrador de domínios externo e se aplica ao Serviço de Aplicativo no Windows e Linux.
Saiba mais sobre este e outros benefícios destes planos do Microsoft Defender em Introdução ao Microsoft Defender para Serviço de Aplicativo.
Usar registros de alias DNS do Azure
Os registros de alias do DNS do Azure podem evitar referências pendentes acoplando o ciclo de vida de um registro DNS a um recurso do Azure. Por exemplo, considere um registro DNS qualificado como um registro de alias para apontar para um endereço IP público ou um perfil do Gerenciador de Tráfego. Se você excluir esses recursos subjacentes, o registro de alias DNS se tornará um conjunto de registros vazio. Ele não faz mais referência ao recurso excluído. É importante observar que há limites para o que você pode proteger com registros de alias. Hoje, a lista limita-se a:
- Azure Front Door
- Perfis do Gestor de Tráfego
- Pontos de extremidade da Rede de Entrega de Conteúdo (CDN) do Azure
- IPs Públicos
Apesar das ofertas de serviços limitadas atuais, recomendamos o uso de registros de alias para se defender contra a aquisição de subdomínios sempre que possível.
Saiba mais sobre os recursos dos registros de alias do DNS do Azure.
Usar a verificação de domínio personalizada do Serviço de Aplicativo do Azure
Ao criar entradas DNS para o Serviço de Aplicativo do Azure, crie um asuid. {subdomínio} Registo TXT com o ID de Verificação de Domínio. Quando esse registro TXT existe, nenhuma outra Assinatura do Azure pode validar o Domínio Personalizado, ou seja, assumi-lo.
Esses registros não impedem que alguém crie o Serviço de Aplicativo do Azure com o mesmo nome que está na sua entrada CNAME. Sem a capacidade de provar a propriedade do nome de domínio, os agentes de ameaças não podem receber tráfego ou controlar o conteúdo.
Saiba mais sobre como mapear um nome DNS personalizado existente para o Serviço de Aplicativo do Azure.
Crie e automatize processos para mitigar a ameaça
Muitas vezes, cabe aos desenvolvedores e às equipes de operações executar processos de limpeza para evitar ameaças de DNS pendentes. As práticas abaixo ajudarão a garantir que sua organização evite sofrer essa ameaça.
Crie procedimentos para prevenção:
Eduque seus desenvolvedores de aplicativos para redirecionar endereços sempre que excluírem recursos.
Coloque "Remover entrada DNS" na lista de verificações necessárias ao desativar um serviço.
Coloque bloqueios de exclusão em todos os recursos que tenham uma entrada DNS personalizada. Um bloqueio de exclusão serve como um indicador de que o mapeamento deve ser removido antes que o recurso seja desprovisionado. Medidas como esta só podem funcionar quando combinadas com programas internos de educação.
Crie procedimentos para descoberta:
Reveja os seus registos DNS regularmente para garantir que os seus subdomínios estão todos mapeados para recursos do Azure que:
- Existir - Consulte suas zonas DNS em busca de recursos que apontem para subdomínios do Azure, como *.azurewebsites.net ou *.cloudapp.azure.com (consulte a Lista de referência de domínios do Azure).
- Você possui - Confirme que você possui todos os recursos que seus subdomínios DNS estão direcionando.
Mantenha um catálogo de serviços de seus pontos de extremidade FQDN (nome de domínio totalmente qualificado) do Azure e os proprietários do aplicativo. Para criar seu catálogo de serviços, execute o seguinte script de consulta do Gráfico de Recursos do Azure. Esse script projeta as informações do ponto de extremidade FQDN dos recursos aos quais você tem acesso e os produz em um arquivo CSV. Se você tiver acesso a todas as assinaturas para seu locatário, o script considerará todas essas assinaturas conforme mostrado no script de exemplo a seguir. Para limitar os resultados a um conjunto específico de assinaturas, edite o script conforme mostrado.
Crie procedimentos para remediação:
- Quando entradas DNS pendentes são encontradas, sua equipe precisa investigar se ocorreu algum comprometimento.
- Investigue por que o endereço não foi redirecionado quando o recurso foi desativado.
- Exclua o registro DNS se ele não estiver mais em uso ou aponte-o para o recurso correto do Azure (FQDN) de propriedade de sua organização.
Limpar ponteiros DNS ou recuperar o DNS
Após a exclusão do recurso de serviço de nuvem clássico, o DNS correspondente é reservado de acordo com as políticas de DNS do Azure. Durante o período de reserva, a reutilização do DNS será proibida EXCETO para subscrições pertencentes ao inquilino Microsoft Entra da subscrição originalmente proprietária do DNS. Depois que a reserva expirar, o DNS é livre para ser reivindicado por qualquer assinatura. Ao aceitar reservas de DNS, o cliente tem algum tempo para 1) limpar quaisquer associações/ponteiros para esse DNS ou 2) recuperar o DNS no Azure. A recomendação seria excluir entradas DNS indesejadas no mínimo. O nome DNS que está sendo reservado pode ser derivado anexando o nome do serviço de nuvem à zona DNS dessa nuvem.
- Público - cloudapp.net
- Mooncake - chinacloudapp.cn
- Fairfax - usgovcloudapp.net
- BlackForest - azurecloudapp.de
Por exemplo, um serviço hospedado em Public chamado "test" teria DNS "test.cloudapp.net"
Exemplo: A subscrição 'A' e a subscrição 'B' são as únicas subscrições pertencentes ao inquilino do Microsoft Entra 'AB'. A subscrição 'A' contém um 'teste' clássico do serviço na nuvem com o nome DNS 'test.cloudapp.net'. Após a exclusão do serviço de nuvem, uma reserva é feita no nome DNS 'test.cloudapp.net'. Durante o período de reserva, apenas a subscrição 'A' ou a subscrição 'B' poderão reivindicar o nome DNS 'test.cloudapp.net' criando um serviço de nuvem clássico denominado 'teste'. Nenhuma outra assinatura poderá reivindicá-lo. Após o período de reserva, qualquer assinatura no Azure agora pode reivindicar 'test.cloudapp.net'.
Próximos passos
Para saber mais sobre serviços relacionados e recursos do Azure que você pode usar para se defender contra a aquisição de subdomínio, consulte as páginas a seguir.
Habilite o Microsoft Defender para Serviço de Aplicativo - para receber alertas quando entradas DNS pendentes forem detetadas