Español - Ht
HackTricks Training Twitter Linkedin Sponsor

Upgrade Header Smuggling

Aprende hacking en AWS desde cero hasta convertirte en un experto con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

Grupo de Seguridad Try Hard

H2C Smuggling

HTTP2 sobre texto sin formato (H2C)

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:

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 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.

Proxies Vulnerables

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:

  • HAProxy

  • Traefik

  • Nuster

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:

  • AWS ALB/CLB

  • NGINX

  • Apache

  • Squid

  • Varnish

  • Kong

  • Envoy

  • Apache Traffic Server

Explotación

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 y h2csmuggler de assetnote 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.

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 de Websocket para evitar 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 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.

Escenario 2

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.

Laboratorios

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

Referencias

Try Hard Security Group

Aprende hacking en AWS desde cero hasta experto con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

AnteriorHTTP Response Smuggling / DesyncSiguientehop-by-hop headers

Última actualización