Analizando el WAF de Imperva (SecureSphere)

Recientemente en Hacktimes hemos podido analizar y probar uno de los Firewalls de Aplicaciones Web (WAF) más reconocidos del mercado: SecureSphere de Imperva. Le hemos sometido a todo tipo de pruebas, hemos revisado la seguridad del propio equipo, analizado el nivel de detección y de falsos positivos así como falsos negativos (lo que no detecta), trasteado con todas las funcionalidades que ofrece el dispositivo, etc. Muy divertido a la vez que interesante y lo que viene a continuación son los principales resultados y las conclusiones más importantes.

Un Firewall de Aplicaciones Web o comúnmente conocido como WAF es un dispositivo de seguridad que analiza el tráfico Web controlando las entradas, respuestas y/o los diferentes accesos HTTP que se producen en una determinada página. Funciona mediante el seguimiento de dicha página o aplicación Web para bloquear la entrada o salida de las llamadas al sistema que no cumplan con la política definida y configurada en el WAF. Por lo general, dicha política se refiere a ataques en la aplicación (nivel 7 de la capa OSI) del tipo Cross Site Scripting (XSS), Inyección SQL (SQLi), Remote y Local File Inclusion (LFI), etc. Es decir, un WAF trata de proteger a un servidor Web de los ataques que un Firewall y/o un IDS/IPS no pueden bloquear.

La instalación de un WAF como mecanismo de seguridad es altamente recomendable porque:

1. Un Firewall únicamente puede detectar ataques de red ya que sólo inspecciona direcciones IP ya sea de origen o destino, determinados puertos y servicios, etc. Lo que intenta es mantener a un posible atacante fuera del perímetro de nuestra red pero el servidor Web está abierto al exterior y, por tanto, fuera ya del perímetro protegido.


2. Un IDS/IPS o un Firewall de nueva generación se basa en firmas conocidas sin entender el funcionamiento de la aplicación y no es capaz de reconocer tendencias como, por ejemplo, un número determinado de eventos concretos, altas tasas de falsos positivos o, simplemente, analizar la trazabilidad del usuario que se ha conectado a la página Web en cuestión.

SecureSphere de Imperva es uno de los WAFs más extendidos y utilizados del mercado. SecureSphere proporciona protección para aplicaciones Web basada en diferentes capas de defensa (firmas, correlación, ThreatRadar, etc.) y de forma transparente adaptable a casi cualquier entorno con una sencilla y potente gestión centralizada. Con SecureSphere se revisa el protocolo HTTP para detectar cualquier violación del mismo, dispone de más de 6500 firmas que se actualizan semanalmente, también es capaz de detectar un uso anómalo de la aplicación y evita filtraciones de información sensible en la página Web, además, dispone del módulo denominado ThreatRadar para detener a un usuario malintencionado antes de que se lance un ataque según parámetros de reputación de la dirección IP de ese usuario y/o del posible origen desde el que pretende lanzar el ataque.

La instalación de SecureSphere analizada es una configuración tipo con un único equipo (appliance X2500) que agrupa el WAF y el servidor de Gestión desde donde se configura de forma centralizada el dispositivo y que es el que distribuye las nuevas firmas y el resto de actualizaciones existentes. La forma de integrarlo en nuestra red ha sido de forma transparente como “Bridge Transparente Inline” que no implica ningún cambio en el entorno y facilita todo el proceso de aprendizaje y despliegue de la plataforma. La versión revisada es la 9.5.0.2 Enterprise Edition que está preparada para proteger una única página Web de muestra donde realizaremos todo tipo de simulaciones y pruebas para analizar la respuesta y el nivel de detección y bloqueo del sistema, en función de la política definida.

La gestión del equipo se realiza mediante un interface Web que es accesible previo proceso de autenticación. También permite acceso por SSH y línea de comandos ya que se trata de una distribución Linux como se puede observar en la siguiente captura de pantalla:

Linux IMPERVA 2.6.18-164.15.1.el5.imp1 #1 SMP Tue Apr 27 20:46:55 IDT 2010 x86_64 x86_64 x86_64 GNU/Linux

