Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-24 05:33:33 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/cache-deception.md

20 KiB
Raw Blame History

Envenenamento de Cache e Engano de Cache

Aprenda hacking na AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras maneiras de apoiar o HackTricks:


Use Trickest para construir e automatizar fluxos de trabalho facilmente 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" %}

A diferença

Qual é a diferença entre envenenamento de cache web e engano de cache web?

  • No envenenamento de cache web, o atacante faz com que a aplicação armazene algum conteúdo malicioso no cache, e esse conteúdo é servido do cache para outros usuários da aplicação.
  • No engano de cache web, o atacante faz com que a aplicação armazene algum conteúdo sensível pertencente a outro usuário no cache, e o atacante então recupera esse conteúdo do cache.

Envenenamento de Cache

O envenenamento de cache tem como objetivo manipular o cache do lado do cliente para forçar os clientes a carregar recursos inesperados, parciais ou sob o controle de um atacante. A extensão do impacto depende da popularidade da página afetada, pois a resposta contaminada é servida exclusivamente aos usuários que visitam a página durante o período de contaminação do cache.

A execução de um ataque de envenenamento de cache envolve várias etapas:

  1. Identificação de Entradas Não-Chaveadas: Estes são parâmetros que, embora não sejam necessários para que uma solicitação seja armazenada em cache, podem alterar a resposta retornada pelo servidor. Identificar essas entradas é crucial, pois elas podem ser exploradas para manipular o cache.
  2. Exploração das Entradas Não-Chaveadas: Após identificar as entradas não-chaveadas, o próximo passo envolve descobrir como abusar desses parâmetros para modificar a resposta do servidor de uma forma que beneficie o atacante.
  3. Garantir que a Resposta Envenenada seja Armazenada em Cache: O último passo é garantir que a resposta manipulada seja armazenada no cache. Dessa forma, qualquer usuário que acesse a página afetada enquanto o cache estiver envenenado receberá a resposta contaminada.

Descoberta: Verificar cabeçalhos HTTP

Normalmente, quando uma resposta foi armazenada em cache, haverá um cabeçalho indicando isso, você pode verificar quais cabeçalhos você deve prestar atenção neste post: Cabeçalhos de Cache HTTP.

Descoberta: Armazenamento de código 400 em cache

Se você suspeitar que a resposta está sendo armazenada em cache, você poderia tentar enviar solicitações com um cabeçalho ruim, que deveria ser respondido com um código de status 400. Em seguida, tente acessar a solicitação normalmente e se a resposta for um código de status 400, você saberá que está vulnerável (e até poderia realizar um DoS).
Um cabeçalho mal configurado poderia ser apenas \: como cabeçalho.
Obs: Às vezes esses tipos de códigos de status não são armazenados em cache, então este teste será inútil.

Descoberta: Identificar e avaliar entradas não-chaveadas

Você poderia usar o Param Miner para forçar parâmetros e cabeçalhos que podem estar alterando a resposta da página. Por exemplo, uma página pode estar usando o cabeçalho X-Forwarded-For para indicar ao cliente para carregar o script de lá:

<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>

Obter uma resposta prejudicial do servidor back-end

Com o parâmetro/cabeçalho identificado, verifique como ele está sendo sanitizado e onde está sendo refletido ou afetando a resposta do cabeçalho. Você consegue abusar de alguma forma (realizar um XSS ou carregar um código JS controlado por você? realizar um DoS?...)

Obter a resposta em cache

Depois de ter identificado a página que pode ser abusada, qual parâmetro/cabeçalho usar e como abusar dele, você precisa obter a página em cache. Dependendo do recurso que você está tentando colocar em cache, isso pode levar algum tempo, talvez seja necessário tentar por vários segundos.
O cabeçalho X-Cache na resposta pode ser muito útil, pois pode ter o valor miss quando a solicitação não foi colocada em cache e o valor hit quando está em cache.
O cabeçalho Cache-Control também é interessante para saber se um recurso está sendo colocado em cache e quando será a próxima vez que o recurso será colocado em cache novamente: Cache-Control: public, max-age=1800
Outro cabeçalho interessante é o Vary. Este cabeçalho é frequentemente usado para indicar cabeçalhos adicionais que são tratados como parte da chave de cache mesmo que normalmente não sejam chaveados. Portanto, se o usuário conhece o User-Agent da vítima que está visando, ele pode envenenar o cache para os usuários que usam esse User-Agent específico.
Mais um cabeçalho relacionado ao cache é o Age. Ele define o tempo em segundos que o objeto está no cache do proxy.

