Inicio / Para Expertos / Investigador demuestra 4 nuevas variantes del ataque del tipo HTTP Request Smuggling

Investigador demuestra 4 nuevas variantes del ataque del tipo HTTP Request Smuggling

Una nueva investigación ha identificado cuatro nuevas variantes de ataques HTTP Request Smuggling que funcionan contra varios servidores web comerciales y servidores proxy HTTP.

Amit Klein, vicepresidente de investigación de seguridad de SafeBreach, quien presentó los hallazgos hoy en la conferencia de seguridad de Black Hat, dijo que los ataques destacan cómo los servidores web y los servidores proxy HTTP siguen siendo susceptibles al HTTP Request Smuggling incluso después de 15 años desde que se documentaron por primera vez.

¿Qué es el HTTP Request Smuggling?

El HTTP Request Smuggling (o desincronización HTTP) es una técnica empleada para interferir con la forma en que un sitio web procesa secuencias de solicitudes HTTP que se reciben de uno o más usuarios.

Las vulnerabilidades relacionadas con HTTP Request Smuggling generalmente surgen cuando el front-end (un equilibrador de carga o proxy) y los servidores back-end interpretan el límite de una solicitud HTTP de manera diferente, lo que permite que un atacante envíe una solicitud ambigüeda que se antepone a la siguiente solicitud de usuario legítima.

Esta desincronización de solicitudes puede explotarse para secuestrar credenciales, inyectar respuestas a los usuarios e incluso robar datos de la solicitud de una víctima y filtrar la información a un servidor controlado por el atacante.

La técnica fue demostrada por primera vez en 2005 por un grupo de investigadores de Watchfire, incluidos Klein, Chaim Linhart, Ronen Heled y Steve Orrin. Pero en los últimos cinco años, se han ideado una serie de mejoras, expandiéndose significativamente en la superficie de ataque para empalmar las solicitudes en otros y “obtener el máximo acceso de privilegio a las API internas”, envenenar cachés web y comprometer páginas de inicio de sesión de aplicaciones populares.

¿Qué hay de nuevo?

Las nuevas variantes reveladas por Klein implican el uso de varias combinaciones de servidor proxy, incluidos Aprelium’s Abyss, Microsoft IIS, Apache y Tomcat en el modo de servidor web, y Nginx, Squid, HAProxy, Caddy y Traefik en el modo de proxy HTTP.

La lista de las cuatro nuevas variantes nuevas es la siguiente, incluida una antigua que el investigador explotó con éxito en sus experimentos.

  • Variante 1: “Header SP/CR junk: …”
  • Variante 2 – “Wait for It”
  • Variante 3: HTTP / 1.2 para evitar la defensa similar a mod_security
  • Variante 4 – a plain solution.
  • Variante 5 – “CR header”

Cuando se manejan solicitudes HTTP que contienen dos campos de encabezado Content-Length, Abyss, por ejemplo, acepta el segundo encabezado como válido, mientras que Squid usa el primer encabezado Content-Length, lo que lleva a los dos servidores a interpretar las solicitudes de manera diferente y lograr el Request Smuggling.

En situaciones en las que Abyss recibe una solicitud HTTP con un cuerpo cuya longitud es menor que el valor de Content-Length especificado, espera 30 segundos para completar la solicitud, pero no antes de ignorar el cuerpo restante de la solicitud. Klein descubrió que esto también genera discrepancias entre Squid y Abyss, y este último interpreta porciones de la solicitud HTTP saliente como una segunda solicitud.

Una tercera variante del ataque usa HTTP / 1.2 para eludir las defensas WAF como se define en el Conjunto de reglas centrales de OWASP ModSecurity (CRS) para prevenir ataques de HTTP Request Smuggling que crean una carga maliciosa que desencadena el comportamiento.

Por último, Klein descubrió que usar el campo de encabezado “Content-Type: text / plain” era suficiente para evitar las comprobaciones de nivel 1 y 2 especificadas en CRS y generar una vulnerabilidad de HTTP Request Smuggling.

¿Cuáles son las posibles defensas?

Después de que los hallazgos fueron revelados a Aprelium, Squid y OWASP CRS, los problemas se solucionaron en Abyss X1 v2.14, Squid versiones 4.12 y 5.0.3 y CRS v3.3.0.

Al pedir la normalización de las solicitudes HTTP salientes de los servidores proxy, Klein enfatizó la necesidad de una solución de firewall de aplicación web robusta y de código abierto que sea capaz de manejar los ataques de HTTP Request Smuggling.

“ModSecurity (combinado con CRS) es de hecho un proyecto de código abierto, pero en cuanto a robustez, mod_security tiene varios inconvenientes”, señaló Klein. “No proporciona protección completa contra el HTTP Request Smuggling [y] solo está disponible para Apache, IIS y nginx”.

Con este fin, Klein ha publicado una biblioteca basada en C ++ que garantiza que todas las solicitudes HTTP entrantes sean completamente válidas, compatibles y sin ambigüedades al aplicar estrictamente el formato de encabezado HTTP y el formato de línea de solicitud. Se puede acceder desde GitHub aquí.

Vea También

Pruebas de penetración de cajeros automáticos: métodos de prueba avanzados para encontrar las vulnerabilidades

Pruebas de penetración de cajeros automáticos, los piratas informáticos han encontrado diferentes enfoques para piratear …

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.