O nome que aponta para lugar nenhum: takeover de CNAME dangling
O desafio
O Kestrel Bank mantém uma zona DNS organizada, e esse é o problema. Um dos seus subdomínios ainda tem um CNAME apontando para um bucket na nuvem que o time de marketing apagou quando uma campanha terminou. O nome resolve, o destino não existe, e qualquer pessoa pode ir até esse provedor de nuvem e reivindicar o nome vago. Quem fizer isso passa a servir conteúdo a partir de um endereço legítimo de kestrelbank.example. Cruze os registros e indique o subdomínio que pode ser tomado.
O que você vai aprender
- Explicar como um CNAME apontando para um recurso desprovisionado se torna assumível
- Reconhecer a resposta de "não existe" de um provedor como assinatura de takeover
- Cruzar uma exportação de DNS com probes ativos para encontrar o registro dangling
- Descrever o impacto de servir conteúdo a partir de um subdomínio real
- Indicar a ordem segura de desativação de DNS e recursos em nuvem
Habilidades testadas
Pré-requisitos
- O que é um registro CNAME
- A ideia de buckets na nuvem / recursos hospedados
Como funciona
Um subdomain takeover é possível quando um registro DNS aponta para um recurso de terceiros que foi excluído, mas cujo nome qualquer pessoa pode recriar. O registro continua resolvendo; aquilo para onde ele resolve é um espaço vazio esperando para ser reivindicado.
O sinal está na resposta do alvo. Um alvo ativo responde normalmente; um alvo assumível retorna o erro de "não existe" do provedor, como NoSuchBucket. Isso significa que o recurso foi desmontado enquanto o CNAME que apontava para ele foi deixado para trás.
Ao reivindicar o nome, um atacante pode servir conteúdo a partir de um subdomínio genuíno da vítima, o que carrega confiança real: cookies com escopo no domínio pai, familiaridade dos clientes e a possibilidade de obter um certificado válido.
Erros comuns
- Escolher um subdomínio ativo. status, docs e login apontam para alvos que respondem normalmente.
- Culpar o bucket excluído. O bucket ter sumido é normal; o CNAME que sobrou é a vulnerabilidade.
- Responder com o host de destino. O nome passível de takeover é o subdomínio da Kestrel, não o alvo na nuvem para onde ele aponta.
- Ignorar o probe. Sem verificar a resposta de cada alvo, não dá para distinguir o registro dangling dos saudáveis.
Como se proteger
Amarre o ciclo de vida do DNS ao ciclo de vida do recurso.
- Remova ou reaponte um registro DNS no momento em que o recurso por trás dele for desativado. Exclua o registro antes do recurso, ou mantenha o nome reservado.
- Adote um checklist de desmontagem para que a limpeza do DNS nunca seja a etapa deixada em aberto.
- Escaneie continuamente suas zonas em busca de CNAMEs cujos alvos retornem assinaturas conhecidas de takeover, em todos os provedores que você usa.