Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-28 07:31:10 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/domain-subdomain-takeover.md

26 KiB
Raw Blame History

Domínio/Subdomínio takeover

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

Domínio takeover

Se você descobrir algum domínio (dominio.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.

Subdomínio takeover

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 que está sendo usado, você pode realizar o subdomínio takeover.

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

Verificando subdomínios suscetíveis a sequestro com BBOT:

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

bbot -t evilcorp.com -f subdomain-enum

Geração de Subdomínio Takeover 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 configurado como 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 administrador do sistema apontar 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 caso do GitHub) e dizer que something.testing.com está apontando para lá. Porque o wildcard CNAME concordará, 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 dessa vulnerabilidade no write-up do CTF: https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api

Explorando um Subdomínio Takeover

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

Recentemente, eu escrevi sobre os conceitos básicos de subdomínio takeover. Embora o conceito seja agora geralmente bem compreendido, notei que as pessoas geralmente têm dificuldade em entender os riscos que o subdomínio takeover traz para a mesa. Neste post, vou aprofundar e cobrir os riscos mais notáveis do subdomínio takeover na minha perspectiva.

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

Transparência para um Navegador

Para começar, vamos analisar a resolução DNS quando o CNAME está envolvido:

Resolução DNS

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

Um domínio desse tipo é perfeito para phishing. Os 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 por um atacante. Vamos pegar como exemplo um banco aleatório. Se um dos subdomínios do banco for vulnerável ao subdomínio takeover, um atacante pode criar um formulário HTML que imita o formulário de login do sistema de internet banking do banco. Em seguida, um atacante pode executar uma campanha de spear phishing ou phishing em massa pedindo aos usuários que façam login e alterem suas senhas. Nesta etapa, as senhas são capturadas por um atacante que está no controle do domínio em questão. A URL fornecida no e-mail de phishing é um subdomínio legítimo de um banco. Portanto, os usuários não têm conhecimento de algo malicioso acontecendo. Filtros de spam e outras medidas de segurança também são menos propensos a identificar 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 ao subdomínio takeover é muito menos "legítimo" do que ter um subdomínio de 2º nível com um nome de subdomínio amigável. Vi vários casos de subdomínios perfeitos para phishing, incluindo:

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

Todos eles vulneráveis ao subdomínio 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 o exemplo da Apple). Tendo um certificado SSL válido (mais sobre isso abaixo), palavra-chave no nome de domínio e um site que imita o site da marca-alvo, as pessoas tendem a cair nesses ataques. Pense nas chances com um subdomínio legítimo dessa marca.


Use Trickest para criar e automatizar fluxos de trabalho com facilidade, usando as ferramentas comunitárias mais avançadas do mundo.
Acesse hoje mesmo:

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

Certificados SSL

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

Fluxo do Let's Encrypt

Isso significa que, se houver um conteúdo específico colocado em um caminho de URL específico, o Let's Encrypt aprovará a emissão de um certificado para um determinado domínio. Como um atacante tem controle total sobre o conteúdo do domínio que é vulnerável ao subdomínio 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 esse domínio, o que reduz ainda mais a suspeita de um ataque de phishing.

Roubo de Cookies

Isso está intimamente relacionado à transparência do navegador, mas tem consequências diferentes. O navegador da web implementa muitas políticas de segurança para evitar 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ê? Embora o HTTP seja um protocolo sem estado, os cookies são usados para rastrear sessões. Por conveniência, os usuários costumam salvar cookies por um longo período para evitar fazer login toda vez. Esses cookies, portanto, atuam como um token de login que é apresentado ao servidor da web e o usuário é identificado. Ataques como Roubo de sessão naturalmente evoluíram a partir desse conceito.

O navegador automaticamente apresenta os cookies armazenados com cada solicitação ao domínio que os emitiu. Há uma exceção para isso, na qual os cookies podem ser compartilhados entre subdomínios (leia aqui, observe também a seção 8.7). Isso geralmente acontece quando o site usa um sistema de login único (SSO) baseado em cookies. Usando o SSO, um usuário pode fazer login usando um subdomínio e compartilhar o mesmo token de sessão em uma ampla variedade 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 pelo servidor web que reside 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 subdominio.example.com. Esse comportamento cria a possibilidade de ataques de alta gravidade usando subdomínio takeover. Suponha que um determinado domínio esteja usando cookies de sessão para domínio curinga. Se houver um subdomínio vulnerável ao subdomínio takeover, a única coisa necessária para obter o token de sessão do usuário é enganá-lo para 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:

  • Cookie HttpOnly - Por padrão, os cookies podem ser acessados 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 em questão 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 só pode ser comunicado de volta ao servidor web se o HTTPS for usado.

Se o domínio for vulnerável ao subdomínio takeover, um invasor pode obter 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 tomado.

