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:

  1. CRIAÇÃO:

    1. Você provisiona um recurso do Azure com um nome de domínio totalmente qualificado (FQDN) do app-contogreat-dev-001.azurewebsites.net.

    2. 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.

  2. DESPROVISIONAMENTO:

    1. O recurso do Azure é desprovisionado ou excluído depois que não é mais necessário.

      Neste ponto, o registro greatapp.contoso.comCNAME 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. Esta é a definição de um registro DNS "pendurado".

    2. O subdomínio pendente, , greatapp.contoso.comagora está vulnerável e pode ser assumido sendo atribuído a outro recurso de assinatura do Azure.

  3. AQUISIÇÃO:

    1. Usando métodos e ferramentas comumente disponíveis, um agente de ameaça descobre o subdomínio pendente.

    2. 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.

    3. 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.

Subdomain takeover from a deprovisioned website

Os riscos da aquisição de subdomínios

Quando um registo DNS aponta para um recurso que não está disponível, o próprio registo deve ter sido removido da sua zona DNS. Se não tiver sido eliminado, é um registo de "DNS pendente" e cria a possibilidade de aquisição de subdomínios.

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, bem como os 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), consequentemente qualquer subdomínio pode aceder aos mesmos. 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 - Subdomínios com aparência autêntica podem ser usados em campanhas de phishing. Isso é verdade para sites mal-intencionados e para registros MX que permitiriam que o agente de ameaça recebesse e-mails endereçados a um subdomínio legítimo de uma marca conhecida e segura.

  • 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.

Service Tipo 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, eleve a sua conta para ter acesso a toda a subscrição da sua organização utilizando as orientações em Elevar o acesso para gerir todas as subscrições e grupos de gestão do Azure.

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

Reveja as zonas DNS e identifique os registos CNAME que estão pendentes ou cujo controlo foi assumido. Se os subdomínios estiverem pendentes ou tiverem sido assumidos, remova os subdomínios vulneráveis e mitigue os riscos com os seguintes passos:

  1. Na zona DNS, remova todos os registos CNAME que apontem para FQDNs de recursos que já não estão aprovisionados.

  2. Para permitir que o tráfego seja encaminhado para recursos no seu controlo, aprovisione recursos adicionais com os FQDNs especificados nos registos CNAME dos subdomínios pendentes.

  3. 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.

  4. Investigue se ocorreu algum comprometimento e tome medidas de acordo com os procedimentos de resposta a incidentes da sua organização. Dicas e práticas recomendadas para investigar esse problema podem ser encontradas abaixo.

    Se a lógica da aplicação for tal que segredos como credenciais OAuth tenham sido enviados para o subdomínio pendente ou se as informações sensíveis à privacidade tiverem sido enviadas para os subdomínios pendentes, esses dados poderão ter sido expostos a terceiros.

  5. 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 for App Service inclui deteção de DNS pendente. Com esse plano ativado, 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 ao associar 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 da 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.