Ao colocar uma solicitação em cache, tenha cuidado com os cabeçalhos que você usa porque alguns deles podem ser usados inesperadamente como chaveados e a vítima precisará usar o mesmo cabeçalho. Sempre teste um Envenenamento de Cache com navegadores diferentes para verificar se está funcionando.

Exemplos de Exploração

Exemplo mais simples

Um cabeçalho como X-Forwarded-For está sendo refletido na resposta sem ser sanitizado.
Você pode enviar uma carga útil básica de XSS e envenenar o cache para que todos que acessem a página sejam afetados pelo XSS:

GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"

Usando envenenamento de cache web para explorar vulnerabilidades de manipulação de cookies

Os cookies também podem ser refletidos na resposta de uma página. Se você puder abusar disso para causar um XSS, por exemplo, você poderá explorar o XSS em vários clientes que carregam a resposta de cache maliciosa.

GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"

Observe que se o cookie vulnerável for muito utilizado pelos usuários, as solicitações regulares limparão o cache.

Envenenamento de cache com travessia de caminho para roubar chave de API

Este relatório explica como foi possível roubar uma chave de API da OpenAI com uma URL como https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123 porque qualquer coisa correspondente a /share/* será armazenada em cache sem o Cloudflare normalizar a URL, o que foi feito quando a solicitação chegou ao servidor web.

Usando vários cabeçalhos para explorar vulnerabilidades de envenenamento de cache na web

Às vezes, você precisará explorar várias entradas sem chave para poder abusar de um cache. Por exemplo, você pode encontrar um redirecionamento aberto se definir X-Forwarded-Host para um domínio controlado por você e X-Forwarded-Scheme para http. Se o servidor estiver redirecionando todas as solicitações HTTP para HTTPS e usando o cabeçalho X-Forwarded-Scheme como o nome de domínio para o redirecionamento. Você pode controlar para onde a página é apontada pelo redirecionamento.

GET /resources/js/tracking.js HTTP/1.1
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
X-Forwarded-Scheme: http

Explorando com cabeçalho Vary limitado

Se você descobrir que o cabeçalho X-Host está sendo usado como nome de domínio para carregar um recurso JS mas o cabeçalho Vary na resposta está indicando User-Agent. Então, você precisa encontrar uma maneira de exfiltrar o User-Agent da vítima e envenenar o cache usando esse user agent:

GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com

Explorando a Manipulação de Cache HTTP ao abusar do Contrabando de Requisições HTTP

Saiba aqui como realizar ataques de Envenenamento de Cache ao abusar do Contrabando de Requisições HTTP.

Teste Automatizado para Envenenamento de Cache Web

O Scanner de Vulnerabilidades de Cache Web pode ser usado para testar automaticamente o envenenamento de cache web. Ele suporta diversas técnicas e é altamente personalizável.

Exemplo de uso: wcvs -u example.com


Use Trickest para construir e automatizar fluxos de trabalho facilmente com 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" %}

Exemplos Vulneráveis

Apache Traffic Server (CVE-2021-27577)

O ATS encaminhou o fragmento dentro da URL sem removê-lo e gerou a chave de cache usando apenas o host, caminho e consulta (ignorando o fragmento). Assim, a requisição /#/../?r=javascript:alert(1) foi enviada ao backend como /#/../?r=javascript:alert(1) e a chave de cache não continha o payload, apenas o host, caminho e consulta.

GitHub CP-DoS

O envio de um valor incorreto no cabeçalho content-type acionou uma resposta em cache 405. A chave de cache continha o cookie, tornando possível atacar apenas usuários não autenticados.

GitLab + GCP CP-DoS

O GitLab usa buckets GCP para armazenar conteúdo estático. Os buckets GCP suportam o cabeçalho x-http-method-override. Assim, era possível enviar o cabeçalho x-http-method-override: HEAD e envenenar o cache para retornar um corpo de resposta vazio. Também poderia suportar o método PURGE.

Rack Middleware (Ruby on Rails)

Em aplicações Ruby on Rails, o middleware Rack é frequentemente utilizado. O código Rack tem o objetivo de pegar o valor do cabeçalho x-forwarded-scheme e defini-lo como o esquema da requisição. Quando o cabeçalho x-forwarded-scheme: http é enviado, ocorre um redirecionamento 301 para o mesmo local, potencialmente causando uma Negação de Serviço (DoS) para esse recurso. Além disso, a aplicação pode reconhecer o cabeçalho X-forwarded-host e redirecionar os usuários para o host especificado. Esse comportamento pode levar ao carregamento de arquivos JavaScript do servidor de um atacante, representando um risco de segurança.

403 e Buckets de Armazenamento

Anteriormente, o Cloudflare armazenava em cache respostas 403. Tentativas de acessar S3 ou Azure Storage Blobs com cabeçalhos de Autorização incorretos resultariam em uma resposta 403 que era armazenada em cache. Embora o Cloudflare tenha parado de armazenar em cache respostas 403, esse comportamento pode ainda estar presente em outros serviços de proxy.

Inserção de Parâmetros Chaveados

Os caches frequentemente incluem parâmetros GET específicos na chave de cache. Por exemplo, o Varnish da Fastly armazenava o parâmetro size nas requisições. No entanto, se uma versão codificada em URL do parâmetro (por exemplo, siz%65) fosse enviada com um valor incorreto, a chave de cache seria construída usando o parâmetro size correto. No entanto, o backend processaria o valor no parâmetro codificado em URL. Codificar em URL o segundo parâmetro size levava à sua omissão pelo cache, mas sua utilização pelo backend. Atribuir um valor de 0 a esse parâmetro resultava em um erro 400 Bad Request cacheável.

Regras de User Agent

Alguns desenvolvedores bloqueiam requisições com user-agents correspondentes a ferramentas de alto tráfego como FFUF ou Nuclei para gerenciar a carga do servidor. Ironicamente, essa abordagem pode introduzir vulnerabilidades como envenenamento de cache e DoS.

Campos de Cabeçalho Ilegais

O RFC7230 especifica os caracteres aceitáveis nos nomes de cabeçalho. Cabeçalhos contendo caracteres fora do intervalo tchar especificado idealmente deveriam acionar uma resposta 400 Bad Request. Na prática, os servidores nem sempre seguem esse padrão. Um exemplo notável é a Akamai, que encaminha cabeçalhos com caracteres inválidos e armazena qualquer erro 400, desde que o cabeçalho cache-control não esteja presente. Foi identificado um padrão explorável onde o envio de um cabeçalho com um caractere ilegal, como \, resultaria em um erro 400 Bad Request cacheável.

Encontrando novos cabeçalhos

https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6

Decepção de Cache

O objetivo da Decepção de Cache é fazer com que os clientes carreguem recursos que serão salvos pelo cache com suas informações sensíveis.

Primeiramente, observe que extensões como .css, .js, .png, etc geralmente são configuradas para serem salvas no cache. Portanto, se você acessar www.example.com/profile.php/nonexistent.js, o cache provavelmente armazenará a resposta porque identifica a extensão .js. No entanto, se a aplicação estiver reproduzindo com o conteúdo sensível do usuário armazenado em www.example.com/profile.php, você pode roubar esses conteúdos de outros usuários.

Outras coisas para testar:

  • www.example.com/profile.php/.js
  • www.example.com/profile.php/.css
  • www.example.com/profile.php/test.js
  • www.example.com/profile.php/../test.js
  • www.example.com/profile.php/%2e%2e/test.js
  • Use extensões menos conhecidas como .avif

Um exemplo muito claro pode ser encontrado neste relatório: https://hackerone.com/reports/593712.
No exemplo, é explicado que se você carregar uma página inexistente como http://www.example.com/home.php/non-existent.css, o conteúdo de http://www.example.com/home.php (com as informações sensíveis do usuário) será retornado e o servidor de cache salvará o resultado.
Então, o atacante pode acessar http://www.example.com/home.php/non-existent.css em seu próprio navegador e observar as informações confidenciais dos usuários que acessaram anteriormente.

Observe que o proxy de cache deve ser configurado para armazenar arquivos com base na extensão do arquivo (.css) e não com base no tipo de conteúdo. No exemplo http://www.example.com/home.php/non-existent.css, terá um tipo de conteúdo text/html em vez de um tipo mime text/css (o esperado para um arquivo .css).

Saiba aqui como realizar ataques de Decepção de Cache abusando do Contrabando de Requisições HTTP.

Ferramentas Automáticas

  • toxicache: Scanner em Golang para encontrar vulnerabilidades de envenenamento de cache web em uma lista de URLs e testar múltiplas técnicas de injeção.

Referências


Use Trickest para construir e automatizar fluxos de trabalho facilmente com 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" %}

Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras maneiras de apoiar o HackTricks: