Cache Poisoning via URL discrepancies
Last updated
Last updated
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Este é um resumo das técnicas propostas no post https://portswigger.net/research/gotta-cache-em-all para realizar ataques de cache poisoning abusando das discrepâncias entre proxies de cache e servidores web.
O objetivo deste ataque é fazer o servidor de cache pensar que um recurso estático está sendo carregado para que ele o armazene em cache, enquanto o servidor de cache armazena como chave de cache parte do caminho, mas o servidor web responde resolvendo outro caminho. O servidor web resolverá o caminho real, que estará carregando uma página dinâmica (que pode armazenar informações sensíveis sobre o usuário, um payload malicioso como XSS ou redirecionar para carregar um arquivo JS do site do atacante, por exemplo).
Delimitadores de URL variam de acordo com o framework e o servidor, impactando como as requisições são roteadas e as respostas são tratadas. Alguns delimitadores de origem comuns são:
Ponto e vírgula: Usado no Spring para variáveis de matriz (por exemplo, /hello;var=a/world;var1=b;var2=c → /hello/world).
Ponto: Especifica o formato da resposta no Ruby on Rails (por exemplo, /MyAccount.css → /MyAccount).
Byte nulo: Trunca caminhos no OpenLiteSpeed (por exemplo, /MyAccount%00aaa → /MyAccount).
Byte de nova linha: Separa componentes de URL no Nginx (por exemplo, /users/MyAccount%0aaaa → /account/MyAccount).
Outros delimitadores específicos podem ser encontrados seguindo este processo:
Passo 1: Identificar requisições não cacheáveis e usá-las para monitorar como URLs com potenciais delimitadores são tratadas.
Passo 2: Anexar sufixos aleatórios aos caminhos e comparar a resposta do servidor para determinar se um caractere funciona como delimitador.
Passo 3: Introduzir potenciais delimitadores antes do sufixo aleatório para ver se a resposta muda, indicando o uso de delimitador.
Propósito: Parsers de URL em servidores de cache e de origem normalizam URLs para extrair caminhos para mapeamento de endpoints e chaves de cache.
Processo: Identifica delimitadores de caminho, extrai e normaliza o caminho decodificando caracteres e removendo segmentos de ponto.
Diferentes servidores HTTP e proxies como Nginx, Node e CloudFront decodificam delimitadores de maneira diferente, levando a inconsistências entre CDNs e servidores de origem que podem ser exploradas. Por exemplo, se o servidor web realiza esta transformação /myAccount%3Fparam → /myAccount?param, mas o servidor de cache mantém como chave o caminho /myAccount%3Fparam, há uma inconsistência.
Uma maneira de verificar essas inconsistências é enviar requisições URL codificando diferentes caracteres após carregar o caminho sem nenhuma codificação e verificar se a resposta do caminho codificado veio da resposta em cache.
A normalização de caminho onde pontos estão envolvidos também é muito interessante para ataques de cache poisoning. Por exemplo, /static/../home/index ou /aaa..\home/index, alguns servidores de cache irão armazenar esses caminhos com eles mesmos como chaves, enquanto outros podem resolver o caminho e usar /home/index como a chave de cache.
Assim como antes, enviar esse tipo de requisições e verificar se a resposta foi obtida do cache ajuda a identificar se a resposta para /home/index é a resposta enviada quando esses caminhos são solicitados.
Vários servidores de cache sempre armazenarão uma resposta se ela for identificada como estática. Isso pode ser devido a:
A extensão: O Cloudflare sempre armazenará em cache arquivos com as seguintes extensões: 7z, csv, gif, midi, png, tif, zip, avi, doc, gz, mkv, ppt, tiff, zst, avif, docx, ico, mp3, pptx, ttf, apk, dmg, iso, mp4, ps, webm, bin, ejs, jar, ogg, rar, webp, bmp, eot, jpg, otf, svg, woff, bz2, eps, jpeg, pdf, svgz, woff2, class, exe, js, pict, swf, xls, css, flac, mid, pls, tar, xlsx
É possível forçar um cache a armazenar uma resposta dinâmica usando um delimitador e uma extensão estática, como uma requisição para /home$image.png que armazenará /home$image.png e o servidor de origem responderá com /home
Diretórios estáticos bem conhecidos: Os seguintes diretórios contêm arquivos estáticos e, portanto, suas respostas devem ser armazenadas em cache: /static, /assets, /wp-content, /media, /templates, /public, /shared
É possível forçar um cache a armazenar uma resposta dinâmica usando um delimitador, um diretório estático e pontos, como: /home/..%2fstatic/something armazenará /static/something e a resposta será /home
Diretórios estáticos + pontos: Uma requisição para /static/..%2Fhome ou para /static/..%5Chome pode ser armazenada em cache como está, mas a resposta pode ser /home
Arquivos estáticos: Alguns arquivos específicos são sempre armazenados em cache, como /robots.txt, /favicon.ico e /index.html. O que pode ser abusado como /home/..%2Frobots.txt, onde o cache pode armazenar /robots.txt e o servidor de origem responder para /home.
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
