Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 05:03:35 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/h2c-smuggling.md

14 KiB
Raw Blame History

Actualización de Smuggling de Cabecera

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

Encuentra las vulnerabilidades que más importan para que puedas solucionarlas más rápido. Intruder rastrea tu superficie de ataque, realiza escaneos proactivos de amenazas, encuentra problemas en toda tu pila tecnológica, desde APIs hasta aplicaciones web y sistemas en la nube. Pruébalo gratis hoy.

{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}

Smuggling H2C

HTTP2 sobre texto sin formato (H2C)

Una conexión HTTP normalmente dura solo durante la duración de una sola solicitud. Sin embargo, H2C o "http2 sobre texto sin formato" es donde una conexión http transitoria normal se actualiza a una conexión persistente que utiliza el protocolo binario http2 para comunicarse continuamente en lugar de una solicitud utilizando el protocolo http en texto sin formato.

La segunda parte del smuggling ocurre cuando se utiliza un proxy inverso. Normalmente, cuando se realizan solicitudes http a un proxy inverso, el proxy manejará la solicitud, procesará una serie de reglas de enrutamiento, luego enviará la solicitud al backend y devolverá la respuesta. Cuando una solicitud http incluye una cabecera Connection: Upgrade, como en una conexión websocket, el proxy inverso mantendrá la conexión persistente entre el cliente y el servidor, lo que permite la comunicación continua necesaria para estos protocolos. Para una conexión H2C, el RFC requiere que estén presentes 3 cabeceras:

Upgrade: h2c
HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA
Connection: Upgrade, HTTP2-Settings

Entonces, ¿dónde está el error? Cuando se actualiza una conexión, el proxy inverso a menudo deja de manejar solicitudes individuales, asumiendo que una vez establecida la conexión, su trabajo de enrutamiento está hecho. Mediante H2C Smuggling, podemos evadir las reglas que un proxy inverso utiliza al procesar solicitudes, como el enrutamiento basado en la ruta, la autenticación o el procesamiento del WAF, siempre que podamos establecer una conexión H2C primero.

Proxies Vulnerables

Tenga en cuenta, a partir de la explicación de la vulnerabilidad, que el servidor proxy necesita reenviar el encabezado Upgrade, y a veces también es necesario reenviar correctamente el encabezado Connection.

Por defecto, los siguientes servicios reenvían los encabezados Upgrade y Connection durante el proxy-pass, lo que permite la h2c smuggling de forma predeterminada:

  • HAProxy
  • Traefik
  • Nuster

Por defecto, estos servicios no reenvían ambos encabezados Upgrade y Connection durante el proxy-pass, pero se pueden configurar de manera insegura (pasando encabezados Upgrade y Connection sin filtrar):

  • AWS ALB/CLB
  • NGINX
  • Apache
  • Squid
  • Varnish
  • Kong
  • Envoy
  • Apache Traffic Server

Explotación

La publicación original del blog señala que no todos los servidores reenviarán los encabezados requeridos para una actualización de conexión H2C compatible. Esto significa que los balanceadores de carga como AWS ALB/CLB, NGINX y Apache Traffic Server, entre otros, impedirán una conexión H2C de forma predeterminada. Sin embargo, al final de la publicación del blog, menciona que "no todos los backends eran compatibles, y pudimos probar con la variante no compatible Connection: Upgrade, donde se omite el valor HTTP2-Settings del encabezado Connection".

{% hint style="danger" %} Tenga en cuenta que incluso si la URL de proxy_pass (el punto final al que el proxy reenvía la conexión) apuntaba a una ruta específica, como http://backend:9999/socket.io, la conexión se establecerá con http://backend:9999, por lo que puede acceder a cualquier otra ruta dentro de ese punto final interno abusando de esta técnica. Por lo tanto, no importa si se especifica una ruta en la URL de proxy_pass. {% endhint %}

Utilizando las herramientas https://github.com/BishopFox/h2csmuggler y https://github.com/assetnote/h2csmuggler, puede intentar evadir las protecciones impuestas por el proxy estableciendo una conexión H2C y acceder a los recursos protegidos por el proxy.

Siga este enlace para obtener más información sobre esta vulnerabilidad en Nginx.

Websocket Smuggling

Similar a la técnica anterior, esta en lugar de crear un túnel HTTP2 hacia un punto final accesible a través de un proxy, creará un túnel Websocket con el mismo propósito, evitando las limitaciones potenciales de los proxies y comunicándose directamente con el punto final:

