Cache Poisoning via URL discrepancies
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
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.
Normalização e Codificações
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.
Codificações
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 realizar esta transformação /myAccount%3Fparam → /myAccount?param, mas o servidor de cache mantiver como chave o caminho /myAccount%3Fparam, há uma inconsistência.
Uma maneira de verificar essas inconsistências é enviar requisições 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.
Segmento de ponto
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.
Recursos Estáticos
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.pngque armazenará em cache/home$image.pnge o servidor de origem responderá com/homeDiretó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/somethingarmazenará em cache/static/somethinge a resposta será/homeDiretórios estáticos + pontos: Uma requisição para
/static/..%2Fhomeou para/static/..%5Chomepode ser armazenada em cache como está, mas a resposta pode ser/homeArquivos estáticos: Alguns arquivos específicos são sempre armazenados em cache, como
/robots.txt,/favicon.icoe/index.html. O que pode ser abusado como/home/..%2Frobots.txt, onde o cache pode armazenar/robots.txte o servidor de origem responderá para/home.
Last updated
