hacktricks/pentesting-web/domain-subdomain-takeover.md
2023-06-06 18:56:34 +00:00

8.3 KiB

Tomada de Domínio/Subdomínio

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥


Use Trickest para construir e automatizar fluxos de trabalho com as ferramentas comunitárias mais avançadas do mundo.
Obtenha acesso hoje:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Tomada de Domínio

Se você descobrir algum domínio (domínio.tld) que está sendo usado por algum serviço dentro do escopo mas a empresa perdeu a propriedade dele, você pode tentar registrá-lo (se for barato o suficiente) e informar a empresa. Se este domínio estiver recebendo alguma informação sensível como um cookie de sessão via parâmetro GET ou no cabeçalho Referer, isso é com certeza uma vulnerabilidade.

Tomada de Subdomínio

Um subdomínio da empresa está apontando para um serviço de terceiros com um nome não registrado. Se você pode criar uma conta neste serviço de terceiros e registrar o nome em uso, você pode realizar a tomada de subdomínio.

Existem várias ferramentas com dicionários para verificar possíveis tomadas:

HTTP/1.1 200 OK
Set-Cookie: name=value

Se este cookie é emitido pelo servidor web que reside em example.com, apenas este servidor pode acessar este cookie posteriormente. No entanto, o cookie pode ser emitido para um domínio curinga (pelos motivos explicados acima) da seguinte maneira:

HTTP/1.1 200 OK
Set-Cookie: name=value; domain=example.com

O cookie será incluído em solicitações HTTP para example.com, mas também para qualquer outro subdomínio, como subdomínio.example.com. Esse comportamento cria uma possibilidade de ataques de alta gravidade usando a apropriação de subdomínio. Suponha que um domínio específico esteja usando cookies de sessão para domínio curinga. Se houver um subdomínio vulnerável à apropriação de subdomínio, a única coisa para obter o token de sessão do usuário é enganá-lo para visitar o subdomínio vulnerável. O cookie de sessão é enviado automaticamente com a solicitação HTTP.

O navegador também implementa mecanismos de segurança adicionais para cookies:

  • Cookie HttpOnly - Os cookies podem ser acessados por padrão pelo código Javascript em execução no contexto do site que criou os cookies. O Javascript pode ler, atualizar e excluir os cookies. A flag HttpOnly (definida pelo servidor web) indica que o cookie específico não pode ser acessado pelo código Javascript. A única maneira de obtê-lo é por meio de cabeçalhos de solicitação e resposta HTTP.
  • Cookie seguro - Quando o cookie tem a flag Secure definida pelo servidor web, ele pode ser comunicado de volta ao servidor web somente se o HTTPS for usado.

Se o domínio for vulnerável à apropriação de subdomínio, um invasor pode coletar cookies emitidos por esse domínio no passado apenas enganando os usuários para visitar esse site. As flags HttpOnly e Secure não ajudam, pois o cookie não está sendo acessado usando Javascript e o certificado SSL pode ser facilmente gerado para o domínio apropriado.

O roubo de cookies usando a apropriação foi explicado em um relatório de recompensa por bug report por Arne Swinnen. O relatório explica o problema com um dos subdomínios da Ubiquiti Networks (ping.ubnt.com). Este subdomínio era vulnerável à apropriação de subdomínio, apontando para uma distribuição não reclamada da AWS CloudFront. Como a Ubiquiti Networks está usando SSO com cookies de sessão curinga, todos os usuários que visitam ping.ubnt.com podem ter seus cookies de sessão roubados. Mesmo que este domínio esteja apontando para a AWS CloudFront, as configurações de distribuição do CloudFront permitem o registro de cookies com cada solicitação. Portanto, o cenário de extração de cookies de sessão é totalmente possível, mesmo com subdomínios apontando para a AWS CloudFront. Em 2017, Arne também demonstrou um vetor de ataque semelhante contra o sistema SSO da Uber.

O comportamento explicado acima não se limita a cookies. Como os scripts Javascript têm controle total sobre os sites em que são executados, ter a capacidade de substituir esses scripts no site legítimo pode levar a consequências catastróficas. Suponha que o site esteja usando código Javascript do provedor externo usando a tag script e o atributo src. Quando o domínio do provedor externo expira, o navegador falha silenciosamente, ou seja, não aciona nenhum alerta visível para usuários regulares. Se o código externo não estiver fazendo nada importante (por exemplo, é usado apenas para rastreamento), esse provedor externo pode permanecer no site por um período prolongado. Um invasor pode assumir esse domínio expirado, corresponder ao caminho de URL do código Javascript fornecido e, assim, obter o controle sobre cada visitante que visita o site original.

No entanto, há uma maneira de proteger a integridade dos arquivos Javascript em um navegador. Subresource Integrity foi proposto como um mecanismo para incluir o hash criptográfico como um atributo integrity na tag script em HTML5. Quando o hash criptográfico fornecido não corresponde ao arquivo de download, o navegador se recusa a executá-lo.

E-mails

Quando a apropriação de subdomínio CNAME é possível, registros MX podem ser configurados por um invasor para um servidor web arbitrário também. Isso permite receber e-mails para um subdomínio legítimo de alguma marca - particularmente útil novamente em ataques de phishing (spear) onde a interação entre um invasor e a vítima é necessária. Os invasores geralmente falsificam o cabeçalho Return-Path para receber uma resposta ao e-mail. Com registros MX corretos, esse problema é contornado.

Por outro lado, também é possível enviar e-mails. Embora seja trivial falsificar o cabeçalho From para incluir qualquer endereço de e-mail, os filtros SPF geralmente verificam o cabeçalho Return-Path e os hosts de envio de e-mail permitidos para o domínio. SPF armazena a configuração