Un fallo limitado de inyección CRLF puede escalar hasta convertirse en un grave ataque de desincronización HTTP. Este método, denominado CRLF-Powered Desync, permite a los atacantes envenenar los cachés de las CDN y entregar cargas útiles de XSS a usuarios en sitios web legítimos. El ataque ocurre cuando una aplicación gestiona incorrectamente los caracteres de retorno de carro y salto de línea codificados (%0d%0a), los cuales definen las nuevas líneas en los mensajes HTTP.

Un fallo limitado de inyección CRLF puede escalar hasta convertirse en un ataque grave de desincronización HTTP, envenenando las cachés de CDN y entregando cargas útiles de XSS a usuarios en sitios web legítimos.

El ataque, llamado CRLF-Powered Desync, comienza cuando una aplicación maneja incorrectamente los caracteres codificados de retorno de carro y salto de línea, comúnmente representados como %0d%0a.

Estos caracteres marcan nuevas líneas en los mensajes HTTP. Si un servidor front-end los decodifica antes de reenviar una solicitud a un servidor back-end, un atacante podría inyectar nuevas cabeceras HTTP o alterar la estructura de la solicitud ascendente.

Una configuración riesgosa involucra los despliegues de Nginx que colocan variables como $uri en directivas proxy_pass. Nginx puede normalizar y decodificar la URL de la ruta antes de reenviarla al servidor superior.

El Desync CRLF envenena las cachés de CDN

Esto puede convertir secuencias CRLF codificadas en saltos de línea reales, permitiendo la inyección de cabeceras de solicitud. El desajuste resultante entre cómo las diferentes capas de infraestructura interpretan la misma solicitud puede crear una condición de contrabando de solicitudes HTTP, o desincronización (desync).

En un ataque de desincronización, un proxy front-end y una aplicación back-end no se ponen de acuerdo sobre dónde termina una solicitud HTTP y dónde comienza la siguiente. Los atacantes pueden usar esta confusión para insertar una solicitud adicional en una conexión compartida.

Las respuestas destinadas a un usuario pueden ser entregadas a otro, provocando confusiones de cuentas, exposición de datos sensibles, denegación de servicio o envenenamiento de caché. Los investigadores demostraron que el problema puede volverse especialmente peligroso dentro de la infraestructura de una CDN.

En un caso, el envenenamiento de la cola de respuestas pareció ocurrir en la capa de la CDN en lugar de solo dentro de una aplicación objetivo. Esto creó el riesgo de que las solicitudes y respuestas de sitios no relacionados alojados en la misma infraestructura de CDN pudieran mezclarse.

Tales incidentes pueden exponer cookies de sesión, tokens de autorización y otros datos sensibles si falla el aislamiento de la conexión. Un escenario más impactante implicó envenenar una página almacenada en la caché de una CDN y convertir el contenido almacenado en un mecanismo de entrega de XSS.

Al combinar un desync CL.TE impulsado por CRLF con un comportamiento de solicitud HEAD cuidadosamente seleccionado, los investigadores pudieron hacer que una CDN almacenara en caché una respuesta maliciosa.

El recurso envenenado podría entonces ser servido a usuarios reales, permitiendo que JavaScript controlado por el atacante se ejecute en el contexto de su navegador. La investigación también advierte que estos ataques pueden ser compatibles con los navegadores.

En algunos casos, la navegación normal del navegador o las solicitudes fetch() de JavaScript pueden transportar los datos codificados necesarios para activar la desincronización. Si un atacante logra un XSS en una página vista por la víctima, el navegador de esta podría lanzar repetidamente las mismas solicitudes maliciosas, creando un "gusano de desincronización" autopropagable.

Tú y tu organización deberían tratar la inyección de CRLF y de cabeceras de solicitud como hallazgos de alta gravedad, en lugar de simples problemas menores de validación de entrada.

Como defensor, deberías revisar las reglas de proxy inverso, evitar el uso de variables URI decodificadas en las directivas proxy_pass y return de Nginx, y asegurarte de que cada capa de la pila aplique reglas de análisis HTTP consistentes.

Tú y tu equipo también deberían probar juntos el comportamiento de la CDN, el equilibrador de carga, el proxy y el servidor de origen, ya que los fallos más graves surgen de las diferencias de análisis entre estas capas.

Mover el tráfico ascendente a HTTP/2 donde sea práctico, aislar las conexiones del back-end, rechazar los caracteres de control codificados prematuramente y realizar pruebas regulares de contrabando de solicitudes puede reducir significativamente la exposición.

La lección principal es sencilla: una sola secuencia CRLF inyectada puede convertirse en un riesgo de XSS y envenenamiento de caché en toda la infraestructura cuando los componentes HTTP no coinciden en los límites de la solicitud.

Fuentes:
https://cybersecuritynews.com/crlf-powered-desync-attack/