Cache Poisoning via URL discrepancies

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}

Este es un resumen de las técnicas propuestas en el post https://portswigger.net/research/gotta-cache-em-all para realizar ataques de cache poisoning abusando de las discrepancias entre los proxies de caché y los servidores web.

{% hint style="info" %} El objetivo de este ataque es hacer que el servidor de caché piense que se está cargando un recurso estático para que lo almacene en caché, mientras que el servidor de caché almacena como clave de caché parte de la ruta, pero el servidor web responde resolviendo otra ruta. El servidor web resolverá la ruta real que cargará una página dinámica (que podría almacenar información sensible sobre el usuario, una carga maliciosa como XSS o redirigir para cargar un archivo JS desde el sitio web del atacante, por ejemplo). {% endhint %}

Delimitadores

Los delimitadores de URL varían según el marco y el servidor, lo que impacta cómo se enrutan las solicitudes y se manejan las respuestas. Algunos delimitadores de origen comunes son:

Punto y coma: Usado en Spring para variables de matriz (por ejemplo, /hello;var=a/world;var1=b;var2=c → /hello/world).
Punto: Especifica el formato de respuesta en Ruby on Rails (por ejemplo, /MyAccount.css → /MyAccount).
Byte nulo: Trunca rutas en OpenLiteSpeed (por ejemplo, /MyAccount%00aaa → /MyAccount).
Byte de nueva línea: Separa componentes de URL en Nginx (por ejemplo, /users/MyAccount%0aaaa → /account/MyAccount).

Otros delimitadores específicos pueden encontrarse siguiendo este proceso:

Paso 1: Identificar solicitudes no cacheables y usarlas para monitorear cómo se manejan las URL con posibles delimitadores.
Paso 2: Agregar sufijos aleatorios a las rutas y comparar la respuesta del servidor para determinar si un carácter funciona como delimitador.
Paso 3: Introducir posibles delimitadores antes del sufijo aleatorio para ver si la respuesta cambia, indicando el uso de delimitadores.

Normalización y codificaciones

Propósito: Los analizadores de URL en los servidores de caché y de origen normalizan las URL para extraer rutas para el mapeo de puntos finales y claves de caché.
Proceso: Identifica los delimitadores de ruta, extrae y normaliza la ruta decodificando caracteres y eliminando segmentos de punto.

Codificaciones

Diferentes servidores HTTP y proxies como Nginx, Node y CloudFront decodifican los delimitadores de manera diferente, lo que lleva a inconsistencias entre CDNs y servidores de origen que podrían ser explotadas. Por ejemplo, si el servidor web realiza esta transformación /myAccount%3Fparam → /myAccount?param pero el servidor de caché mantiene como clave la ruta /myAccount%3Fparam, hay una inconsistencia.

Una forma de verificar estas inconsistencias es enviar solicitudes codificando diferentes caracteres después de cargar la ruta sin ninguna codificación y verificar si la respuesta de la ruta codificada provino de la respuesta en caché.

Segmento de punto

La normalización de la ruta donde están involucrados los puntos también es muy interesante para los ataques de cache poisoning. Por ejemplo, /static/../home/index o /aaa..\home/index, algunos servidores de caché almacenarán en caché estas rutas con ellas mismas como claves, mientras que otros podrían resolver la ruta y usar /home/index como la clave de caché.
Al igual que antes, enviar este tipo de solicitudes y verificar si la respuesta se obtuvo de la caché ayuda a identificar si la respuesta a /home/index es la respuesta enviada cuando se solicitan esas rutas.

Recursos estáticos

Varios servidores de caché siempre almacenarán en caché una respuesta si se identifica como estática. Esto puede ser porque:

La extensión: Cloudflare siempre almacenará en caché archivos con las siguientes extensiones: 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.
Es posible forzar a una caché a almacenar una respuesta dinámica utilizando un delimitador y una extensión estática, como una solicitud a /home$image.png que almacenará en caché /home$image.png y el servidor de origen responderá con /home.
Directorios estáticos bien conocidos: Los siguientes directorios contienen archivos estáticos y, por lo tanto, su respuesta debería ser almacenada en caché: /static, /assets, /wp-content, /media, /templates, /public, /shared.
Es posible forzar a una caché a almacenar una respuesta dinámica utilizando un delimitador, un directorio estático y puntos como: /home/..%2fstatic/something almacenará en caché /static/something y la respuesta será /home.
Directorios estáticos + puntos: Una solicitud a /static/..%2Fhome o a /static/..%5Chome podría ser almacenada en caché tal cual, pero la respuesta podría ser /home.
Archivos estáticos: Algunos archivos específicos siempre se almacenan en caché, como /robots.txt, /favicon.ico y /index.html. Lo que se puede abusar como /home/..%2Frobots.txt donde la caché podría almacenar /robots.txt y el servidor de origen responder a /home.