Evite registos DNS órfãos e a apropriação de subdomínios

Este artigo descreve a ameaça comum de segurança da tomada de subdomínio e as medidas que pode tomar para a mitigar.

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 eliminam 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. DESAPROVISIONAMENTO:

   1. O recurso do Azure é desprovisionado ou eliminado depois de deixar de ser 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. Agora você tem um registro DNS "pendurado".

   2. O subdomínio órfão, greatapp.contoso.com, está agora vulnerável e pode ser tomado ao ser atribuído a um recurso de outra subscrição do Azure.

3. TOMADA DE CONTROLO:

   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 enviado para o subdomínio greatapp.contoso.com é agora encaminhado para o recurso do ator malicioso, onde este 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 eliminado, trata-se de um registo "dangling DNS" e cria a possibilidade de apropriaçã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 controlo sobre o conteúdo do subdomínio: Má imprensa sobre a incapacidade da sua organização de proteger o seu conteúdo, danos à marca e perda de confiança.

• Colheita de cookies de visitantes desavisados: É comum aplicações web exporem cookies de sessão a subdomínios (*.contoso.com). Qualquer subdomínio pode acessá-los. Os intervenientes de ameaça podem usar a tomada de subdomínio para construir uma página com aspeto autêntico, enganar utilizadores desavisados para a visitarem e recolher os seus cookies (até cookies seguros). Um equívoco comum é pensar que os certificados SSL protegem o seu site e os cookies dos seus utilizadores contra uma tomada de controlo. 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: Agentes maliciosos frequentemente exploram subdomínios com aparência autêntica em campanhas de phishing. O risco estende-se tanto a websites maliciosos como a registos MX. Os registos MX poderiam permitir que agentes ameaçadores recebam emails dirigidos a subdomínios legítimos associados a marcas de confiança.

• Riscos adicionais: Sites maliciosos podem escalar para outros ataques clássicos como XSS, CSRF, CORS BYPASS e outros.

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-o a listar todos os domínios com um CNAME associado a um recurso Azure existente que criou nas suas 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.

Pré-requisitos

Execute a consulta como um usuário que tenha:

• Pelo menos o acesso de função Reader às subscrições do Azure.
• Leia o acesso ao Azure Resource Graph.

Se é Administrador Global do inquilino da sua organização, siga as orientações no Elevate Access para gerir todas as subscrições e grupos de gestão do Azure e assim aceder a todas as subscrições da sua organização.

Executar o script

Para mais informações sobre o script PowerShell, consulte Get-DanglingDnsRecords.ps1.

Remediar entradas DNS pendentes

Revise suas zonas DNS e identifique os registros CNAME que estão pendurados ou assumidos. Se encontrar subdomínios pendentes ou assumidos, remova os subdomínios vulneráveis e mitigue os riscos usando 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 encaminhar tráfego para recursos que controla, provisione mais recursos 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 alguma comprometimento e tome medidas de acordo com os procedimentos de resposta a incidentes da sua organização. Para dicas e boas práticas de investigação:

   Se a lógica da sua aplicação resultar em segredos, como credenciais OAuth, a serem enviados para subdomínios pendentes ou se informação sensível à privacidade for transmitida para esses subdomínios, esses dados podem ser expostos a terceiros.

5. Compreenda porque é que o registo CNAME não foi removido da sua zona DNS quando desprovisionou o recurso e tome medidas para garantir que os registos DNS são atualizados corretamente quando os recursos do Azure forem desprovisionados no futuro.

Evitar entradas DNS pendentes

Torne os processos que impedem entradas DNS pendentes e as consequentes aquisições de subdomínios uma parte crucial do seu programa de segurança.

As secções seguintes descrevem as funcionalidades do serviço Azure que podem ajudar a criar medidas preventivas. Estabeleça outros métodos para prevenir este problema através das melhores práticas da sua organização ou dos procedimentos operacionais padrã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 para a 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. Quando ativa este plano, recebe alertas de segurança se desativar um site de Serviço de Aplicações mas não remover o seu domínio personalizado do seu registo DNS.

A proteção contra DNS pendente do Microsoft Defender para a Cloud está disponível quer faça a gestão dos seus domínios através do DNS do Azure quer através de um registador de domínios externo, e aplica-se ao App Service, tanto no Windows como no Linux.

Para mais informações sobre esta funcionalidade e outros benefícios destes planos Microsoft Defender, consulte Introdução ao Microsoft Defender for App Service.

Usar registros de alias DNS do Azure