O roubo de cookies usando takeover foi explicado em um relatório de recompensa por bugs report 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 ao subdomínio takeover, apontando para uma distribuição não reclamada do 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 o 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 o 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 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 regulares. Se o código externo não estiver fazendo algo importante (por exemplo, sendo 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 URL do código JavaScript fornecido e, assim, obter controle sobre cada visitante que acessa o site original.

No entanto, há uma maneira de proteger a integridade dos arquivos JavaScript em um navegador. A Integridade de Subrecursos foi proposta como um mecanismo para incluir um hash criptográfico como um atributo integrity na 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

Quando o subdomínio takeover do CNAME é possível, os registros MX também podem ser configurados por um invasor para um servidor web arbitrário. Isso permite receber e-mails em um subdomínio legítimo de uma determinada marca - especialmente útil novamente em ataques de phishing (spear phishing) onde a interação entre o 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 permitidos para envio de e-mails para o domínio. O SPF armazena a configuração em registros TXT do DNS. Com o subdomínio takeover, os registros TXT também estão sob o controle do invasor - as verificações SPF podem ser facilmente passadas.

Como mencionei 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

O conceito de subdomínio 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 estará vulnerável ao subdomínio takeover.

Um dos problemas no subdomínio takeover usando registro NS é que o nome de domínio de origem geralmente possui vários registros NS. Múltiplos 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 invasor assumir o controle do 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 um servidor de nomes controlado por um invasor é de 50%.
  2. Se o resolvedor DNS do usuário escolher ns.nonvulnerable.com (servidor de nomes legítimo), o resultado correto será retornado e provavelmente será 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 invasor), um invasor pode fornecer um resultado falso que também será armazenado em cache. Como um invasor controla o servidor de nomes, ela pode definir o TTL para esse resultado específico, por exemplo, uma semana.

O processo acima é repetido toda vez que a entrada de cache expira. Quando um invasor escolhe usar um TTL com valor alto, o resultado falso permanecerá no cache DNS durante 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 invasor. Essa ideia é ainda amplificada quando os resolvedores DNS públicos (por exemplo, Google DNS) são usados. Nesse caso, os resolvedores públicos provavelmente armazenarão em cache 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, também é obtido controle sobre todos os domínios de nível superior do nome de domínio de origem. Isso ocorre porque possuir um nome de domínio canônico do registro NS significa possuir a zona DNS completa do nome de domínio de origem.

Em 2016, Matthew Bryant demonstrou um subdomínio takeover usando registro NS em maris.int. O domínio de nível superior .INT é um TLD especial e apenas algumas poucas domínios o utilizam. Bryant mostrou que, mesmo que o registro de tais nomes de domínio seja aprovado exclusivamente pela IANA, os servidores de nomes podem ser definidos para domínios arbitrários. Como um dos servidores de nomes do maris.int estava disponível para registro (cobalt.aliis.be), o subdomínio takeover foi possível mesmo nesse TLD restrito.

Matthew também demonstrou um ataque de gravidade ainda maior, onde ele foi capaz de obter controle sobre o servidor de nomes do domínio de nível superior .IO. Obter controle sobre o .IO significa controlar as respostas para todos os domínios .IO. Nesse caso, um dos servidores de nomes do .IO era ns-a1.io, que estava disponível para registro. Ao registrar ns-a1.io, Bryant foi capaz de receber consultas DNS e controlar suas respostas para todos os domínios .IO.

Mitigação

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

  • Remova o registro DNS afetado - A solução mais simples é remover o registro afetado da zona DNS. Esse passo é geralmente utilizado quando a organização conclui que o nome de domínio de origem afetado não é mais necessário.
  • Reivindique 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 evitar subdomain takeover no futuro, as organizações devem alterar 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, ocorre o oposto: o registro DNS precisa ser removido como a primeira etapa desse processo. Ferramentas como aquatone incluem verificações para subdomain takeover. Essas verificações devem ser realizadas periodicamente por uma equipe de segurança da organização para verificar se não há domínios vulneráveis. Os processos de coleta centralizada de nomes de domínio expostos geralmente não são eficientes dentro das organizações (devido a equipes globais, etc.) e o monitoramento externo geralmente é a melhor opção.

A mitigação para provedores de nuvem também deve ser considerada. Os serviços em nuvem não verificam a propriedade do domínio. A razão para isso é principalmente a conveniência. O provedor de nuvem não introduz 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. Outro motivo é que, quando um recurso em nuvem é removido, o usuário geralmente não é mais cliente desse serviço. A pergunta que os provedores de nuvem fazem é: Por que deveríamos nos importar?

Provedores como GitLab perceberam que o subdomain takeover é um problema e implementaram um mecanismo de verificação de domínio.

Alumas partes deste post são trechos da minha Tese de Mestrado.

Até a próxima!

Patrik


Use Trickest para criar e automatizar fluxos de trabalho com facilidade, utilizando as ferramentas comunitárias mais avançadas do mundo.
Acesse hoje mesmo:

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

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