<summary><strong>Aprenda hacking no AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se você quer ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**material oficial 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 [**telegram**](https://t.me/peass) ou **siga-me** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Compartilhe suas técnicas 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).
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir e **automatizar fluxos de trabalho** com as ferramentas comunitárias **mais avançadas** do mundo.\
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**.
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.
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](https://github.com/EdOverflow/can-i-take-over-xyz).
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...
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](https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api)
Recentemente, eu [escrevi](https://0xpatrik.com/subdomain-takeover-basics/) 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._
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_](https://en.wikipedia.org/wiki/Typosquatting) ou os chamados [_Doppelganger domains_](https://en.wikipedia.org/wiki/Doppelg%C3%A4nger) 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:
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](https://www.phishtank.com/target\_search.php?target\_id=183\&valid=y\&active=All\&Search=Search)). 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**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir e **automatizar workflows** facilmente, alimentados pelas **ferramentas comunitárias mais avançadas** do mundo.\
O ataque acima pode ser aprimorado pela geração de um certificado SSL válido. Autoridades certificadoras como [_Let's Encrypt_](https://letsencrypt.org/) 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.
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](https://en.wikipedia.org/wiki/Same-origin\_policy). 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_](https://en.wikipedia.org/wiki/Session\_hijacking) 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](https://tools.ietf.org/html/rfc6265#section-8.6), também observe a seção 8.7). Isso geralmente acontece quando o site usa um sistema de [Single sign-on](https://en.wikipedia.org/wiki/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:
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:
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.
* **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.
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._
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.
* **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.
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.\
<summary><strong>Aprenda hacking AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* 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).
