Errores de implementación de HTTP / 2 que exponen los sitios web a …



Las organizaciones que no implementan HTTP / 2 de un extremo a otro son vulnerables a los ataques que redirigen a los usuarios a sitios maliciosos y otras amenazas, revela un investigador de seguridad de Black Hat United states.

BLACK HAT United states 2021 – Las fallas de implementación y las imperfecciones en las especificaciones técnicas en torno a HTTP / 2 están exponiendo a los sitios world-wide-web que usan el protocolo de pink a un nuevo conjunto de riesgos, advirtió un investigador de seguridad en una presentación en Black Hat United states of america el jueves.

James Kettle, director de investigación de PortSwigger, que en Black Hat demostró durante dos años los llamados ataques Desync contra sitios internet que utilizan el protocolo HTTP, mostró esta semana cómo se podrían llevar a cabo ataques similares con consecuencias potencialmente graves contra los sitios website que utilizan HTTP / 2. estándar.

Como prueba de concepto, Kettle describió los ataques que pudo ejecutar usando sus técnicas contra sitios website pertenecientes a organizaciones como Netflix, aquellos impulsados ​​por el balanceador de carga de aplicaciones de Amazon y sitios world wide web que utilizan el firewall de aplicaciones net en la nube de Imperva. En muchos casos, pudo redirigir las solicitudes de los servidores website en estos sitios a su propio servidor.

Casi el 50% de todos los sitios net utilizan actualmente el protocolo HTTP / 2 (H2), que se introdujo en 2015 como una alternativa más rápida y sencilla a HTTP / 1.1. Como Google lo explain, «todos los conceptos básicos, como métodos HTTP, códigos de estado, URI y campos de encabezado, permanecen en su lugar» con el nuevo protocolo. «En cambio, HTTP / 2 modifica la forma en que los datos se formatean (enmarcan) y se transportan entre el cliente y el servidor, los cuales administran todo el proceso y oculta toda la complejidad de nuestras aplicaciones dentro de la nueva capa de encuadre».

Según Kettle, pueden surgir una gran cantidad de problemas de seguridad cuando las organizaciones no utilizan HTTP / 2 de un extremo a otro. En su lugar, tienen un servidor de aplicaciones para el usuario que habla HTTP / 2 con los clientes y luego reescribe las solicitudes de esos clientes a HTTP / 1.1 antes de reenviarlas a un servidor de servicios de fondo.

«La gran mayoría de los servidores que hablan HTTP / 2 en realidad hablan HTTP / 1 al back-end», dijo durante su charla sobre Black Hat. Hablan H2 con el cliente y H1 con el back-finish, dijo Kettle.

«Esta configuración es ridículamente común», señaló. Kettle señaló al Application Load Balancer de Amazon, por ejemplo, donde esta comunicación no se puede deshabilitar. Tales degradaciones HTTP / 2 y traducciones de protocolos brindan a los atacantes una forma de llevar a cabo ataques Desync, dijo Kettle.

Los ataques HTTP Desync básicamente abusan de las debilidades en cómo los servidores back again-finish interpretan y responden a solicitudes consecutivas de un servidor front-stop, balanceador de carga o servidor proxy. Por ejemplo, los servidores de aplicaciones para el usuario que hablan HTTP / 2 siguen un formato específico para transmitir la longitud del mensaje al servidor de servicios de fondo. Pero un servidor de fondo que solo habla HTTP / 1.1 no reconocerá los datos porque obtiene información sobre la longitud de una solicitud a través de otros métodos.

Los atacantes pueden aprovechar los desacuerdos sobre la longitud del mensaje entre el servidor de aplicaciones para el usuario y el servidor de servicios de fondo para esencialmente interferir con la forma en que una aplicación puede manejar las solicitudes.

Objetivos de alto perfil
Para mostrar cómo funcionaría un ataque de este tipo, Kettle señaló un exploit que ejecutó contra Netflix en el que los servidores de aplicaciones para el usuario realizaban una degradación de HTTP sin verificar la longitud de las solicitudes. La vulnerabilidad permitió a Kettle desarrollar un exploit que activó el again-finish de Netflix para redirigir las solicitudes del entrance-stop de Netflix a su propio servidor. Eso permitió a Kettle ejecutar potencialmente código malicioso para comprometer las cuentas de Netflix, robar contraseñas de usuarios, información de tarjetas de crédito y otros datos. Netflix reparó la vulnerabilidad y le otorgó a Kettle su recompensa máxima de $ 20,000 por informarlo a la compañía.

En otro caso, Kettle descubrió que Application Load Balancer de Amazon no había implementado una especificación HTTP / 2 con respecto a cierta información de encabezado de mensaje que HTTP / 1.1 united states of america para derivar las longitudes de las solicitudes. Con esta vulnerabilidad, Kettle pudo mostrar cómo un atacante podría aprovecharla para redirigir las solicitudes de los servidores de aplicaciones para el usuario a un servidor controlado por el atacante. Encontró un portal de acceso vulnerable para las fuerzas del orden mientras usaba el equilibrador de carga de Amazon.

Casi todos los sitios net que usaban el equilibrador de carga de Amazon eran vulnerables a la explotación, dijo Kettle. También lo period un CMS que impulsaba varios sitios de noticias como Huffington Post, y todos los sitios website que usaban un WAF Imperva, agregó.

Durante su presentación, Kettle destacó varios otros exploits que había desarrollado para aprovechar las vulnerabilidades que surgen cuando las organizaciones degradan HTTP / 2 a HTTP. También lanzó una versión actualizada de HTTP Request Smuggler, una herramienta que las organizaciones pueden usar para detectar vulnerabilidades específicas de HTTP / 2 en su red. El escáner de vulnerabilidades Burp Suite también se ha actualizado para detectar estas vulnerabilidades, dijo Kettle.

«Por favor, evite la degradación de HTTP / 2», aconsejó. «Simplemente hable HTTP / 2 de un extremo a otro. Si lo hace, aproximadamente el 80% de los ataques de esta presentación simplemente no funcionarán».

Jai Vijayan es un reportero de tecnología experimentado con más de 20 años de experiencia en el periodismo comercial de TI. Más recientemente, fue editor senior en Computerworld, donde cubrió temas de seguridad de la información y privacidad de datos para la publicación. En el transcurso de sus 20 años … Ver biografía completa

Lectura recomendada:

Más información





Enlace a la noticia initial