Impedir entradas DNS pendentes e evitar tomada de controle de subdomínio

Este artigo descreve a ameaça de segurança comum de tomada de controle de subdomínio e as etapas que você pode tomar para reduzi-la.

O que é uma tomada de controle de subdomínio?

As tomadas de controle de subdomínio são uma ameaça comum e de alta gravidade para as organizações que criam e excluem muitos recursos regularmente. Uma tomada de controle de subdomínio pode ocorrer quando um registro DNS indicar um recurso desprovisionado do Azure. Esses registros DNS também são conhecidos como entradas "DNS pendentes". Os registros CNAME são particularmente vulneráveis a essa ameaça. As invasões de subdomínio permitem que os atores mal-intencionados redirecionem o tráfego destinado ao domínio de uma organização a um site que executa atividades mal-intencionadas.

Um cenário comum de uma tomada de controle de subdomínio:

1. CRIAÇÃO:

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

   2. Você atribui um registro CNAME na zona DNS com o subdomínio greatapp.contoso.com que roteia o tráfego para o recurso do Azure.

2. DESPROVISIONAMENTO:

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

      Neste ponto, o registro CNAME greatapp.contoso.com deve ser removido da 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 "pendente".

   2. O subdomínio pendente, greatapp.contoso.com, agora está vulnerável e pode ser controlado ao ser atribuído a outro recurso da assinatura do Azure.

3. TOMADA DE CONTROLE:

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

   2. O ator de ameaça provisiona um recurso do Azure com o mesmo FQDN do recurso que você controlou 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.

Os riscos da tomada de controle de subdomínio

Quando um registro DNS aponta para um recurso que não está disponível, o próprio registro deve ser removido da sua zona DNS. Se não for excluído, é um registro de “DNS pendente” e cria a possibilidade de controle de subdomínio.

As entradas DNS pendentes possibilitam que atores de ameaça 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.

• Coleta de cookies de visitantes desavisados - é comum que aplicativos Web exponham cookies de sessão a subdomínios (*.contoso.com). Qualquer subdomínio pode acessá-los. Os atores da ameaça podem usar a tomada de controle de subdomínio para criar uma página de aparência autêntica, fazer com que usuários ingênuos a visitem e coletar seus cookies (até mesmo cookies seguros). Um equívoco comum é que o uso de certificados SSL protege o site e os cookies dos usuários de uma tomada de controle. No entanto, um ator da ameaça pode usar o subdomínio sequestrado para se aplicar e receber um certificado SSL válido. Os certificados SSL válidos concedem a eles acesso a cookies seguros e podem aumentar ainda mais a legitimidade percebida do site mal-intencionado.

• Campanhas de phishing - Atores maliciosos geralmente exploram subdomínios que parecem autênticos em campanhas de phishing. O risco se estende a sites maliciosos e registros MX, o que poderia permitir que os agentes de ameaças recebessem emails direcionados a subdomínios legítimos associados a marcas confiáveis.

• Riscos adicionais – sites mal-intencionados podem ser usados para escalonar outros ataques clássicos, como XSS, CSRF, desvio de CORS e muito mais.

Identificar entradas DNS pendentes

Para identificar as entradas DNS na organização que podem estar pendentes, use as ferramentas do PowerShell hospedado pelo GitHub da Microsoft "Get-DanglingDnsRecords".

Essa 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 em suas assinaturas ou locatários.

Se os CNAMEs estiverem em outros serviços DNS e apontarem para recursos do Azure, forneça os CNAMEs em um arquivo de entrada para a ferramenta.

A ferramenta dá suporte aos recursos do Azure listados na tabela a seguir. A ferramenta extrai ou usa como entradas todos os CNAMEs do locatário.

Pré-requisitos

Execute a consulta como um usuário com:

• pelo menos acesso de nível de leitor às assinaturas do Azure
• acesso de leitura ao grafo de recursos do Azure

Se você for um Administrador Global do locatário da sua organização, siga as orientações em Elevar o acesso para gerenciar todas as assinaturas e grupos de gerenciamento do Azure para obter acesso a todas as assinaturas da sua organização

