Los WAF (Web Application Firewall, firewall de aplicaciones web) son una parte crucial de la infraestructura de seguridad de cualquier servicio o aplicación basado en la web y protegen de ataques que pueden causar daños financieros y de reputación. Por ello, las formas de eludir la capacidad de filtrado y bloqueo de un WAF son muy buscadas por los ciberdelincuentes.
En diciembre de 2022 hablamos sobre uno de estos ataques, un bypass descubierto por Team82, el equipo de investigación de seguridad de Claroty. Este afectó a múltiples WAF de varios proveedores populares, pero el WAF de Azion fue inmune al ataque de bypass.
Ahora, los investigadores de seguridad de Praetorian han encontrado otro bypass1, que afecta al WAF de Akamai (y puede que este no sea el único vulnerable). Los investigadores afirman: “No queremos que nuestro artículo destaque a Akamai en particular. Más bien, sospechamos que los atacantes podrían usar técnicas de evasión similares contra prácticamente cualquier firewall de aplicaciones web del mercado”.
De nuestra parte y tras una evaluación interna, podemos afirmar con confianza que el WAF de Azion no es vulnerable ante este nuevo tipo de ataque.
Cómo funciona el ataque
Según Praetorian, se trata de un ataque de inyección de CRLF. Este tipo de ataque ocurre cuando “una aplicación no filtra correctamente y devuelve un encabezado de respuesta HTTP que incluye una entrada de usuario controlada por el atacante. Este tipo de vulnerabilidad permite que un agresor inserte caracteres de retorno de carro (CR, Carriage Return, comúnmente representado por la secuencia ‘\r’) y de salto de línea (LF, Line Feed, representado por la secuencia ‘\n’) en el cuerpo de la respuesta HTTP”.
Como resultado, un atacante puede “terminar controlando tanto los encabezados HTTP como los datos en el cuerpo de la respuesta HTTP. Además, este problema puede generar otras vulnerabilidades, como Cross-Site Scripting (XSS) y redirección abierta (Open Redirect)“.
Los ingenieros intentaron además explotar la vulnerabilidad agregando la carga útil <script>alert(“XSS”)</script> en el cuerpo de la respuesta HTTP. Sin embargo, el WAF lo bloqueó correctamente, ya que sus reglas detectaron la etiqueta <script>.
¿Qué se podría hacer para evitar la detección? Ofuscar. “Adoptamos la hipótesis de que podríamos inyectar un encabezado usando la inyección CRLF para especificar que el cuerpo de la respuesta HTTP estaba comprimido”, dijeron los ingenieros. “En ese caso, no necesitaríamos modificar nuestra payload XSS, ya que usamos la compresión para eludir las reglas del WAF”.
Eligieron el algoritmo de compresión deflate e inyectaron un encabezado Content-Encoding que especificaba eso. También, agregaron un encabezado Content-Length que especificaba el tamaño exacto del encabezado comprimido, y el experimento funcionó.
Según los ingenieros, esta técnica es digna de elogio porque “encadenar una inyección CRLF para generar cross-site scripting y evadir a un firewall de aplicaciones web mediante la inyección de datos comprimidos en el cuerpo de respuesta es un enfoque innovador. No tenemos conocimiento de otro artículo que aborde dicho método”.
¿Por qué el WAF de Azion no se ve afectado?
Tras ser informado del ataque, nuestro equipo de seguridad efectuó la prueba de concepto presentada por Praetorian contra el propio Web Application Firewall de Azion.
Se realizaron dos pruebas en un entorno controlado utilizando nuestro WAF. El equipo de seguridad usó una herramienta de tests de seguridad llamada Burp Suite Professional que ejecuta ataques simulados. Este software permite a un investigador enviar diferentes tipos de solicitudes a un sistema, así como validar su comportamiento y respuestas.
En el primer test simulamos a un atacante adicionando un carácter de salto de línea URL-encoded (%0a) a la solicitud GET para definir una cookie (usando la instrucción Set-Cookie) con el par clave-valor “crlf=injection”. Como podemos ver en el campo de Respuesta, la instrucción no fue interpretada y la cookie no se definió.
Imagen: Azion Technologies
En el segundo test, nuevamente inyectamos un CRLF en la solicitud GET (no visible en la imagen a continuación) para configurar de manera fraudulenta los encabezados Content-Type, Content-Encoding y Content-Length. Sin embargo, el intento fue bloqueado con éxito por el WAF de Azion, que devolvió el código de estado HTTP 400 (Bad Request).
Imagen: Azion Technologies
Conclusión
Los resultados obtenidos en ambos tests prueban nuevamente la efectividad del WAF de Azion para proteger a nuestros clientes de las amenazas de día cero. Según Marcos R. Carvalho, Security Arquitect de Azion: “Esto se hizo usando las reglas estándar de Azion y su algoritmo de clasificación patentado, sin necesidad de expresiones regulares adicionales”.
Regístrate gratis y descubre cómo Web Application Firewall de Azion puede ayudarte a proteger tus aplicaciones y servicios contra diversos tipos de amenazas o comunícate con nuestros experts para obtener más detalles.
Referencias
1 Bypassing Akamai’s Web Application Firewall Using an Injected Content-Encoding Header