Os registos de alias do DNS do Azure podem evitar referências órfãs ao associar o ciclo de vida de um registo DNS ao de 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. O registo DNS alias já não faz referência ao recurso eliminado. Os registos alias têm limitações quanto ao que podem proteger. A lista limita-se atualmente a:

• Azure Front Door
• Perfis do Gestor de Tráfego
• Pontos finais da Rede de Entrega de Conteúdos (CDN) do Azure
• IPs Públicos

Apesar da oferta de serviços atualmente limitada, utilize registos de alias para se proteger contra a apropriação de subdomínios sempre que possível.

Para mais informações, consulte as capacidades dos registos de alias do DNS do Azure.

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

Quando criar entradas DNS para o Serviço de Aplicações do Azure, crie um asuid.{subdomain} registo TXT com o ID de verificação do domínio. Quando tal registo TXT existe, nenhuma outra subscrição do Azure pode validar o domínio personalizado ou assumi-lo.

Estes registos não impedem alguém de criar uma instância do Serviço de Aplicações 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 mal-intencionados não conseguem receber tráfego nem controlar o conteúdo.

Para mais informações, consulte Mapear um nome DNS personalizado existente para o Serviço de Aplicações do Azure.

Crie e automatize processos para mitigar a ameaça

Os programadores e equipas de operações devem executar processos de limpeza para evitar ameaças DNS pendentes. As seguintes práticas ajudam a sua organização a evitar esta 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.

    • Adicione bloqueios de eliminação a quaisquer 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ó funcionam quando combinadas com programas internos de educação.

• Criar procedimentos de deteção:

  • Reveja os seus registos DNS regularmente para garantir que os seus subdomínios estão todos mapeados para recursos do Azure que:

    • Existem: Consulte as suas zonas DNS à procura de recursos que apontem para subdomínios do Azure, como *.azurewebsites.net ou *.cloudapp.azure.com (ver a lista de referência dos domínios do Azure).
    • É proprietário: Confirme que é proprietário de todos os recursos para os quais os seus subdomínios DNS apontam.

  • Mantenha um catálogo de serviços dos seus pontos finais FQDN (nomes de domínio totalmente qualificados) do Azure e dos responsáveis pelas aplicações. Use o Azure Resource Graph, o portal Azure ou outro processo de inventário de ativos para exportar regularmente a informação do endpoint FQDN para recursos a que possa aceder. Se tiver acesso a todas as subscrições no seu locatário, inclua todas as subscrições no inventário. Se não o fizeres, documenta quais as subscrições que o inventário cobre.

• Crie procedimentos para remediação:

  • Quando a sua equipa encontrar entradas DNS pendentes, investigue se ocorreu alguma 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 os ponteiros DNS ou recuperar o DNS

Quando elimina um recurso clássico de serviço cloud, o Azure reserva o nome DNS correspondente de acordo com as políticas do DNS do Azure. Durante o período de reserva, apenas as subscrições que pertençam ao inquilino Microsoft Entra da subscrição que originalmente detinha o nome DNS podem reutilizá-lo. Depois de a reserva expirar, qualquer subscrição do Azure pode reivindicar o nome DNS. As reservas DNS dão-te tempo para limpar associações ou ponteiros para o nome DNS, ou para recuperar o nome DNS no Azure. Apague entradas DNS indesejadas o mais rapidamente possível. Pode obter o nome DNS reservado acrescentando o nome do serviço de nuvem à zona DNS dessa nuvem.

• Público: cloudapp.net
• Bolo da Lua: chinacloudapp.cn
• Fairfax: usgovcloudapp.net
• BlackForest: azurecloudapp.de

Por exemplo, um serviço alojado em Public com o nome test tem o nome DNS test.cloudapp.net.

Exemplo: As subscrições A e B são as únicas subscrições que pertencem ao tenant do Microsoft Entra AB. A subscrição A contém um serviço de nuvem clássico chamado test com o nome DNS test.cloudapp.net. Quando elimina o serviço cloud, o Azure reserva o nome test.cloudapp.netDNS . Durante o período de reserva, apenas a subscrição A ou a subscrição B pode reservar o nome DNS test.cloudapp.net ao criar um serviço cloud clássico com o nome test. Nenhuma outra subscrição pode reivindicá-la. Após o período de reserva, qualquer subscrição do Azure pode reclamar 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.

• Ativar o Microsoft Defender para Serviços de Aplicações - Receber alertas quando forem detetadas entradas DNS pendentes.

• Evite registos DNS órfãos 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

• Guia de início rápido: execute sua primeira consulta do Gráfico de Recursos usando o Azure PowerShell