# Upgrade Header Smuggling {% hint style="success" %} Learn & practice AWS Hacking:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\ Learn & practice GCP Hacking: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Support HackTricks * Check the [**subscription plans**](https://github.com/sponsors/carlospolop)! * **Join the** 馃挰 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 馃惁 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.** * **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
{% endhint %} ### H2C Smuggling #### HTTP2 Over Cleartext (H2C) H2C, o **http2 sobre texto claro**, 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, a diferencia de la naturaleza de solicitud 煤nica del HTTP en texto claro. El n煤cleo 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: ``` Upgrade: h2c HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA Connection: Upgrade, HTTP2-Settings ``` La vulnerabilidad surge cuando, despu茅s de actualizar una conexi贸n, el proxy inverso deja de gestionar solicitudes individuales, asumiendo que su trabajo de enrutamiento est谩 completo tras el establecimiento de la conexi贸n. Explotar H2C Smuggling permite eludir las reglas del proxy inverso aplicadas durante el procesamiento de solicitudes, como el enrutamiento basado en rutas, la autenticaci贸n y el procesamiento de WAF, asumiendo que se inicia con 茅xito una conexi贸n H2C. #### Proxies Vulnerables La vulnerabilidad depende del manejo de los encabezados `Upgrade` y a veces `Connection` por parte del proxy inverso. Los siguientes proxies reenv铆an inherentemente estos encabezados durante el proxy-pass, habilitando as铆 H2C smuggling: * HAProxy * Traefik * Nuster Por el contrario, estos servicios no reenv铆an inherentemente ambos encabezados durante el proxy-pass. Sin embargo, pueden configurarse de manera insegura, permitiendo el reenv铆o sin filtrar de los encabezados `Upgrade` y `Connection`: * AWS ALB/CLB * NGINX * Apache * Squid * Varnish * Kong * Envoy * Apache Traffic Server #### Explotaci贸n Es crucial notar que no todos los servidores reenv铆an inherentemente los encabezados requeridos para una actualizaci贸n de conexi贸n H2C conforme. Como tal, 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 ajustarse a los est谩ndares. {% hint style="danger" %} Independientemente de la **ruta** espec铆fica designada en la URL `proxy_pass` (por ejemplo, `http://backend:9999/socket.io`), la conexi贸n establecida se predetermina a `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. {% endhint %} Las herramientas [**h2csmuggler by BishopFox**](https://github.com/BishopFox/h2csmuggler) y [**h2csmuggler by assetnote**](https://github.com/assetnote/h2csmuggler) facilitan los intentos de **eludir las protecciones impuestas por el proxy** al establecer una conexi贸n H2C, permitiendo as铆 el acceso a recursos protegidos por el proxy. Para obtener informaci贸n adicional sobre esta vulnerabilidad, particularmente en relaci贸n con NGINX, consulte [**este recurso detallado**](../network-services-pentesting/pentesting-web/nginx.md#proxy\_set\_header-upgrade-and-connection). ## Websocket Smuggling 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 Websocket para eludir posibles limitaciones del proxy y facilitar la comunicaci贸n directa con el punto final. ### Escenario 1 En este escenario, un backend que ofrece una API WebSocket p煤blica junto con una API REST interna inaccesible es objetivo de un cliente malicioso que busca acceso a la API REST interna. El ataque se desarrolla en varios pasos: 1. El cliente inicia enviando una solicitud 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`, cree que la solicitud Upgrade es v谩lida y la reenv铆a al backend. 2. El backend responde con un c贸digo de estado `426`, indicando la versi贸n de protocolo incorrecta en el encabezado `Sec-WebSocket-Version`. El proxy inverso, ignorando el estado de respuesta del backend, asume que est谩 listo para la comunicaci贸n WebSocket y reenv铆a la respuesta al cliente. 3. En consecuencia, el proxy inverso es enga帽ado para creer que se ha establecido una conexi贸n WebSocket entre el cliente y el backend, mientras que en realidad, el backend hab铆a rechazado la solicitud 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 la versi贸n 1.8.0 o anterior del proxy Envoy, con versiones posteriores que han alterado el mecanismo de actualizaci贸n. Otros proxies tambi茅n pueden ser susceptibles. ![https://github.com/0ang3el/websocket-smuggle/raw/master/img/2-4.png](https://github.com/0ang3el/websocket-smuggle/raw/master/img/2-4.png) ### Escenario 2 Este escenario involucra un backend con una API WebSocket p煤blica y una API REST p煤blica para verificaci贸n de estado, junto con una API REST interna inaccesible. El ataque, m谩s complejo, implica los siguientes pasos: 1. El cliente env铆a una solicitud POST para activar la API de verificaci贸n de estado, incluyendo un encabezado HTTP adicional `Upgrade: websocket`. NGINX, actuando como el proxy inverso, interpreta esto como una solicitud de actualizaci贸n est谩ndar basada 煤nicamente en el encabezado `Upgrade`, descuidando otros aspectos de la solicitud, y la reenv铆a al backend. 2. El backend ejecuta la API de verificaci贸n de estado, contactando un recurso externo controlado por el atacante que devuelve una respuesta HTTP con 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 WebSocket debido a su validaci贸n solo del c贸digo de estado. ![https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-4.png](https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-4.png) > **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 WebSocket entre el cliente y el backend. En realidad, no existe tal conexi贸n; la API REST de verificaci贸n de estado fue el objetivo. Sin embargo, el proxy inverso mantiene la conexi贸n abierta, permitiendo al cliente acceder a la API REST privada a trav茅s de ella. ![https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-5.png](https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-5.png) La mayor铆a de los proxies inversos son vulnerables a este escenario, pero la explotaci贸n depende de la presencia de una vulnerabilidad SSRF externa, generalmente considerada como un problema de baja gravedad. #### Laboratorios Verifique los laboratorios para probar ambos escenarios en [https://github.com/0ang3el/websocket-smuggle.git](https://github.com/0ang3el/websocket-smuggle.git) ### Referencias * [https://blog.assetnote.io/2021/03/18/h2c-smuggling/](https://blog.assetnote.io/2021/03/18/h2c-smuggling/) * [https://bishopfox.com/blog/h2c-smuggling-request](https://bishopfox.com/blog/h2c-smuggling-request) * [https://github.com/0ang3el/websocket-smuggle.git](https://github.com/0ang3el/websocket-smuggle.git) {% hint style="success" %} Aprende y practica Hacking en AWS:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\ Aprende y practica Hacking en GCP: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Apoya a HackTricks * 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** 馃惁 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.** * **Comparte 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.
{% endhint %}