Executar o script

Saiba mais sobre o script do PowerShell, Get-DanglingDnsRecords.ps1 e baixe-o pelo GitHub: https://aka.ms/Get-DanglingDnsRecords.

Corrigir entradas DNS pendentes

Revise suas zonas DNS e identifique registros CNAME que estão pendentes ou assumidos. Se os subdomínios estiverem pendentes ou tiverem sido controlados, remova os subdomínios vulneráveis e reduza os riscos com as seguintes etapas:

1. Na zona DNS, remova todos os registros CNAME que apontam para FQDNs de recursos que não são mais provisionados.

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

3. Examine o código do aplicativo para obter referências de subdomínios específicos e atualize todas as referências de subdomínio 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 investigação:

   Se a lógica do seu aplicativo resultar no envio de segredos, como credenciais OAuth, para subdomínios pendentes ou se informações confidenciais forem transmitidas a esses subdomínios, existe a possibilidade de esses dados serem expostos a terceiros.

5. Entenda por que o registro CNAME não foi removido da 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.

Impedir entradas DNS pendentes

Garantir que a organização tenha implementado processos para impedir entradas DNS pendentes e a tomada de controle de subdomínio resultante deve ser uma parte fundamental do programa de segurança.

Alguns serviços do Azure, detalhados abaixo, oferecem recursos para auxiliar na criação de medidas preventivas. Outros métodos para impedir esse problema devem ser estabelecidos por meio das práticas recomendadas da organização ou de procedimentos operacionais padrão.

Habilitar o Microsoft Defender para Serviço de Aplicativo

A CWPP (plataforma de proteção de cargas de trabalho na nuvem) integrada do Microsoft Defender para Nuvem oferece uma variedade de planos para proteger recursos e cargas de trabalho do Azure, híbridos e de várias nuvens.

O plano do Microsoft Defender para Serviço de Aplicativo inclui a detecção de DNS pendente. Com esse plano habilitado, você receberá alertas de segurança se desativar um site do Serviço de Aplicativo, mas não remover o domínio personalizado do registrador de DNS.

A proteção de DNS pendente do Microsoft Defender para Nuvem estará disponível se os domínios forem gerenciados com o DNS do Azure ou um registrador de domínios externo. Além disso, ela se aplica ao Serviço de Aplicativo no Windows e no Linux.

Saiba mais sobre este e outros benefícios do plano do Microsoft Defender em Introdução ao Microsoft Defender para Serviço de Aplicativo.

Usar registros de alias do DNS do Azure

Os registros de alias do DNS do Azure podem impedir 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 de DNS se tornará um conjunto de registros vazio. Ele não fará mais referência ao recurso excluído. É importante observar que há um limite para o que você pode proteger com registros de alias. Atualmente, a lista está limitada a:

• Porta da frente do Azure
• Perfis do Gerenciador de Tráfego
• Pontos de extremidade da CDN (Rede de Distribuição de Conteúdo) do Azure
• IPs Públicos

Apesar das ofertas de serviço limitadas atuais, recomendamos o uso de registros de alias para se defender contra a tomada de controle de subdomínio sempre que possível.

Saiba mais sobre as funcionalidade dos registros de alias do DNS do Azure.

Usar a verificação de domínio personalizado do Serviço de Aplicativo do Azure

Ao criar entradas DNS para o Serviço de Aplicativo do Azure, crie um registro TXT asuid.{subdomain} com a ID de verificação de domínio. Quando existe esse registro TXT, nenhuma outra assinatura do Azure pode validar nem tomar o controle do domínio personalizado.

Esses registros não impedem que alguém crie o Serviço de Aplicativo do Azure com o mesmo nome que está na entrada CNAME. Sem conseguir provar a propriedade do nome de domínio, os atores de ameaças não podem receber tráfego nem controlar o conteúdo.

Saiba mais sobre como mapear um nome DNS personalizado existente para o Serviço de Aplicativo do Azure.

