<summary><strong>Aprende hacking en AWS desde cero hasta convertirte en un experto con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* 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 la [**merchandising oficial de PEASS & HackTricks**](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.
H2C, o **http2 sobre texto sin formato**, se desvía de la norma de conexiones HTTP transitorias al actualizar una conexión HTTP estándar a una persistente. Esta conexión actualizada utiliza el protocolo binario http2 para la comunicación continua, en lugar de la naturaleza de una sola solicitud del HTTP sin formato.
La esencia del problema de smuggling surge con el uso de un **proxy inverso**. Normalmente, el proxy inverso procesa y reenvía las solicitudes HTTP al backend, devolviendo la respuesta del backend después de eso. Sin embargo, cuando el encabezado `Connection: Upgrade` está presente en una solicitud HTTP (comúnmente visto con conexiones websocket), el **proxy inverso mantiene una conexión persistente** entre el cliente y el servidor, facilitando el intercambio continuo requerido por ciertos protocolos. Para las conexiones H2C, la adherencia al RFC requiere la presencia de tres encabezados específicos:
La vulnerabilidad surge cuando, después de actualizar una conexión, el proxy inverso deja de gestionar las solicitudes individuales, asumiendo que su trabajo de enrutamiento está completo después del establecimiento de la conexión. Explotar el H2C Smuggling permite eludir las reglas del proxy inverso aplicadas durante el procesamiento de solicitudes, como el enrutamiento basado en la ruta, la autenticación y el procesamiento de WAF, asumiendo que se inicia con éxito una conexión H2C.
La vulnerabilidad depende del manejo por parte del proxy inverso de los encabezados `Upgrade` y a veces `Connection`. Los siguientes proxies inherentemente reenvían estos encabezados durante el proxy-pass, lo que habilita inherentemente el H2C smuggling:
Por el contrario, estos servicios no reenvían inherentemente ambos encabezados durante el proxy-pass. Sin embargo, pueden estar configurados de forma insegura, permitiendo el reenvío no filtrado de los encabezados `Upgrade` y `Connection`:
Es crucial tener en cuenta que no todos los servidores reenvían inherentemente los encabezados requeridos para una actualización de conexión H2C conforme. Por lo tanto, servidores como AWS ALB/CLB, NGINX y Apache Traffic Server, entre otros, bloquean naturalmente las conexiones H2C. No obstante, vale la pena probar con la variante no conforme `Connection: Upgrade`, que excluye el valor `HTTP2-Settings` del encabezado `Connection`, ya que algunos backends pueden no cumplir con los estándares.
Independientemente de la **ruta** específica designada en la URL `proxy_pass` (por ejemplo, `http://backend:9999/socket.io`), la conexión establecida se establece por defecto en `http://backend:9999`. Esto permite la interacción con cualquier ruta dentro de ese punto final interno, aprovechando esta técnica. En consecuencia, la especificación de una ruta en la URL `proxy_pass` no restringe el acceso.
Las herramientas [**h2csmuggler de BishopFox**](https://github.com/BishopFox/h2csmuggler) y [**h2csmuggler de assetnote**](https://github.com/assetnote/h2csmuggler) facilitan los intentos de **eludir las protecciones impuestas por el proxy** al establecer una conexión H2C, lo que permite acceder a recursos protegidos por el proxy.
Para obtener información adicional sobre esta vulnerabilidad, especialmente en relación con NGINX, consulta [**este recurso detallado**](../network-services-pentesting/pentesting-web/nginx.md#proxy\_set\_header-upgrade-and-connection).
El websocket smuggling, a diferencia de crear un túnel HTTP2 a un punto final accesible a través de un proxy, establece un túnel de Websocket para evitar posibles limitaciones del proxy y facilitar la comunicación directa con el punto final.
En este escenario, un backend que ofrece una API de Websocket pública junto con una API REST interna inaccesible es el objetivo de un cliente malicioso que busca acceder a la API REST interna. El ataque se desarrolla en varios pasos:
1. El cliente inicia enviando una solicitud de Upgrade al proxy inverso con una versión de protocolo `Sec-WebSocket-Version` incorrecta en el encabezado. El proxy, al no validar el encabezado `Sec-WebSocket-Version`, considera válida la solicitud de Upgrade y la reenvía al backend.
2. El backend responde con un código de estado `426`, indicando la versión incorrecta del protocolo en el encabezado `Sec-WebSocket-Version`. El proxy inverso, pasando por alto el estado de respuesta del backend, asume la disposición para la comunicación de Websocket y retransmite la respuesta al cliente.
3. En consecuencia, el proxy inverso es engañado para creer que se ha establecido una conexión de Websocket entre el cliente y el backend, cuando en realidad el backend ha rechazado la solicitud de Upgrade. A pesar de esto, el proxy mantiene una conexión TCP o TLS abierta entre el cliente y el backend, permitiendo al cliente acceder sin restricciones a la API REST privada a través de esta conexión.
Los proxies inversos afectados incluyen Varnish, que se negó a abordar el problema, y el proxy Envoy en la versión 1.8.0 o anterior, con versiones posteriores que han alterado el mecanismo de actualización. Otros proxies también pueden ser susceptibles.
Este escenario implica un backend con una API de Websocket pública y una API REST pública para verificación de salud, junto con una API REST interna inaccesible. El ataque, más complejo, involucra los siguientes pasos:
1. El cliente envía una solicitud POST para activar la API de verificación de salud, incluyendo un encabezado HTTP adicional `Upgrade: websocket`. NGINX, actuando como proxy inverso, interpreta esto como una solicitud de Upgrade estándar basada únicamente en el encabezado `Upgrade`, ignorando los otros aspectos de la solicitud, y la reenvía al backend.
2. El backend ejecuta la API de verificación de salud, accediendo a un recurso externo controlado por el atacante que devuelve una respuesta HTTP con el código de estado `101`. Esta respuesta, una vez recibida por el backend y reenviada a NGINX, engaña al proxy haciéndole creer que se ha establecido una conexión de Websocket debido a su validación únicamente del código de estado.
> **Advertencia:** La complejidad de esta técnica aumenta, ya que requiere la capacidad de interactuar con un punto final capaz de devolver un código de estado 101.
En última instancia, NGINX es engañado para creer que existe una conexión de Websocket entre el cliente y el backend. En realidad, no existe tal conexión; la API REST de verificación de salud era el objetivo. No obstante, el proxy inverso mantiene la conexión abierta, permitiendo al cliente acceder a la API REST privada a través de ella.
La mayoría de los proxies inversos son vulnerables a este escenario, pero la explotación depende de la presencia de una vulnerabilidad externa de SSRF, generalmente considerada como un problema de baja gravedad.
Consulta los laboratorios para probar ambos escenarios en [https://github.com/0ang3el/websocket-smuggle.git](https://github.com/0ang3el/websocket-smuggle.git)
<summary><strong>Aprende hacking en AWS desde cero hasta experto con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si deseas ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF**, ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* **Ú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).
