hacktricks/pentesting-web/domain-subdomain-takeover.md

Domain/Subdomain takeover

Aprenda hacking no AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks:

• Se você quer ver sua empresa anunciada no HackTricks ou baixar o HackTricks em PDF, confira os PLANOS DE ASSINATURA!
• Adquira o material oficial PEASS & HackTricks
• Descubra A Família PEASS, nossa coleção de NFTs exclusivos
• Junte-se ao grupo 💬 Discord ou ao grupo telegram ou siga-me no Twitter 🐦 @carlospolopm.
• Compartilhe suas técnicas de hacking enviando PRs para os repositórios github do HackTricks e HackTricks Cloud.

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" %}

Domain takeover

Se você descobrir algum domínio (domain.tld) que está sendo usado por algum serviço dentro do escopo mas a empresa perdeu a propriedade dele, você pode tentar registrar (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 é certamente uma vulnerabilidade.

Subdomain takeover

Um subdomínio da empresa está apontando para um serviço de terceiros com um nome não registrado. Se você puder 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:

• https://github.com/EdOverflow/can-i-take-over-xyz
• https://github.com/blacklanternsecurity/bbot
• https://github.com/punk-security/dnsReaper
• https://github.com/haccer/subjack
• https://github.com/anshumanbh/tko-sub
• https://github.com/ArifulProtik/sub-domain-takeover
• https://github.com/SaadAhmedx/Subdomain-Takeover
• https://github.com/Ice3man543/SubOver
• https://github.com/m4ll0k/takeover
• https://github.com/antichown/subdomain-takeover
• https://github.com/musana/mx-takeover

Varredura de Subdomínios Sequestráveis com BBOT:

Verificações de takeover de subdomínio estão incluídas na enumeração padrão de subdomínios do BBOT. Assinaturas são retiradas diretamente de https://github.com/EdOverflow/can-i-take-over-xyz.

bbot -t evilcorp.com -f subdomain-enum

Geração de Subdomain Takeover via DNS Wildcard

Quando o DNS wildcard é utilizado em um domínio, qualquer subdomínio solicitado desse domínio que não tenha um endereço explicitamente diferente será resolvido para a mesma informação. Isso pode ser um endereço IP A, um CNAME...

Por exemplo, se *.testing.com está com wildcard para 1.1.1.1. Então, not-existent.testing.com estará apontando para 1.1.1.1.

No entanto, se em vez de apontar para um endereço IP, o sysadmin apontá-lo para um serviço de terceiros via CNAME, como um subdomínio do github por exemplo (sohomdatta1.github.io). Um atacante poderia criar sua própria página de terceiros (no Github neste caso) e dizer que something.testing.com está apontando para lá. Porque, o CNAME wildcard concordará e o atacante será capaz de gerar subdomínios arbitrários para o domínio da vítima apontando para suas páginas.

Você pode encontrar um exemplo desta vulnerabilidade no write-up do CTF: https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api

Explorando um Subdomain Takeover

Esta informação foi copiada de https://0xpatrik.com/subdomain-takeover/

Recentemente, eu escrevi sobre os conceitos básicos de subdomain takeover. Embora o conceito agora seja geralmente bem compreendido, notei que as pessoas geralmente têm dificuldade em entender os riscos que o subdomain takeover traz à mesa. Neste post, eu exploro em profundidade e cubro os riscos mais notáveis de subdomain takeover do meu ponto de vista.

Nota: Alguns riscos são mitigados implicitamente pelo provedor de nuvem. Por exemplo, quando o subdomain takeover é possível no Amazon CloudFront, não há como configurar registros TXT para contornar as verificações de SPF. O post, portanto, visa fornecer riscos sobre o subdomain takeover geral. No entanto, a maioria destes se aplica aos provedores de nuvem também.

Transparência Para um Navegador

Para começar, vamos olhar para a resolução de DNS onde o CNAME está envolvido:

Note que a etapa #7 solicita sub.example.com em vez de anotherdomain.com. Isso ocorre porque o navegador da web não está ciente de que anotherdomain.com sequer existe. Mesmo que o registro CNAME seja usado, a barra de URL no navegador ainda contém sub.example.com. Esta é a transparência para o navegador. Se você pensar sobre isso, o navegador coloca toda a confiança no resolvedor de DNS para fornecer informações precisas sobre o domínio. Simplificando, subdomain takeover é um spoofing de DNS para um domínio particular em toda a Internet. Por quê? Porque qualquer navegador que execute a resolução de DNS no domínio afetado recebe um registro A definido por um atacante. O navegador então exibe alegremente o que quer que seja recebido deste servidor (pensando que é legítimo).

Um domínio como esse faz um cenário perfeito para phishing. Atacantes frequentemente usam typosquatting ou os chamados Doppelganger domains para imitar o domínio/site legítimo para fins de phishing. Depois que um atacante assume o controle de um nome de domínio legítimo, é quase impossível para um usuário comum dizer se o conteúdo no domínio é fornecido por uma parte legítima ou um atacante. Vamos tomar como exemplo um banco aleatório. Se um dos subdomínios do banco for vulnerável a subdomain takeover, um atacante pode criar um formulário HTML que imita o formulário de login do sistema de internet banking do banco. Então, um atacante pode executar uma campanha de spear phishing ou phishing em massa pedindo aos usuários para fazer login e mudar suas senhas. Neste estágio, as senhas são capturadas por um atacante que está no controle do domínio em questão. O URL fornecido no e-mail de phishing é um subdomínio legítimo de um banco. Portanto, os usuários não estão cientes de algo malicioso acontecendo. Filtros de spam e outras medidas de segurança também são menos propensos a acionar o e-mail como spam ou malicioso porque ele contém nomes de domínio com maior confiança.

De fato, o próprio nome de domínio desempenha um papel significativo em uma campanha bem-sucedida. Ter um subdomínio de 5º nível vulnerável a subdomain takeover é muito menos "legítimo" do que ter um subdomínio de 2º nível com algum nome de subdomínio amigável. Eu vi várias instâncias de subdomínios perfeitos para phishing, incluindo:

• purchases.SOMETHING.com
• www.SOMETHING.com
• online.SOMETHING.com
• shop.SOMETHING.com

Todos eles vulneráveis a subdomain takeover. Todos eles eram grandes marcas. Falando sobre phishing perfeito?

No entanto, campanhas recentes de phishing hospedam conteúdo em domínios com nomes de domínio longos que incluem o nome da marca (veja exemplo da Apple). Tendo um certificado SSL válido (mais sobre isso abaixo), palavra-chave no nome do domínio e site que imita o site da marca alvo, as pessoas tendem a cair nesses ataques. Pense nas chances com um subdomínio legítimo desta marca.

Use Trickest para construir e automatizar workflows facilmente, alimentados pelas 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" %}

Certificados SSL

O ataque acima pode ser aprimorado pela geração de um certificado SSL válido. Autoridades certificadoras como Let's Encrypt permitem a verificação automática da propriedade do domínio pela verificação de conteúdo:

Ou seja, se houver um conteúdo específico colocado em um caminho de URL específico, Let's Encrypt aprovará a emissão de um certificado para um dado domínio. Como um atacante tem controle total sobre o conteúdo do domínio que é vulnerável a subdomain takeover, essa verificação pode ser feita em questão de minutos. Portanto, os atacantes também são capazes de gerar um certificado SSL para tal domínio, o que apenas diminui a suspeita de um ataque de phishing.

Roubo de Cookies

Isso anda de mãos dadas com a transparência do navegador, mas tem consequências diferentes. O navegador da web implementa muitas políticas de segurança para impedir que sites maliciosos causem danos. Isso inclui coisas como Política de mesma origem. Uma das principais responsabilidades de segurança de um navegador é proteger os cookies salvos. Por quê? Enquanto o HTTP é um protocolo sem estado, os cookies são usados para rastrear sessões. Para conveniência, os usuários frequentemente salvam cookies por um período prolongado para evitar fazer login todas as vezes. Esses cookies, portanto, agem como um token de login que é apresentado ao servidor web e o usuário é identificado. Ataques como Sequestro de sessão naturalmente evoluíram desse conceito.

O navegador automaticamente apresenta cookies armazenados com cada solicitação ao domínio que os emitiu. Há uma exceção a isso, tal que os cookies podem ser compartilhados entre subdomínios (leia aqui, também observe a seção 8.7). Isso geralmente acontece quando o site usa um sistema de Single sign-on baseado em cookies (SSO). Usando SSO, um usuário pode fazer login usando um subdomínio e compartilhar o mesmo token de sessão em uma ampla gama de subdomínios. A sintaxe para definir um cookie regular é a seguinte:

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

Se este cookie for emitido por um servidor web residente em example.com, apenas este servidor poderá 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 _subdomain.example.com_. Esse comportamento cria a possibilidade de ataques de alta gravidade usando subdomain takeover. Suponha que um domínio específico esteja usando cookies de sessão para domínio curinga. Se houver um subdomínio vulnerável a subdomain takeover, a única coisa necessária para coletar o token de sessão do usuário é induzi-lo a visitar o subdomínio vulnerável. O cookie de sessão é automaticamente enviado com a solicitação HTTP.

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

* **HttpOnly cookie** — Cookies podem, por padrão, ser acessados por código Javascript executado no contexto do site que criou os cookies. Javascript pode ler, atualizar e deletar os cookies. A flag _HttpOnly_ do cookie (definida pelo servidor web) indica que o cookie específico não pode ser acessado por código Javascript. A única maneira de obtê-lo é através dos cabeçalhos de solicitação e resposta HTTP.
* **Secure cookie** — Quando o cookie tem a flag _Secure_ definida pelo servidor web, ele só pode ser comunicado de volta ao servidor web se HTTPS for usado.

Se o domínio for vulnerável a subdomain takeover, um atacante pode coletar cookies emitidos por esse domínio no passado apenas induzindo usuários a 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 tomado.

O roubo de cookies usando takeover foi explicado no [relatório](https://hackerone.com/reports/172137) de bug bounty por Arne Swinnen. O relatório explica o problema com um dos subdomínios da _Ubiquiti Networks_ (_ping.ubnt.com_). Este subdomínio estava vulnerável a subdomain takeover, apontando para uma distribuição AWS CloudFront não reivindicada. Como a Ubiquiti Networks está usando SSO com cookies de sessão de domínio curinga, todos os usuários que visitassem _ping.ubnt.com_ poderiam ter seus cookies de sessão roubados. Embora este domínio aponte para AWS CloudFront, as configurações de distribuição do CloudFront permitem registrar 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 AWS CloudFront. Em 2017, Arne também demonstrou um vetor de ataque semelhante contra [o sistema SSO da Uber](https://www.arneswinnen.net/2017/06/authentication-bypass-on-ubers-sso-via-subdomain-takeover/).

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 tais scripts em um site legítimo pode levar a consequências catastróficas. Suponha que o site esteja usando código Javascript de um 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 comuns. Se o código externo não estiver fazendo nada importante (por exemplo, é usado apenas para rastreamento), tal provedor externo pode permanecer no site por um período prolongado. Um atacante pode assumir esse domínio expirado, combinar o caminho da URL do código Javascript fornecido e, assim, ganhar controle sobre cada visitante que visita o site original.

No entanto, há uma maneira de proteger a integridade dos arquivos Javascript no navegador. _Subresource Integrity_ [foi proposto](https://www.w3.org/TR/2016/REC-SRI-20160623/) como um mecanismo para incluir hash criptográfico como um atributo _integrity_ à tag _script_ em HTML5. Quando o hash criptográfico fornecido não corresponde ao arquivo baixado, o navegador se recusa a executá-lo.

### E-mails <a href="#emails" id="emails"></a>

Quando o subdomain takeover de CNAME é possível, os registros MX também podem ser configurados por um atacante para um servidor web arbitrário. 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 atacante e a vítima é necessária. Os atacantes geralmente falsificam o cabeçalho `Return-Path` para receber uma resposta ao e-mail. Com os 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 permitidos para envio de e-mails para o domínio. O SPF armazena a configuração em registros DNS TXT. Com subdomain takeover, os registros TXT também estão sob controle do atacante - as verificações de SPF podem ser facilmente aprovadas.

_Como notei no início, essas táticas geralmente não funcionam com a maioria dos provedores de nuvem, pois você não tem controle direto sobre a zona DNS._

### Riscos de Ordem Superior <a href="#higherorderrisks" id="higherorderrisks"></a>

O conceito de subdomain takeover pode ser naturalmente estendido para registros NS: Se o domínio base de pelo menos um registro NS estiver disponível para registro, o nome de domínio de origem está vulnerável a subdomain takeover.

Um dos problemas no subdomain takeover usando registro NS é que o nome de domínio de origem geralmente tem vários registros NS. Vários registros NS são usados para redundância e balanceamento de carga. O servidor de nomes é escolhido aleatoriamente antes da resolução DNS. Suponha que o domínio _sub.example.com_ tenha dois registros NS: _ns.vulnerable.com_ e _ns.nonvulnerable.com_. Se um atacante assumir o _ns.vulnerable.com_, a situação do ponto de vista do usuário que consulta _sub.example.com_ é a seguinte:

1. Como existem dois servidores de nomes, um é escolhido aleatoriamente. Isso significa que a probabilidade de consultar o servidor de nomes controlado por um atacante é de 50%.
2. Se o resolvedor DNS do usuário escolher _ns.nonvulnerable.com_ (servidor de nomes legítimo), o resultado correto é retornado e provavelmente sendo armazenado em cache em algum lugar entre 6 e 24 horas.
3. Se o resolvedor DNS do usuário escolher _ns.vulnerable.com_ (servidor de nomes de propriedade de um atacante), um atacante pode fornecer um resultado falso que também será armazenado em cache. Como um atacante está no controle do servidor de nomes, ela pode definir o TTL para este resultado específico ser, por exemplo, uma semana.

O processo acima é repetido toda vez que a entrada de cache expira. Quando um atacante opta por usar TTL com valor alto, o resultado falso permanecerá no cache DNS por esse período. Durante esse tempo, todas as solicitações para _sub.example.com_ usarão o resultado DNS falso armazenado em cache por um atacante. Essa ideia é ainda amplificada quando resolvedores DNS públicos (por exemplo, Google DNS) são usados. Nesse caso, os resolvedores públicos provavelmente armazenarão os resultados falsos, o que significa que todos os usuários que usam o mesmo resolvedor DNS obterão resultados falsos até que o cache seja revogado.

Além do controle sobre o nome de domínio de origem, o controle sobre todos os domínios de nível superior do nome de domínio de origem também é obtido. Isso porque possuir um nome de domínio canônico de registro NS significa possuir a zona DNS completa do nome de domínio de origem.

Em 2016, Matthew Bryant [demonstrou](https://thehackerblog.com/the-international-incident-gaining-control-of-a-int-domain-name-with-dns-trickery/index.html) um subdomain takeover usando registro NS em _maris.int_. O domínio de nível superior .INT é um TLD especial, e apenas um punhado de domínios o utilizam. Bryant mostrou que, embora o registro de tais nomes de domínio seja aprovado exclusivamente pela IANA, os servidores de nomes podem ser configurados para domínios arbitrários. Como um dos servidores de nomes de _maris.int_ estava disponível para registro (_cobalt.aliis.be_), o subdomain takeover foi possível até mesmo neste TLD restrito.

Matthew também [demonstrou](https://thehackerblog.com/the-io-error-taking-control-of-all-io-domains-with-a-targeted-registration/index.html) um ataque de gravidade ainda maior, onde ele conseguiu assumir o controle sobre o servidor de nomes do domínio de nível superior .IO. Controlar .IO significa controlar as respostas para todos os nomes de domínio .IO. Neste caso, um dos servidores de nomes .IO era _ns-a1.io_, que estava disponível para registro. Ao registrar _ns-a1.io_, Bryant conseguiu receber consultas DNS e controlar suas respostas para todos os domínios .IO.

### Mitigação <a href="#mitigation" id="mitigation"></a>

As estratégias de mitigação para nomes de domínio já vulneráveis a subdomain takeover são bastante diretas:

* **Remover o registro DNS afetado** — A solução mais simples é remover o registro afetado da zona DNS. Este passo é geralmente usado se a organização conclui que o nome de domínio de origem afetado não é mais necessário.
* **Reivindicar o nome de domínio** — Isso significa registrar o recurso em um provedor de nuvem específico ou, no caso de um domínio regular da Internet, recomprar o domínio expirado.

Para prevenir subdomain takeover no futuro, as organizações devem mudar o processo de criação e destruição de recursos em sua infraestrutura. No caso da criação de recursos, a criação do registro DNS deve ser a _última etapa_ desse processo. Essa condição impede que o registro DNS aponte para um domínio inexistente em qualquer momento. Para a destruição de recursos, o oposto é válido: o registro DNS precisa ser removido como a _primeira etapa_ nesse processo. Ferramentas como [aquatone](https://github.com/michenriksen/aquatone) incluem verificações para subdomain takeover. As verificações devem ser realizadas periodicamente por uma equipe de segurança de uma organização para verificar que não existem domínios vulneráveis. Processos para coleta central de nomes de domínio expostos são frequentemente ineficientes dentro das organizações (devido a equipes globais, etc.) e o monitoramento externo geralmente é a melhor opção.

A estratégia de mitigação para provedores de nuvem também deve ser considerada. Os serviços de nuvem não estão verificando a propriedade do domínio. A razão por trás disso é principalmente a conveniência. O provedor de nuvem não está introduzindo nenhuma vulnerabilidade ao não verificar a propriedade de um nome de domínio de origem. Portanto, cabe ao usuário monitorar seus registros DNS. Outra razão é que, quando um recurso de nuvem é removido, o usuário geralmente não é mais um cliente desse serviço. A pergunta que os provedores de nuvem então se fazem é: Por que deveríamos nos importar?

Provedores como [GitLab](https://about.gitlab.com/2018/02/05/gitlab-pages-custom-domain-validation/) perceberam que subdomain takeover é um problema e implementaram um mecanismo de verificação de domínio.

_Algumas partes deste post são trechos da minha_ [_Tese de Mestrado_](https://is.muni.cz/th/byrdn/Thesis.pdf).

Até a próxima!

[Patrik](https://twitter.com/0xpatrik)

<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>

\
Use [**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks) para construir e **automatizar fluxos de trabalho** facilmente, alimentados pelas **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" %}

<details>

<summary><strong>Aprenda hacking AWS do zero ao herói com</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Outras maneiras de apoiar o HackTricks:

* Se você quiser ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**merchandising oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Junte-se ao grupo** 💬 [**Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga**-me no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Compartilhe suas dicas de hacking enviando PRs para os repositórios github do** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).

</details>