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

# Tomada de Domínio/Subdomínio

<details>

<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>

* Você trabalha em uma **empresa de segurança cibernética**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud).

</details>

![](<../.gitbook/assets/image (9) (1) (2).png>)

\
Use [**Trickest**](https://trickest.io/) 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:

* [https://github.com/EdOverflow/can-i-take-over-xyz](https://github.com/EdOverflow/can-i-take-over-xyz)
* [https://github.com/blacklanternsecurity/bbot](https://github.com/blacklanternsecurity/bbot)
* [https://github.com/punk-security/dnsReaper](https://github.com/punk-security/dnsReaper)
* [https://github.com/haccer/subjack](https://github.com/haccer/subjack)
* [https://github.com/anshumanbh/tko-sub](https://github.com/anshumanbh/tko-subs)
* [https://github.com/ArifulProtik/sub-domain-take
```
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](https://hackerone.com/reports/172137) 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](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 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](https://www.w3.org/TR/2016/REC-SRI-20160623/) 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 <a href="#emails" id="emails"></a>

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