En el acceso por SSH dispone de dos CLI (Common Line Interface) uno como usuario y otro como root o administrador del equipo. La plataforma es un Linux Red Hat Enteprise 5 (RHEL) especialmente configurado por la gente de Imperva para prestar el servicio de WAF. La seguridad del equipo es correcta a pesar de disponer de versiones algo antiguas como OpenSSH 4.3 (Febrero de 2006) o el propio Kernel de Linux que data de marzo de 2010. Los puertos del Listener de Oracle (1521 TCP) que tiene instalado (versión 11G) y demás aparecen perfectamente filtrados y sólo está disponible el servidor Web de administración en un puerto HTTPS (a escoger durante la instalación) y el ya comentado de SSH. La aplicación Web de configuración no presenta errores del tipo XSS o SQLi y permite establecer una política de usuarios y contraseñas robusta. Tanto el servidor Web Tomcat como el propio SSHD están correctamente configurados y tampoco presentan debilidades.

El sistema se actualiza de forma automática (configurable) según lo que vaya publicando el ADC o Centro de Defensa de Aplicaciones de Imperva y estas nuevas defensas se transmiten de forma automática también a todos los equipos existentes y gestionados desde el servidor manager.

En nuestro laboratorio hemos configurado una única página Web con vulnerabilidades de XSS y SQLi a proteger y hemos definido una política estándar que detecte y bloquee, después de un aprendizaje automático del funcionamiento de la aplicación Web, posibles ataques de XSS y SQLi principalmente, intentos de ataques de fuerza bruta contra el formulario de autenticación, peticiones Web desde diferentes nodos de la red Tor y pruebas con Double Enconding y similares.

A modo de ejemplo, la siguiente captura muestra cómo se ha configurado en nuestra política la detección y el bloqueo de peticiones a nuestra página Web desde nodos de Tor:

Fig 1. Definición de la regla para bloquear peticiones desde la red Tor

SecureSphere también permite definir sofisticadas reglas de correlación como la utilizada para detectar y bloquear ataques de fuerza bruta contra el formulario de autenticación que existe en nuestra página Web de muestra:

Fig 2. Definición de la regla para bloquear ataques de fuerza bruta

Una funcionalidad también interesante de SecureSphere es la capacidad de mitigar “virtualmente” vulnerabilidades de desarrollo presentes en nuestra página Web que no estén corregidas y que se hayan detectado al realizar una revisión de seguridad con herramientas comerciales tales como IBM Appscan, HP Webinspect, Acunetix, etc. Es posible importar el resultado de la revisión de seguridad en formato XML para proteger a la página Web de las vulnerabilidades y errores encontrados durante dicho escaneo.

Otra funcionalidad es la posibilidad de configurar páginas de error personalizadas para que, en cuanto se produzca cualquier error en la aplicación Web se muestre la página definida por Imperva y no las de respuesta del servidor Web (Apache, IIS, etc.) donde reside nuestra página Web y que muestran información sensible acerca del error, la tecnología utilizada, versiones de software, etc. Esto permite identificar la presencia del WAF ya que cualquier página legítima (200 OK) la proporciona el servidor Web original que puede ser un IIS, un Apache o cualquier otro y la página de error (404 Not Found) la proporciona el WAF con su versión específica de Apache. Ya existen scripts en nmap (http-waf-detect.nse) para comprobar la presencia o no de un Firewall de Aplicaciones Web.

El resultado de las diferentes pruebas y simulaciones de ataques realizados ha sido una detección y bloqueo de todo lo intentado: ataques de XSS, SQLi, fuerza bruta, navegación desde la red Tor, intentos de evasión con técnicas anti-IDS, múltiple Encoding, etc.

