Translated ['src/pentesting-web/domain-subdomain-takeover.md', 'src/pent

2025-10-10 18:36:50 +00:00 · 2025-02-04 18:48:56 +00:00 · 2025-02-04 18:48:56 +00:00 · ea260c9c49
commit ea260c9c49
parent 570839fc97
2 changed files with 85 additions and 42 deletions
--- a/src/pentesting-web/domain-subdomain-takeover.md
+++ b/src/pentesting-web/domain-subdomain-takeover.md
@ -1,17 +1,17 @@
-# Tomada de domínio/subdomínio
+# Domain/Subdomain takeover

 {{#include ../banners/hacktricks-training.md}}


-## Tomada de domínio
+## 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 **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 **GET** parâmetro ou no cabeçalho **Referer**, isso é com certeza uma **vulnerabilidade**.

-### Tomada de subdomínio
+### Subdomain takeover

-Um subdomínio da empresa está apontando para um **serviço de terceiros com um nome não registrado**. Se você conseguir **criar** uma **conta** neste **serviço de terceiros** e **registrar** o **nome** que está em uso, você pode realizar a 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ê conseguir **criar** uma **conta** neste **serviço de terceiros** e **registrar** o **nome** que está em uso, você pode realizar o takeover do subdomínio.

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

 - [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)
@ -27,55 +27,72 @@ Existem várias ferramentas com dicionários para verificar possíveis tomadas:
 - [https://github.com/Stratus-Security/Subdominator](https://github.com/Stratus-Security/Subdominator)
 - [https://github.com/NImaism/takeit](https://github.com/NImaism/takeit)

-### Geração de Tomada de Subdomínio via DNS Wildcard
+### Subdomain Takeover Generation via DNS Wildcard

 Quando um wildcard DNS é usado em um domínio, qualquer subdomínio solicitado desse domínio que não tenha um endereço diferente explicitamente será **resolvido para as mesmas informações**. Isso pode ser um endereço IP A, um CNAME...

-Por exemplo, se `*.testing.com` estiver wildcard para `1.1.1.1`. Então, `not-existent.testing.com` estará apontando para `1.1.1.1`.
+Por exemplo, se `*.testing.com` está wildcarded 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 administrador do sistema apontá-lo para um **serviço de terceiros via CNAME**, como um subdomínio do G**ithub** 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á que o atacante poderá **gerar subdomínios arbitrários para o domínio da vítima apontando para suas páginas**.
+No entanto, se em vez de apontar para um endereço IP, o sysadmin apontar para um **serviço de terceiros via CNAME**, como um subdomínio do G**ithub** 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á que o atacante poderá **gerar subdomínios arbitrários para o domínio da vítima apontando para suas páginas**.

 Você pode encontrar um exemplo dessa 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)

-## Explorando uma tomada de subdomínio
+## Exploiting a subdomain takeover

-A tomada de subdomínio é essencialmente um spoofing de DNS para um domínio específico na internet, permitindo que atacantes definam registros A para um domínio, levando navegadores a exibir conteúdo do servidor do atacante. Essa **transparência** nos navegadores torna os domínios propensos a phishing. Os atacantes podem empregar [_typosquatting_](https://en.wikipedia.org/wiki/Typosquatting) ou [_domínios Doppelganger_](https://en.wikipedia.org/wiki/Doppelg%C3%A4nger) para esse propósito. Especialmente vulneráveis são os domínios onde a URL em um e-mail de phishing parece legítima, enganando os usuários e evitando filtros de spam devido à confiança inerente do domínio.
+O takeover de subdomínio é essencialmente um spoofing de DNS para um domínio específico na internet, permitindo que atacantes definam registros A para um domínio, levando os navegadores a exibir conteúdo do servidor do atacante. Essa **transparência** nos navegadores torna os domínios propensos a phishing. Os atacantes podem empregar [_typosquatting_](https://en.wikipedia.org/wiki/Typosquatting) ou [_Doppelganger domains_](https://en.wikipedia.org/wiki/Doppelg%C3%A4nger) para esse propósito. Especialmente vulneráveis são os domínios onde a URL em um e-mail de phishing parece legítima, enganando os usuários e evitando filtros de spam devido à confiança inerente do domínio.

 Verifique este [post para mais detalhes](https://0xpatrik.com/subdomain-takeover/)

-### **Certificados SSL**
+### **SSL Certificates**

 Certificados SSL, se gerados por atacantes via serviços como [_Let's Encrypt_](https://letsencrypt.org/), aumentam a legitimidade desses domínios falsos, tornando os ataques de phishing mais convincentes.

-### **Segurança de Cookies e Transparência do Navegador**
+### **Cookie Security and Browser Transparency**

-A transparência do navegador também se estende à segurança dos cookies, regida por políticas como a [Same-origin policy](https://en.wikipedia.org/wiki/Same-origin_policy). Cookies, frequentemente usados para gerenciar sessões e armazenar tokens de login, podem ser explorados através da tomada de subdomínio. Os atacantes podem **coletar cookies de sessão** simplesmente direcionando os usuários para um subdomínio comprometido, colocando em risco os dados e a privacidade dos usuários.
+A transparência do navegador também se estende à segurança dos cookies, regida por políticas como a [Same-origin policy](https://en.wikipedia.org/wiki/Same-origin_policy). Cookies, frequentemente usados para gerenciar sessões e armazenar tokens de login, podem ser explorados através do takeover de subdomínio. Os atacantes podem **coletar cookies de sessão** simplesmente direcionando os usuários para um subdomínio comprometido, colocando em risco os dados e a privacidade dos usuários.

-### **E-mails e Tomada de Subdomínio**
+### CORS Bypass

-Outro aspecto da tomada de subdomínio envolve serviços de e-mail. Os atacantes podem manipular **registros MX** para receber ou enviar e-mails de um subdomínio legítimo, aumentando a eficácia dos ataques de phishing.
+Pode ser possível que cada subdomínio tenha permissão para acessar recursos CORS do domínio principal ou de outros subdomínios. Isso poderia ser explorado por um atacante para **acessar informações sensíveis** abusando de solicitações CORS.

-### **Riscos de Ordem Superior**
+### CSRF - Same-Site Cookies bypass

-Outros riscos incluem **tomada de registro NS**. Se um atacante ganhar controle sobre um registro NS de um domínio, ele pode potencialmente direcionar uma parte do tráfego para um servidor sob seu controle. Esse risco é amplificado se o atacante definir um **TTL (Time to Live)** alto para os registros DNS, prolongando a duração do ataque.
+Pode ser possível que o subdomínio tenha permissão para enviar cookies para o domínio ou outros subdomínios, o que foi impedido pelo atributo `Same-Site` dos cookies. No entanto, note que tokens anti-CSRF ainda impedirão esse ataque se forem implementados corretamente.

-### Vulnerabilidade de Registro CNAME
+### OAuth tokens redirect
+
+Pode ser possível que o subdomínio comprometido tenha permissão para ser usado na URL `redirect_uri` de um fluxo OAuth. Isso poderia ser explorado por um atacante para **roubar o token OAuth**.
+
+### CSP Bypass
+
+Pode ser possível que o subdomínio comprometido (ou qualquer subdomínio) tenha permissão para ser usado, por exemplo, no `script-src` do CSP. Isso poderia ser explorado por um atacante para **injetar scripts maliciosos** e abusar de potenciais vulnerabilidades XSS.
+
+### **Emails and Subdomain Takeover**
+
+Outro aspecto do takeover de subdomínio envolve serviços de e-mail. Os atacantes podem manipular **registros MX** para receber ou enviar e-mails de um subdomínio legítimo, aumentando a eficácia dos ataques de phishing.
+
+### **Higher Order Risks**
+
+Outros riscos incluem **NS record takeover**. Se um atacante ganhar controle sobre um registro NS de um domínio, ele pode potencialmente direcionar uma parte do tráfego para um servidor sob seu controle. Esse risco é amplificado se o atacante definir um **TTL (Time to Live)** alto para os registros DNS, prolongando a duração do ataque.
+
+### CNAME Record Vulnerability

 Os atacantes podem explorar registros CNAME não reivindicados que apontam para serviços externos que não estão mais em uso ou foram desativados. Isso permite que eles criem uma página sob o domínio confiável, facilitando ainda mais o phishing ou a distribuição de malware.

-### **Estratégias de Mitigação**
+### **Mitigation Strategies**

 As estratégias de mitigação incluem:

 1. **Remover registros DNS vulneráveis** - Isso é eficaz se o subdomínio não for mais necessário.
-2. **Reivindicar o nome de domínio** - Registrar o recurso com o respectivo provedor de nuvem ou recomprar um domínio expirado.
-3. **Monitoramento regular para vulnerabilidades** - Ferramentas como [aquatone](https://github.com/michenriksen/aquatone) podem ajudar a identificar domínios suscetíveis. As organizações também devem revisar seus processos de gerenciamento de infraestrutura, garantindo que a criação de registros DNS seja a última etapa na criação de recursos e a primeira etapa na destruição de recursos.
+2. **Reivindicar o nome do domínio** - Registrar o recurso com o respectivo provedor de nuvem ou recomprar um domínio expirado.
+3. **Monitoramento regular de vulnerabilidades** - Ferramentas como [aquatone](https://github.com/michenriksen/aquatone) podem ajudar a identificar domínios suscetíveis. As organizações também devem revisar seus processos de gerenciamento de infraestrutura, garantindo que a criação de registros DNS seja a última etapa na criação de recursos e a primeira etapa na destruição de recursos.

-Para provedores de nuvem, verificar a propriedade do domínio é crucial para prevenir tomadas de subdomínio. Alguns, como [GitLab](https://about.gitlab.com/2018/02/05/gitlab-pages-custom-domain-validation/), reconheceram esse problema e implementaram mecanismos de verificação de domínio.
+Para provedores de nuvem, verificar a propriedade do domínio é crucial para prevenir takeovers de subdomínio. Alguns, como [GitLab](https://about.gitlab.com/2018/02/05/gitlab-pages-custom-domain-validation/), reconheceram esse problema e implementaram mecanismos de verificação de domínio.

-## Referências
+## References

 - [https://0xpatrik.com/subdomain-takeover/](https://0xpatrik.com/subdomain-takeover/)
 - [https://www.stratussecurity.com/post/subdomain-takeover-guide](https://www.stratussecurity.com/post/subdomain-takeover-guide)
+- [https://www.hackerone.com/blog/guide-subdomain-takeovers-20](https://www.hackerone.com/blog/guide-subdomain-takeovers-20)

 {{#include ../banners/hacktricks-training.md}}
--- a/src/pentesting-web/hacking-with-cookies/README.md
+++ b/src/pentesting-web/hacking-with-cookies/README.md
@ -10,11 +10,11 @@ Cookies vêm com vários atributos que controlam seu comportamento no navegador

 A data de expiração de um cookie é determinada pelo atributo `Expires`. Por outro lado, o atributo `Max-age` define o tempo em segundos até que um cookie seja excluído. **Opte por `Max-age`, pois reflete práticas mais modernas.**

-### Domain
+### Domínio

 Os hosts que receberão um cookie são especificados pelo atributo `Domain`. Por padrão, isso é definido para o host que emitiu o cookie, não incluindo seus subdomínios. No entanto, quando o atributo `Domain` é explicitamente definido, ele abrange subdomínios também. Isso torna a especificação do atributo `Domain` uma opção menos restritiva, útil para cenários onde o compartilhamento de cookies entre subdomínios é necessário. Por exemplo, definir `Domain=mozilla.org` torna os cookies acessíveis em seus subdomínios como `developer.mozilla.org`.

-### Path
+### Caminho

 Um caminho de URL específico que deve estar presente na URL solicitada para que o cabeçalho `Cookie` seja enviado é indicado pelo atributo `Path`. Este atributo considera o caractere `/` como um separador de diretório, permitindo correspondências em subdiretórios também.

@ -27,7 +27,7 @@ Quando dois cookies têm o mesmo nome, o escolhido para envio é baseado em:

 ### SameSite

- O atributo `SameSite` determina se os cookies são enviados em solicitações originadas de domínios de terceiros. Ele oferece três configurações:
+- O atributo `SameSite` dita se os cookies são enviados em solicitações originadas de domínios de terceiros. Ele oferece três configurações:
 - **Strict**: Restringe o cookie de ser enviado em solicitações de terceiros.
 - **Lax**: Permite que o cookie seja enviado com solicitações GET iniciadas por sites de terceiros.
 - **None**: Permite que o cookie seja enviado de qualquer domínio de terceiros.
@ -76,24 +76,24 @@ A solicitação **somente** enviará o cookie em uma solicitação HTTP se a sol

 ## Prefixos de Cookies

-Cookies prefixados com `__Secure-` devem ser definidos juntamente com a flag `secure` de páginas que estão seguras por HTTPS.
+Cookies prefixados com `__Secure-` devem ser definidos juntamente com a flag `secure` de páginas que são protegidas por HTTPS.

 Para cookies prefixados com `__Host-`, várias condições devem ser atendidas:

 - Eles devem ser definidos com a flag `secure`.
- Eles devem se originar de uma página segura por HTTPS.
- Eles são proibidos de especificar um domínio, impedindo sua transmissão para subdomínios.
+- Devem originar de uma página protegida por HTTPS.
+- É proibido especificar um domínio, impedindo sua transmissão para subdomínios.
 - O caminho para esses cookies deve ser definido como `/`.

 É importante notar que cookies prefixados com `__Host-` não podem ser enviados para superdomínios ou subdomínios. Essa restrição ajuda a isolar cookies de aplicação. Assim, empregar o prefixo `__Host-` para todos os cookies de aplicação pode ser considerado uma boa prática para aumentar a segurança e a isolação.

 ### Sobrescrevendo cookies

-Assim, uma das proteções dos cookies prefixados com `__Host-` é impedir que eles sejam sobrescritos a partir de subdomínios. Prevenindo, por exemplo, [**ataques de Cookie Tossing**](cookie-tossing.md). Na palestra [**Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities**](https://www.youtube.com/watch?v=F_wAzF4a7Xg) ([**paper**](https://www.usenix.org/system/files/usenixsecurity23-squarcina.pdf)), foi apresentado que era possível definir cookies prefixados com \_\_HOST- a partir de subdomínios, enganando o parser, por exemplo, adicionando "=" no início ou no final...:
+Assim, uma das proteções dos cookies prefixados com `__Host-` é impedir que eles sejam sobrescritos a partir de subdomínios. Prevenindo, por exemplo, [**ataques de Cookie Tossing**](cookie-tossing.md). Na palestra [**Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities**](https://www.youtube.com/watch?v=F_wAzF4a7Xg) ([**paper**](https://www.usenix.org/system/files/usenixsecurity23-squarcina.pdf)) é apresentado que foi possível definir cookies prefixados com \_\_HOST- a partir de subdomínios, enganando o parser, por exemplo, adicionando "=" no início ou no final...:

 <figure><img src="../../images/image (6) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>

-Ou em PHP, era possível adicionar **outros caracteres no início** do nome do cookie que seriam **substituídos por caracteres de sublinhado**, permitindo sobrescrever cookies `__HOST-`:
+Ou em PHP, foi possível adicionar **outros caracteres no início** do nome do cookie que seriam **substituídos por caracteres de sublinhado**, permitindo sobrescrever cookies `__HOST-`:

 <figure><img src="../../images/image (7) (1) (1) (1) (1).png" alt="" width="373"><figcaption></figcaption></figure>

@ -177,28 +177,54 @@ RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";

 - Undertow espera um novo cookie imediatamente após um valor entre aspas sem um ponto e vírgula.
 - Zope procura uma vírgula para começar a analisar o próximo cookie.
- As classes de cookies do Python começam a analisar em um caractere de espaço.
+- As classes de cookies do Python começam a análise em um caractere de espaço.

 Essa vulnerabilidade é particularmente perigosa em aplicações web que dependem de proteção CSRF baseada em cookies, pois permite que atacantes injetem cookies de token CSRF falsificados, potencialmente contornando medidas de segurança. O problema é agravado pelo tratamento de nomes de cookies duplicados pelo Python, onde a última ocorrência substitui as anteriores. Também levanta preocupações para cookies `__Secure-` e `__Host-` em contextos inseguros e pode levar a contornos de autorização quando cookies são passados para servidores de back-end suscetíveis à falsificação.

-### Cookies $version e contornos de WAF
+### Cookies $version

-De acordo com [**este blogpost**](https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie), pode ser possível usar o atributo de cookie **`$Version=1`** para fazer o back-end usar uma lógica antiga para analisar o cookie devido ao **RFC2109**. Além disso, outros valores como **`$Domain`** e **`$Path`** podem ser usados para modificar o comportamento do back-end com o cookie.
+#### Bypass de WAF

-#### Análise de contorno de valor com codificação de string entre aspas
+De acordo com [**this blogpost**](https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie), pode ser possível usar o atributo de cookie **`$Version=1`** para fazer o back-end usar uma lógica antiga para analisar o cookie devido ao **RFC2109**. Além disso, outros valores como **`$Domain`** e **`$Path`** podem ser usados para modificar o comportamento do back-end com o cookie.
+
+#### Ataque de Sanduíche de Cookies
+
+De acordo com [**this blogpost**](https://portswigger.net/research/stealing-httponly-cookies-with-the-cookie-sandwich-technique), é possível usar a técnica de sanduíche de cookies para roubar cookies HttpOnly. Estes são os requisitos e passos:
+
+- Encontre um lugar onde um **cookie aparentemente inútil é refletido na resposta**
+- **Crie um cookie chamado `$Version`** com valor `1` (ou você pode fazer isso em um ataque XSS a partir do JS) com um caminho mais específico para que ele obtenha a posição inicial (alguns frameworks como o Python não precisam deste passo)
+- **Crie o cookie que é refletido** com um valor que deixa uma **aspas duplas abertas** e com um caminho específico para que ele seja posicionado no banco de dados de cookies após o anterior (`$Version`)
+- Então, o cookie legítimo irá na sequência
+- **Crie um cookie fictício que fecha as aspas duplas** dentro de seu valor
+
+Dessa forma, o cookie da vítima fica preso dentro do novo cookie versão 1 e será refletido sempre que for refletido.
+e.g. from the post:
+```javascript
+document.cookie = `$Version=1;`;
+document.cookie = `param1="start`;
+// any cookies inside the sandwich will be placed into param1 value server-side
+document.cookie = `param2=end";`;
+```
+### Bypass de WAF
+
+#### Cookies $version
+
+Verifique a seção anterior.
+
+#### Análise de valor de bypass com codificação de string entre aspas

 Essa análise indica desescapar valores escapados dentro dos cookies, então "\a" se torna "a". Isso pode ser útil para contornar WAFS, como:

- `eval('test') => forbidden`
- `"\e\v\a\l\(\'\t\e\s\t\'\)" => allowed`
+- `eval('test') => proibido`
+- `"\e\v\a\l\(\'\t\e\s\t\'\)" => permitido`

 #### Contornando listas de bloqueio de nomes de cookies

-No RFC2109, é indicado que uma **vírgula pode ser usada como um separador entre valores de cookies**. E também é possível adicionar **espaços e tabulações antes e depois do sinal de igual**. Portanto, um cookie como `$Version=1; foo=bar, abc = qux` não gera o cookie `"foo":"bar, admin = qux"` mas os cookies `foo":"bar"` e `"admin":"qux"`. Note como 2 cookies são gerados e como o admin teve o espaço removido antes e depois do sinal de igual.
+No RFC2109, é indicado que uma **vírgula pode ser usada como um separador entre valores de cookies**. E também é possível adicionar **espaços e tabulações antes e depois do sinal de igual**. Portanto, um cookie como `$Version=1; foo=bar, abc = qux` não gera o cookie `"foo":"bar, admin = qux"`, mas os cookies `foo":"bar"` e `"admin":"qux"`. Note como 2 cookies são gerados e como o admin teve o espaço removido antes e depois do sinal de igual.

-#### Análise de contorno de valor com divisão de cookies
+#### Análise de valor de bypass com divisão de cookies

-Finalmente, diferentes backdoors se juntariam em uma string diferentes cookies passados em diferentes cabeçalhos de cookie como em:
+Finalmente, diferentes backdoors se juntariam em uma string diferentes cookies passados em diferentes cabeçalhos de cookies como em:
 ```
 GET / HTTP/1.1
 Host: example.com
@ -220,7 +246,7 @@ Resulting cookie: name=eval('test//, comment') => allowed
 - Faça logout e tente usar o mesmo cookie.
 - Tente fazer login com 2 dispositivos (ou navegadores) na mesma conta usando o mesmo cookie.
 - Verifique se o cookie contém alguma informação e tente modificá-lo.
- Tente criar várias contas com nomes de usuário quase iguais e verifique se consegue ver semelhanças.
+- Tente criar várias contas com nomes de usuário quase idênticos e verifique se consegue ver semelhanças.
 - Verifique a opção "**lembrar-me**" se existir para ver como funciona. Se existir e puder ser vulnerável, sempre use o cookie de **lembrar-me** sem nenhum outro cookie.
 - Verifique se o cookie anterior funciona mesmo após você mudar a senha.

@ -229,7 +255,7 @@ Resulting cookie: name=eval('test//, comment') => allowed
 Se o cookie permanecer o mesmo (ou quase) quando você faz login, isso provavelmente significa que o cookie está relacionado a algum campo da sua conta (provavelmente o nome de usuário). Então você pode:

 - Tentar criar muitas **contas** com nomes de usuário muito **semelhantes** e tentar **adivinhar** como o algoritmo está funcionando.
- Tentar **forçar o nome de usuário**. Se o cookie for salvo apenas como um método de autenticação para o seu nome de usuário, então você pode criar uma conta com o nome de usuário "**Bmin**" e **forçar** cada único **bit** do seu cookie porque um dos cookies que você tentará será o que pertence a "**admin**".
+- Tentar **forçar o nome de usuário**. Se o cookie for salvo apenas como um método de autenticação para o seu nome de usuário, então você pode criar uma conta com o nome de usuário "**Bmin**" e **forçar** cada único **bit** do seu cookie porque um dos cookies que você tentará será o pertencente a "**admin**".
 - Tente **Padding** **Oracle** (você pode descriptografar o conteúdo do cookie). Use **padbuster**.

 **Padding Oracle - Exemplos de Padbuster**