Cache Poisoning and Cache Deception
Utiliza Trickest para construir y automatizar flujos de trabajo fácilmente con las herramientas comunitarias más avanzadas del mundo. ¡Accede hoy mismo:
La diferencia
¿Cuál es la diferencia entre el envenenamiento de caché web y el engaño de caché web?
En el envenenamiento de caché web, el atacante hace que la aplicación almacene algún contenido malicioso en la caché, y este contenido se sirve desde la caché a otros usuarios de la aplicación.
En el engaño de caché web, el atacante hace que la aplicación almacene algún contenido sensible perteneciente a otro usuario en la caché, y luego el atacante recupera este contenido de la caché.
Envenenamiento de Caché
El envenenamiento de caché tiene como objetivo manipular la caché del lado del cliente para forzar a los clientes a cargar recursos que son inesperados, parciales o están bajo el control de un atacante. La magnitud del impacto depende de la popularidad de la página afectada, ya que la respuesta contaminada se sirve exclusivamente a los usuarios que visitan la página durante el período de contaminación de la caché.
La ejecución de un ataque de envenenamiento de caché implica varios pasos:
Identificación de Entradas sin Clave: Estos son parámetros que, aunque no son necesarios para que se almacene una solicitud en la caché, pueden alterar la respuesta devuelta por el servidor. Identificar estas entradas es crucial, ya que pueden ser explotadas para manipular la caché.
Explotación de las Entradas sin Clave: Después de identificar las entradas sin clave, el siguiente paso implica descubrir cómo abusar de estos parámetros para modificar la respuesta del servidor de una manera que beneficie al atacante.
Asegurar que la Respuesta Envenenada se Almacene en la Caché: El paso final es asegurar que la respuesta manipulada se almacene en la caché. De esta manera, cualquier usuario que acceda a la página afectada mientras la caché esté envenenada recibirá la respuesta contaminada.
Descubrimiento: Verificar encabezados HTTP
Por lo general, cuando una respuesta fue almacenada en la caché habrá un encabezado que lo indique, puedes verificar a qué encabezados debes prestar atención en este post: Encabezados de Caché HTTP.
Descubrimiento: Códigos de error de caché
Si piensas que la respuesta se está almacenando en una caché, podrías intentar enviar solicitudes con un encabezado incorrecto, que debería responder con un código de estado 400. Luego intenta acceder a la solicitud de forma normal y si la respuesta es un código de estado 400, sabrás que es vulnerable (e incluso podrías realizar un DoS).
Puedes encontrar más opciones en:
pageCache Poisoning to DoSSin embargo, ten en cuenta que a veces estos tipos de códigos de estado no se almacenan en caché por lo que esta prueba podría no ser confiable.
Descubrimiento: Identificar y evaluar entradas sin clave
Podrías utilizar Param Miner para bruteforcear parámetros y encabezados que puedan estar cambiando la respuesta de la página. Por ejemplo, una página podría estar usando el encabezado X-Forwarded-For para indicar al cliente que cargue el script desde allí:
Provocar una respuesta dañina desde el servidor back-end
Con el parámetro/header identificado, verifica cómo está siendo sanitizado y dónde se está reflejando o afectando la respuesta desde el header. ¿Puedes abusar de alguna manera (realizar un XSS o cargar un código JS controlado por ti? ¿realizar un DoS?...)
Obtener la respuesta en caché
Una vez que hayas identificado la página que puede ser abusada, qué parámetro/header usar y cómo abusar de él, necesitas obtener la página en caché. Dependiendo del recurso que estés intentando cachear, esto podría llevar algo de tiempo, es posible que necesites intentarlo durante varios segundos.
El header X-Cache en la respuesta podría ser muy útil, ya que puede tener el valor miss cuando la solicitud no estaba en caché y el valor hit cuando está en caché.
El header Cache-Control también es interesante para saber si un recurso está en caché y cuándo será la próxima vez que se almacene en caché de nuevo: Cache-Control: public, max-age=1800
Otro header interesante es Vary. Este header se usa a menudo para indicar headers adicionales que se tratan como parte de la clave de caché incluso si normalmente no tienen clave. Por lo tanto, si el usuario conoce el User-Agent de la víctima a la que apunta, puede envenenar la caché para los usuarios que utilizan ese User-Agent específico.
Un header más relacionado con la caché es Age. Define el tiempo en segundos que el objeto ha estado en la caché del proxy.
Al cachear una solicitud, ten cuidado con los headers que uses porque algunos de ellos podrían ser usados inesperadamente como claves y la víctima necesitará usar ese mismo header. Siempre prueba un Envenenamiento de Caché con diferentes navegadores para verificar si está funcionando.
Ejemplos de Explotación
Ejemplo más sencillo
Un header como X-Forwarded-For se está reflejando en la respuesta sin sanitizar.
Puedes enviar un payload básico de XSS y envenenar la caché para que todos los que accedan a la página sean afectados por XSS:
Nota que esto envenenará una solicitud a /en?region=uk y no a /en
Envenenamiento de caché para DoS
pageCache Poisoning to DoSUsando el envenenamiento de caché web para explotar vulnerabilidades en el manejo de cookies
Las cookies también podrían reflejarse en la respuesta de una página. Si puedes abusar de esto para causar un XSS, por ejemplo, podrías ser capaz de explotar XSS en varios clientes que carguen la respuesta de caché maliciosa.
Ten en cuenta que si la cookie vulnerable es muy utilizada por los usuarios, las solicitudes regulares limpiarán la caché.
Envenenamiento de caché con traversal de ruta para robar la clave de la API
Este informe explica cómo fue posible robar una clave de API de OpenAI con una URL como https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123 porque cualquier cosa que coincida con /share/* se almacenará en caché sin que Cloudflare normalice la URL, lo cual se hizo cuando la solicitud llegó al servidor web.
Uso de múltiples encabezados para explotar vulnerabilidades de envenenamiento de caché web
A veces necesitarás explotar varios inputs sin clave para poder abusar de una caché. Por ejemplo, puedes encontrar una redirección abierta si configuras X-Forwarded-Host a un dominio controlado por ti y X-Forwarded-Scheme a http. Si el servidor está redirigiendo todas las solicitudes HTTP a HTTPS y utilizando el encabezado X-Forwarded-Scheme como el nombre de dominio para la redirección. Puedes controlar hacia dónde apunta la página con la redirección.
Explotando con el encabezado Vary limitado
Vary limitadoSi descubres que el encabezado X-Host se está utilizando como nombre de dominio para cargar un recurso JS pero el encabezado Vary en la respuesta indica User-Agent. Entonces, necesitas encontrar una forma de extraer el User-Agent de la víctima y envenenar la caché utilizando ese user agent:
Fat Get
Envía una solicitud GET con la solicitud en la URL y en el cuerpo. Si el servidor web utiliza la del cuerpo pero el servidor de caché almacena la de la URL, cualquier persona que acceda a esa URL en realidad utilizará el parámetro del cuerpo. Como la vulnerabilidad que James Kettle encontró en el sitio web de Github:
Ocultación de parámetros
Por ejemplo, es posible separar parámetros en servidores ruby usando el carácter ; en lugar de &. Esto podría usarse para colocar valores de parámetros no clave dentro de los clave y abusar de ellos.
Laboratorio de Portswigger: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking
Explotando la intoxicación de caché HTTP abusando del contrabando de solicitudes HTTP
Aprende aquí cómo realizar ataques de Intoxicación de Caché abusando del Contrabando de Solicitudes HTTP.
Pruebas automatizadas para la intoxicación de caché web
El Escáner de Vulnerabilidades de Caché Web se puede utilizar para probar automáticamente la intoxicación de caché web. Admite muchas técnicas diferentes y es altamente personalizable.
Uso de ejemplo: wcvs -u example.com
Utiliza Trickest para construir y automatizar flujos de trabajo fácilmente con las herramientas comunitarias más avanzadas del mundo. Accede hoy mismo:
Ejemplos Vulnerables
Apache Traffic Server (CVE-2021-27577)
ATS reenviaba el fragmento dentro de la URL sin eliminarlo y generaba la clave de caché solo usando el host, la ruta y la consulta (ignorando el fragmento). Por lo tanto, la solicitud /#/../?r=javascript:alert(1) se enviaba al backend como /#/../?r=javascript:alert(1) y la clave de caché no contenía la carga útil en su interior, solo el host, la ruta y la consulta.
GitHub CP-DoS
Enviar un valor incorrecto en el encabezado de tipo de contenido desencadenaba una respuesta en caché 405. La clave de caché contenía la cookie, por lo que solo era posible atacar a usuarios no autenticados.
GitLab + GCP CP-DoS
GitLab utiliza buckets de GCP para almacenar contenido estático. Los Buckets de GCP admiten el encabezado x-http-method-override. Por lo tanto, era posible enviar el encabezado x-http-method-override: HEAD y envenenar la caché para devolver un cuerpo de respuesta vacío. También podría admitir el método PURGE.
Middleware de Rack (Ruby on Rails)
En las aplicaciones Ruby on Rails, a menudo se utiliza el middleware de Rack. El propósito del código de Rack es tomar el valor del encabezado x-forwarded-scheme y establecerlo como el esquema de la solicitud. Cuando se envía el encabezado x-forwarded-scheme: http, se produce una redirección 301 a la misma ubicación, lo que potencialmente puede causar una Denegación de Servicio (DoS) a ese recurso. Además, la aplicación podría reconocer el encabezado X-forwarded-host y redirigir a los usuarios al host especificado. Este comportamiento puede llevar a la carga de archivos JavaScript desde el servidor de un atacante, lo que representa un riesgo de seguridad.
403 y Buckets de Almacenamiento
Cloudflare anteriormente almacenaba en caché respuestas 403. Intentar acceder a S3 o Azure Storage Blobs con encabezados de autorización incorrectos resultaría en una respuesta 403 que se almacenaba en caché. Aunque Cloudflare ha dejado de almacenar en caché respuestas 403, este comportamiento aún podría estar presente en otros servicios de proxy.
Inyectando Parámetros Clave
Las cachés a menudo incluyen parámetros GET específicos en la clave de caché. Por ejemplo, Varnish de Fastly almacenaba el parámetro size en las solicitudes. Sin embargo, si se enviaba también una versión codificada en URL del parámetro (por ejemplo, siz%65) con un valor erróneo, la clave de caché se construiría utilizando el parámetro size correcto. Sin embargo, el backend procesaría el valor en el parámetro codificado en URL. Codificar en URL el segundo parámetro size llevaba a su omisión por la caché pero su utilización por el backend. Asignar un valor de 0 a este parámetro resultaba en un error 400 Bad Request en caché.
Reglas de Agente de Usuario
Algunos desarrolladores bloquean solicitudes con agentes de usuario que coinciden con los de herramientas de alto tráfico como FFUF o Nuclei para gestionar la carga del servidor. Irónicamente, este enfoque puede introducir vulnerabilidades como la intoxicación de caché y DoS.
Campos de Encabezado Ilegales
El RFC7230 especifica los caracteres aceptables en los nombres de encabezado. Los encabezados que contienen caracteres fuera del rango tchar especificado idealmente deberían desencadenar una respuesta 400 Bad Request. En la práctica, los servidores no siempre se adhieren a este estándar. Un ejemplo notable es Akamai, que reenvía encabezados con caracteres no válidos y almacena cualquier error 400, siempre que el encabezado cache-control no esté presente. Se identificó un patrón explotable donde el envío de un encabezado con un carácter no válido, como \, resultaría en un error 400 Bad Request en caché.
Encontrar nuevos encabezados
https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6
Engaño de Caché
El objetivo del Engaño de Caché es hacer que los clientes carguen recursos que van a ser guardados por la caché con su información sensible.
En primer lugar, ten en cuenta que las extensiones como .css, .js, .png, etc. suelen estar configuradas para ser guardadas en la caché. Por lo tanto, si accedes a www.example.com/profile.php/nonexistent.js, es probable que la caché almacene la respuesta porque ve la extensión .js. Sin embargo, si la aplicación está reproduciendo con el contenido sensible del usuario almacenado en www.example.com/profile.php, puedes robar ese contenido de otros usuarios.
Otras cosas para probar:
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
Usar extensiones menos conocidas como
.avif
Otro ejemplo muy claro se puede encontrar en este informe: https://hackerone.com/reports/593712. En el ejemplo, se explica que si cargas una página inexistente como http://www.example.com/home.php/non-existent.css, el contenido de http://www.example.com/home.php (con la información sensible del usuario) se devolverá y el servidor de caché guardará el resultado. Luego, el atacante puede acceder a http://www.example.com/home.php/non-existent.css en su propio navegador y observar la información confidencial de los usuarios que accedieron antes.
Ten en cuenta que el proxy de caché debe estar configurado para cachear archivos basados en la extensión del archivo (.css) y no en el tipo de contenido. En el ejemplo http://www.example.com/home.php/non-existent.css tendrá un tipo de contenido text/html en lugar de un tipo MIME text/css (que es el esperado para un archivo .css).
Aprende aquí cómo realizar ataques de Engaño de Caché abusando del Contrabando de Solicitudes HTTP.
Herramientas Automáticas
toxicache: Escáner en Golang para encontrar vulnerabilidades de envenenamiento de caché web en una lista de URLs y probar múltiples técnicas de inyección.
Referencias
Utiliza Trickest para construir y automatizar flujos de trabajo fácilmente con las herramientas comunitarias más avanzadas del mundo. Obtén acceso hoy:
Última actualización