1. Pruebas de Cross Site Scripting (XSS) utilizando mecanismos de evasión para los filtros y reglas de filtrado de los principales dispositivos de seguridad existentes, IDS, IPS, Filtrado de contenido, etc. Se han detectado y bloqueado todos los intentos de explotar una vulnerabilidad de XSS presente en la página y que no está corregida ya sea codificando la petición en hexadecimal, Base64, jugando con los TAGs HTML (no cerrando el TAG script, poniendo espacios y meta caracteres inútiles antes del Javascript del XSS, etc.).

Fig 3. Alerta de la detección de Ataques de XSS usando técnicas de evasión anti-IDS

2. Pruebas de SQLi similar al caso anterior todos los intentos de explotar diferentes vulnerabilidades de inyección SQL presentes en nuestra página de demo han sido detectados y bloqueados, incluso aquellos en los que se ha intentado evitar el filtrado del WAF incluyendo las sentencias SQL dentro de comentarios (“ / ” , “ * ” , “ ! ”) como, por ejemplo:

http://hacktimes.com/news.php?id=15+/*!UnIoN*/+/*!aLl*/+/*!SeLeCt*/+1,2,--

Fig 4. Alerta de la detección de Ataques de SQLi usando técnicas de evasión anti-IDS
3. Pruebas desde direcciones IP de la red TOR o de baja reputación. Aún sin utilizar nodos de la red Tor, ScureSphere ha sido capaz de detectar y bloquear (por la política definida) peticiones desde direcciones IP de dudosa reputación tal y como se observa en la siguiente captura de pantalla:

Fig 5. Origen de la petición HTTP desde IPs de dudosa reputación

Aquí ha entrado en juego el módulo de ThreatRadar que trae la herramienta que, entre otras cosas, comprueba la reputación de las direcciones IP desde las que se visita la página Web. En los ejemplos adjuntos no se han bloqueado las alertas pero si detectado:

Fig 6. Alertas de la detección de peticiones HTTP desde IPs de dudosa reputación

4. Ataques de fuerza bruta contra los formularios de autenticación de nuestra página han sido detectados y bloqueados según la política definida y comentada anteriormente, si se producen 3 intentos fallidos de inicio de sesión en 30 segundos se bloquea la dirección IP de origen de la petición temporalmente durante 15 minutos.

5. Double y Múltiple Encoding. Una dirección en Double Encoding se puede utilizar para realizar ataques del tipo XSS y evitar la detección por parte del WAF que sí es capaz de detectar el uso de caracteres como “<, > y /”. En nuestro ejemplo, hemos revisado cómo realiza SecureSphere la decodificación de la URL y cómo la trata con el filtro XSS. Un ejemplo sencillo y que ha sido detectado por SecureSphere sería:

<script>alert('XSS')</script>
o lo que es lo mismo (una vez codificado):

%253Cscript%253Ealert('XSS')%253C%252Fscript%253E

Los intentos de saltarse los filtros del WAF con Triple y Múltiple Encoding también han sido detectadas.

Se ha configurado una política por defecto tal y como se puede observer en la siguiente captura de pantalla que, primero detecta el uso de Encoding, bloquea la petición y, además, bloquea la dirección origen del atacante de forma temporal:

Fig 7. Configuración de la política de detección de Encoding en la URL

Por último, la herramienta proporciona un módulo para hacer reportes en formato PDF o CSV bajo demanda o de forma automática que es totalmente configurable y personalizable y que muestra toda la información relativa a las diferentes alertas encontradas.

Cabe destacar que no se han llevado a cabo pruebas para analizar el rendimiento de la plataforma ni para ver la capacidad de peticiones HTTP que es capaz de procesar por segundo ni similares. Por las pruebas resalizadas y el resultado obtenido podemos afirmar que, en lo que a seguridad se refiere, SecureSphere es una herramienta muy recomendable capaz de detectar y bloquear todo tipo de ataques en aplicaciones Web de manera eficiente y altamente configurable.

Más información sobre técnicas para evitar el filtrado de los dispositivos de seguridad tipo WAF, IDS e IPS, Double Encoding y similares en:

https://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-henrique.pdf
https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet>
https://www.owasp.org/index.php/Double_Encoding
http://www.cgisecurity.com/lib/URLEmbeddedAttacks.html