Criar e automatizar processos para reduzir a ameaça

Muitas vezes, os desenvolvedores e as equipes de operações executam processos de limpeza para evitar ameaças de DNS pendente. As práticas a seguir ajudarão a garantir que a organização não sofra essa ameaça.

• Criar procedimentos para prevenção:

  • Instrua os desenvolvedores de aplicativos a redirecionar endereços sempre que os recursos forem excluídos.

  • Coloque "Remover entrada DNS" na lista de verificações obrigatórias ao encerrar um serviço.

  • Coloque bloqueios de exclusão em todos os recursos com 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 essa funcionam somente quando combinadas a programas de treinamento interno.

• Criar procedimentos para descoberta:

  • Examine os registros DNS regularmente para garantir que todos os subdomínios estão mapeados para os recursos do Azure que:

    • Existem – consulte as zonas DNS para ver os recursos que apontam para os subdomínios do Azure, como *.azurewebsites.net ou *.cloudapp.azure.com (confira a Lista de referência de domínios do Azure).
    • Você possui – confirme que você possui todos os recursos que os subdomínios DNS estão direcionando.

  • Mantenha um catálogo de serviços dos pontos de extremidade de FQDN (nome de domínio totalmente qualificado) do Azure e os proprietários do aplicativo. Para criar o catálogo de serviços, execute o script de consulta do Azure Resource Graph a seguir. Esse script projeta as informações do ponto de extremidade de FQDN dos recursos aos quais você tem acesso e as gera em um arquivo CSV. Se você tiver acesso a todas as assinaturas do 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.

• Criar procedimentos para correção:

  • Quando forem encontradas entradas DNS pendentes, a equipe precisará investigar se houve comprometimento.
  • Investigue por que o endereço não foi redirecionado quando o recurso foi encerrado.
  • 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 organização.

Limpar ponteiros DNS ou recuperar o DNS

Após a exclusão do recurso do 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, o reutilização do DNS será proibido EXCETO para assinaturas pertencentes ao locatário do Microsoft Entra da assinatura originalmente proprietária do DNS. Depois que a reserva expirar, o DNS será gratuito para ser reivindicado por qualquer assinatura. Ao fazer reservas de DNS, o cliente tem algum tempo para 1) limpar quaisquer associações/ponteiros para o referido DNS ou 2) solicitar o DNS no Azure. A recomendação seria excluir as entradas DNS indesejadas o mais rápido possível. O nome DNS que está sendo reservado pode ser derivado pela adoção do nome do serviço de nuvem para a zona DNS dessa nuvem.

• Público – cloudapp.net
• Mooncake – chinacloudapp.cn
• Fairfax – usgovcloudapp.net
• BlackForest – azurecloudapp.de

Por exemplo, um serviço hospedado em Público chamado "test" teria o DNS "test.cloudapp.net"

Exemplo: a assinatura 'A' e a assinatura 'B' são as únicas assinaturas pertencentes ao locatário do Microsoft Entra 'AB'. A assinatura 'A' contém um 'teste' do serviço de nuvem clássico 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, somente a assinatura “A” ou a assinatura “B” poderá declarar o nome DNS “test.cloudapp.net” criando um serviço de nuvem clássico chamado “test”. Nenhuma outra assinatura terá permissão para reivindicá-lo. Após o período de reserva, qualquer assinatura no Azure pode agora declarar “test.cloudapp.net”.

Próximas etapas

Para saber mais sobre os serviços relacionados e os recursos do Azure que você pode usar para se defender da tomada de controle do subdomínio, consulte as páginas a seguir.

• Habilitar o Microsoft Defender para Serviço de Aplicativo – para receber alertas quando forem detectadas entradas DNS pendentes

• Impedir registros DNS pendentes com o DNS do Azure

• Usar uma ID de verificação de domínio ao adicionar domínios personalizados no Serviço de Aplicativo do Azure

• Início Rápido: Execute a primeira consulta ao Resource Graph usando o Azure PowerShell