Escenario 1

Tenemos un backend que expone una API WebSocket pública y también tiene una API REST interna no disponible desde el exterior. Un cliente malintencionado desea acceder a la API REST interna.

En el primer paso, el cliente envía una solicitud de actualización al proxy inverso, pero con una versión de protocolo incorrecta en el encabezado Sec-WebSocket-Version. El proxy no valida el encabezado Sec-WebSocket-Version y cree que la solicitud de actualización es correcta. Luego, traduce la solicitud al backend.

En el segundo paso, el backend envía una respuesta con el código de estado 426 porque la versión del protocolo es incorrecta en el encabezado Sec-WebSocket-Version. Sin embargo, el proxy inverso no verifica suficientemente la respuesta del backend (incluido el código de estado) y cree que el backend está listo para la comunicación WebSocket. Luego, traduce la solicitud al cliente.

Finalmente, el proxy inverso cree que se ha establecido una conexión WebSocket entre el cliente y el backend. En realidad, no hay una conexión WebSocket: el backend rechazó la solicitud de actualización. Al mismo tiempo, el proxy mantiene la conexión TCP o TLS entre el cliente y el backend en estado abierto. El cliente puede acceder fácilmente a la API REST privada enviando una solicitud HTTP a través de la conexión.

Se descubrió que los siguientes proxies inversos se ven afectados:

  • Varnish: el equipo se negó a solucionar el problema descrito.
  • Envoy proxy 1.8.0 (o anterior): en versiones más nuevas, el mecanismo de actualización ha cambiado.
  • Otros: por determinar.

Escenario 2

La mayoría de los proxies inversos (por ejemplo, NGINX) verifican el código de estado del backend durante la parte de inicio de la conexión. Esto hace que el ataque sea más difícil pero no imposible.

Observemos el segundo escenario. Tenemos un backend que expone una API WebSocket pública y una API REST pública para verificar la salud, y también tiene una API REST interna no disponible desde el exterior. Un cliente malintencionado desea acceder a la API REST interna. Se utiliza NGINX como proxy inverso. La API WebSocket está disponible en la ruta /api/socket.io/ y la API de verificación de salud en la ruta /api/health.

La API de verificación de salud se invoca enviando una solicitud POST, el parámetro con el nombre u controla la URL. El backend accede a un recurso externo y devuelve el código de estado al cliente.

En el primer paso, el cliente envía una solicitud POST para invocar la API de verificación de salud pero con un encabezado HTTP adicional Upgrade: websocket. NGINX cree que es una solicitud de actualización normal, solo busca el encabezado Upgrade omitiendo otras partes de la solicitud. Luego, el proxy traduce la solicitud al backend.

En el segundo paso, el backend invoca la API de verificación de salud. Accede a un recurso externo controlado por usuarios malintencionados que devuelve una respuesta HTTP con el código de estado 101. El backend traduce esa respuesta al proxy inverso. Dado que NGINX solo valida el código de estado, creerá que el backend está listo para la comunicación WebSocket. Luego, traduce la solicitud al cliente.

{% hint style="warning" %} Observe cómo este escenario es mucho más complejo de explotar, ya que debe poder contactar algún punto final que devuelva el código de estado 101. {% endhint %}

Finalmente, NGINX cree que se ha establecido una conexión WebSocket entre el cliente y el backend. En realidad, no hay una conexión WebSocket: se invocó la API de verificación de salud en el backend. Al mismo tiempo, el proxy inverso mantiene la conexión TCP o TLS entre el cliente y el backend en estado abierto. El cliente puede acceder fácilmente a la API REST privada enviando una solicitud HTTP a través de la conexión.

La mayoría de los proxies inversos deberían verse afectados por ese escenario. Sin embargo, la explotación requiere la existencia de una vulnerabilidad externa de SSRF (generalmente considerada un problema de baja gravedad).

Laboratorios

Verifica los laboratorios para probar ambos escenarios en https://github.com/0ang3el/websocket-smuggle.git

Referencias

Encuentra las vulnerabilidades que más importan para que puedas solucionarlas más rápido. Intruder rastrea tu superficie de ataque, realiza escaneos de amenazas proactivas, encuentra problemas en toda tu pila tecnológica, desde APIs hasta aplicaciones web y sistemas en la nube. Pruébalo gratis hoy.

{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