IMPORTANTE: esta vulnerabilidad afecta directamente a las webs de empresas y usuarios. Por ello, antes de hacer pública la vulnerabilidad, así como este artículo que la describe, hemos hecho un reporte de forma responsable, a través de la notificación previa a las empresas afectadas por la vulnerabilidad, y otorgando un tiempo prudencial para solventarla.

Cada vez hay más empresas, organizaciones y usuarios que se preocupan por la seguridad de los productos y servicios digitales.

Por desgracia, esta concienciación surge cuando ya se ha sufrido algún tipo de ataque o ciberincidencia en el que se han visto comprometidos los sistemas de las empresas.

Por si fuera poco, la complejidad de la tecnología hace que en casi todas las aplicaciones existan errores que pueden ser explotados por atacantes para extorsionar, o bien para realizar ataques dirigidos, más sofisticados y por tanto, con mayores probabilidades de éxito.

Esos errores están presentes en las aplicaciones y si no lo estarán en el futuro pues aparecen durante el desarrollo de las herramientas digitales. Por ello, aunque en la actualidad se solventan muchos fallos de seguridad, siempre aparecen nuevas brechas.

A la hora de explotar estas brechas, las inyecciones SQL son uno de los ataques más frecuentes. Por ello han proliferado diversas soluciones que evitan la infiltración de código malicioso en páginas y aplicaciones web.

Según el informe “Web Application Attacks Statistics”, durante el 2017, el sector IT y financiero sufrieron gran parte de los ataques dirigidos a aplicaciones web: más de 900 ataques al día.

La solución de la que vamos a hablar a continuación es la más utilizada en el mundo por parte de empresas y organizaciones que buscan mitigar la explotación de estas vulnerabilidades en sus aplicaciones web. Se trata del Web Application Firewall, también conocido como WAF.

Qué es un WAF | Open Data Security

¿Qué es un WAF?

Un WAF es un servicio que procesa y analiza todas las solicitudes que van dirigidas a la aplicación web. El WAF bloquea toda petición identificada como maliciosa dirigida al servidor de la aplicación, dejando pasar así al resto.

Según de qué manera esté configurando el WAF, puede llegar a bloquear la IP desde la que se ha originado la petición maliciosa para evitar futuros ataques desde ella.

Para poder separar peticiones maliciosas de las legítimas, el WAF analiza las diferentes partes que componen una petición a un recurso web. Algunas de esas partes son las cabeceras, parámetros y cuerpo de la consulta, entre otros.

Durante ese análisis, se buscan patrones que coincidan con los de un ataque. Por ejemplo: referencias a rutas de ficheros que contienen configuraciones del sistema, o inyecciones de código que permiten alterar consultas realizadas a la base de datos para lograr extraer información sensible.

Problemas habituales de los WAF

Por un lado, entre los principales problemas que nos encontramos en el uso de los WAF están los falsos positivos. Se trata de solicitudes legítimas que por alguna razón son bloqueadas y hacen que la aplicación deje de funcionar.

Por otro lado, los WAF generan una falsa sensación de seguridad entre los desarrolladores, administradores de sistemas y personal que se encarga de la seguridad de las empresas y organizaciones. Se descuidan protocolos de seguridad y se dejan de tomar medidas preventivas que cada vez son más necesarias como las auditorías de código e infraestructura.

Como cualquier otra aplicación, los WAF no están exentos de errores. En este caso, lo grave es que si falla el WAF, tu aplicación está expuesta a ataques tal y como vamos a demostrar a continuación.

Vulnerabilidades de los WAF

Basta con echar un vistazo a los WAF de código abierto disponibles en Internet para comprobar que se utiliza Nginx como una de las soluciones más extendidas para la implementación de WAF.

Nginx es un servidor web que se encarga de procesar las solicitudes web. Es una herramienta estable y versátil que permite a los desarrolladores centrarse en la implementación del WAF a través de diferentes scripts escritos en LUA.

En la mayoría de estos WAF de código abierto se da el mismo error: no tienen en cuenta que el módulo encargado de la integración de LUA en Nginx (lua-nginx-module) no permite el acceso a toda la información de la solicitud.

Esto no es algo nuevo, de hecho es una información que está reflejada en la documentación del módulo:

“Note that a maximum of 100 request arguments are parsed by default (including those with the same name) and that additional request arguments are silently discarded to guard against potential denial of service attacks”.

Dicho de otra manera: por muy efectivo que sea en la detección de ataques, hay ciertos datos que son invisibles para el WAF. Si logramos que los parámetros que contienen datos maliciosos queden fuera del ámbito al cual tiene acceso el WAF, este quedará totalmente inutilizado.

Para comprobarlo, hemos visto que el WAF lua-resty-waf puede bloquear la siguiente solicitud la cual contiene una inyección de código SQL:

http://example.com/?param=’ OR 1=1 – –

En cambio, cuando la misma solicitud contiene muchos parámetros, la inyección es invisible para el WAF y por lo tanto, no es bloqueada:

http://example.com/?param=&param=&param=…&param=’ OR 1=1 – –

Lo cierto es que esto no es ningún descubrimiento. Esta caracteristica es controvertida, sobre ella se ha discutido desde hace tiempo y en Internet se pueden encontrar referencias a ellas entre los reportes enviados a los repositorios de código de estas soluciones.

Tenemos que pensar que hasta ahora hemos analizado los WAF de código abierto, es decir, aquellos que han sido desarrollados de forma desinteresada y por supuesto sin garatía de un correcto funcionamiento.

Pero, ¿qué ocurre con los proveedores de WAF comerciales que ofrecen productos de pago y prometen una defensa casi perfecta de sus servicios? Veamos.

Vulnerabilidades, también en los WAF de pago

CloudFlare y Cloudbric son dos conocidos proveedores que ofrecen productos con protección a través de WAF. Durante las pruebas realizadas, hemos encontrado la misma vulnerabilidad en los productos que ambas empresas comercializan. Eso los convierten en vulnerables y expone las aplicaciones de sus clientes a posibles ataques.

Hay que decir que en el caso de Cloudbric es necesario cambiar el valor de algún parámetro en cada solicitud para explotar esta vulnerabilidad.

En el siguiente vídeo, podrás comprobar cómo al añadir más parámetros, el WAF de CloudFlare no es capaz de detectar y bloquear la solicitud maliciosa:

Como habrás visto, esta vulnerabilidad se da a la hora de analizar los datos de entrada, tanto con parámetros GET, POST o con las cabeceras de la solicitud.

Solución a la vulnerabilidad de los WAF

La vulnerabilidad de los WAF fue descubierta al poner a prueba el WAF de Wolf-Ray, la capa de protección que hemos desarrollado en Open Data Security para proteger los recursos externos de las empresas y securizar los recursos expuestos a Internet.

Al descubrir que el WAF es vulnerable a los ataques descritos, decidimos indagar un poco más y encontrar la causa del error. De esta manera, hemos localizado otros productos comerciales que sufren el mismo problema.

Para solucionar la vulnerabilidad de los WAF e implementar esta mejora en Wolf-Ray, hemos barajado múltiples posibilidades. Finalmente, nos hemos decantado por recompilar lua-nginx-module con un nuevo límite de variables a procesar ajustándolo a un nivel que no interfiriera en el normal funcionamiento de las aplicaciones de nuestros clientes.

De esta manera, el WAF de Wolf-Ray protege los recursos web ya que bloquea cualquier solicitud que exceda del nuevo límite que hemos impuesto. Sin ese límite, no podemos asegurar la legitimidad de los datos que son enviados a los servidores finales.

Para más información, visita la web: Wolf-Ray.