ModSecurity en acción

ModSecurity en Acción Implementando la seguridad de nuestro servidor Eduardo Bayón Cascajo Implantación de aplicaciones web 30/01/2012

Eduardo Bayón Cascajo

Implantación de App Web

Tabla de contenido Introducción ........................................................................................................ 2 Instalado WireShark ........................................................................................... 2 Dejando al equipo vulnerable ............................................................................. 5 Comprobando Vulnerabilidades XSS ................................................................. 7 Trafico XSS con WireShark ............................................................................ 8 Ver ataque XSS en los ficheros de log ........................................................... 9 Ficheros de log de Apache.......................................................................... 9 Ficheros de log de ModSecurity ................................................................ 10 Comprobando vulnerabilidades SQLi ............................................................... 12 Trafico SQLi con WireShark ......................................................................... 13 Ver ataques SQLi en los ficheros de log ....................................................... 14 Ficheros de log de Apache........................................................................ 14 Ficheros de log de ModSecurity ................................................................ 14 Ataques con herramientas automáticas ........................................................... 16 Ataque automático de XSS ........................................................................... 16 Corrigiendo los ataques XSS ........................................................................ 19 Ataque automático de SQLi .......................................................................... 21 Corrigiendo los ataques SQLi ....................................................................... 22 Conclusiones .................................................................................................... 24 Bibliografía y Webgrafía ................................................................................... 25

Página 1 de 26



Introducción En este segundo documento sobre la seguridad en aplicaciones web vamos a ver, una vez instalado y comprobado que ya está trabajando ModSecurity, la manera de implementarlo y especificar sus reglas para filtrar y proteger nuestras aplicaciones web, principalmente de ataques XSS (Cross Site Scripting) y SQL injection. También instalaremos en nuestra máquina Ubuntu un capturador de tráfico, para comprobar de que manera se ven los ataque se realizan a nuestras páginas web antes de especificar las reglas y después.

Instalado WireShark Como ya he comentado este será nuestro primer paso, WireShark es un caputrador de tráfico, un analizador de protocolos utilizado para realizar análisis y solucionar problemas en redes de comunicaciones, para desarrollo de software y protocolos, y como una herramienta didáctica para educación. Cuenta con todas las características estándar de un analizador de protocolos. [1] Si vamos al sitio oficial de WireShark podremos ver mas información sobre esta aplicación y podremos descargarnos los instaladores para equipos Windows y Mac. En nuestro caso, que lo instalaremos sobre un equipo Ubuntu, la orden que lo realiza es la siguiente:

Una vez termine la descarga y la instalación podremos abrir el programa desde Aplicaciones>Internet>WireShark:

Página 2 de 26



O desde un terminal ejecutamos: wireshark o sudo wireshark. El problema es que Wireshark te recomienda no usarlo como superusuario ya que dentro de su fichero de configuración /usr/share/wireshark/init.lua tiene una serie de reglas deshabilitadas en el caso de ejecutemos en el programa como root, aunque según lo encontrado por foros el programa debería actuar correctamente. De todos modos, lo que haré será dar derechos de administrador a mi usuario (asir) sobre este programa, para ello he seguido los siguientes pasos: 1. Editamos el archivo group… …y creamos un grupo llamado Wireshark, y dentro del mismo colocamos el nombre de nuestro usuario en el equipo de la siguiente manera: 2. Volvemos a la consola ejecutamos: Para cambiar el grupo de Wireshark. 3. En la misma consola, ejecutamos: De este modo le estamos cambiando los permisos que teníamos sobre la carpeta dumcap para tener pleno control sobre ella. 4. Cerramos sesión y volvemos a entrar con el mismo usuario. Abrimos Wireshark desde el modo gráfico o desde consola sin escribir sudo y comprobaremos que lo podemos usar sin necesidad de estar como root:

Página 3 de 26



Vamos hacer una pequeña demostración de su uso. Para ello escogemos primero la interfaz sobre la que deseamos capturar paquetes, en mi caso como se ve en la imagen anterior, escogeré la eth0:

El programa estará esperando tráfico sobre esa interfaz, por ejemplo voy a realizar desde mi máquina antifriona (192.168.13.15) a la máquina Ubuntu(192.168.13.54):

Página 4 de 26



Automáticamente al realizar el ping, como hemos dejado en escucha a WireShark este capturará el ping que se le ha enviado:

Podemos ver, el tiempo que ha tardado, la fuente desde donde se ha enviado, el destino, el protocolo y por último algo de información sobre el paquete, como el comando usado.

Dejando al equipo vulnerable Antes de comenzar a demostrar las vulnerabilidades, lo que vamos hacer es dejar nuestra aplicación sin protección alguna, por lo que iremos a dvwa y bajaremos la protección de esta aplicación a low:

Si dejamos por defecto la seguridad que tiene la aplicación, no podremos realizar ataques básicos de ningún tipo, y cada vez que se acceda a la aplicación por defecto habrá cambiado a high por lo que tendremos que volver a este punto y cambiarlo. Página 5 de 26



Del mismo modo, debemos tener nuestro ModSecurity sin ninguna regla aplicada, es decir que si hemos seguido los pasos de la actividad anterior tendremos que vaciar la carpeta que contiene las reglas de filtrado para que nuestras aplicaciones no estén protegidas en este momento y poder demostrar las vulnerabilidades.

Página 6 de 26



Comprobando Vulnerabilidades XSS Una vez instalado nuestro analizador de tráfico y dejado totalmente vulnerable nuestro sitio web, vamos a realizar una serie de ataque XSS para después analizarlos desde WireShark y desde los ficheros de log que contiene Apache y nuestro firewall de aplicaciones web ModSecurity. Activaremos WireShark y lo dejaremos en modo escucha, a continuación nos dirigimos a dvwa y nos situamos sobre el apartado XSS reflected, donde se nos muestra un cuadro de texto donde podemos probar nuestros payloads. En este caso para hacer evidente esta vulnerabilidad especificaré el payload siguiente: <script>alert(document.cookie);

De modo que se nos mostrará una ventana emergente con nuestra cookie o id de sesión:

Página 7 de 26



Trafico XSS con WireShark Entonces ahora que hemos realizado nuestro ataque XSS, podemos dirigirnos a WireShark para comprobar de qué manera ha capturado el tráfico:

Podemos observar como detecta el origen y el destino, el protocolo usando… además de otra información, como la categoría usada, GET en este caso y el mensaje que se ha recogido, que es el ataque que hemos enviado. Del mismo modo, si nos situamos sobre ese paquete recibido, podemos ver más datos en la parte inferior de la pantalla del programa:

Página 8 de 26



Ver ataque XSS en los ficheros de log Del mismo modo que hemos podido ver el tipo de ataque efectuado desde WireShark, podemos verlo dentro de nuestros ficheros de log, que son los que almacenan toda la información sobre los datos que recibe nuestra aplicación. Ya que tenemos Apache y ModSecurity instalados, debemos de tener los logs de acceso de ambos. Ficheros de log de Apache Vamos a ver primero los logs que almacena Apache, para ello vamos al fichero access.log que se encuentra en /var/log/apache2/ y podremos ver el contenido del fichero con usando gedit sin tan siquiera permisos de administrador:

Y ahí podemos ver, en primer lugar, el mismo ataque que hemos visto con WireShark además de otros que hemos realizado, también de tipo XSS como se puede comprobar analizando la URL que nos devuelve.

Página 9 de 26



Ficheros de log de ModSecurity Del mismo modo, ModSecurity almacena sus propios ficheros de log donde se registra toda la actividad de nuestro sitio web. Dado el tipo de instalación que hice, siguiendo la práctica anterior, tengo estos ficheros de log almacenados en dos directorios:  

/var/log/apache2/mod_security /etc/apache2/logs

En ambos casos el contenido siempre será el mismo ya que están “enlazados” y ambos apuntan al mismo (ambos tienen los ficheros modsec_audit.log y modsec_debug.log, los dos muestran similar información pero es el primero el que la analiza más en profundidad y será el que veremos). Debemos tener una cosa muy en cuenta, y es que si al vaciar la carpeta con las reglas de ModSecurity este no almacenará ningún cambio en los ficheros de log, es decir, que si queremos que se muestren nuestros ataques debemos especificar las reglas necesarias. De modo que así lo haremos, y dentro del directorio /etc/apache2/conf.d/modsecurity/ volveremos a meter todos los ficheros que contienen las reglas que nos hemos bajado y configurado, de manera predeterminada, durante la instalación:

Tras copiar de nuevo los ficheros a nuestra carpeta de configuración de ModSecurity y reiniciar el servidor apache, podemos realizar un nuevo ataque XSS:

Página 10 de 26



Y evidentemente ahora que vuelven a estar activas las reglas, cuando pulsemos sobre Sumbit nos enviará al navegador un mensaje de error:

Pero si nos dirigimos al fichero modsec_audit.log en cualquiera de los dos directorios anteriormente mencionados podremos ver como se muestra el ataque realizado:

Ahí podemos visualizar la misma información obtenida que obtuvimos anteriormente en los anteriores ficheros de log de Apache o sobre WireShark, pero con mayor profundidad, ya que estos ficheros de log de ModSecurity se dividen en 5 partes (5 fijas mas otras opciones):      

A  Representa parte del registro de auditoría. B  Representa el encabezado de la solicitud F  Representa una cabecera de respuesta H  Representa un “tráiler” de registros de auditoría. K  Parte opcional de los registros de auditoría. Z  Es el final de una entrada de registro de auditoría.

Página 11 de 26



Comprobando vulnerabilidades SQLi Ya hemos visto como se muestra en nuestro sistema, en los ficheros de log y en WireShark, cuando realizamos un ataque de tipo XSS, a continuación vamos a ver de qué manera queda constancia de un ataque de SQL injection. Si tenemos las reglas activadas, debemos desactivarlas, es decir eliminar o mover los ficheros que tengamos dentro de la configuración de ModSecurity (/etc/apache2/conf.d/modsecurity/) para poder realizar el ataque. Para realizar nuestro ataque SQLi nos dirigiremos dentro de dvwa al apartado SQL Injection y en el cuadro de texto que tenemos habilitado especificamos una cadena que demuestre la vulnerabilidad SQLi que existe en nuestro sistema sin seguridad:

Y el consecuente resultado que demuestra la vulnerabildiad actual del sistema:

Página 12 de 26



Trafico SQLi con WireShark Ahora que ya sabemos cómo trabaja, más o menos, WireShark a la hora de capturar el tráfico lo veremos más rápidamente, por lo que nos dirigiremos al programa que está en escucha y podremos ver como se ha realizado la captura. En la siguiente imagen podremos ver de qué modo ha capturado la petición que hemos hecho que hacia carente la vulnerabilidad de tipo SQLi:

Página 13 de 26



Ver ataques SQLi en los ficheros de log Al igual que antes con los ficheros de log sobre los ataques XSS, ahora podremos ver lo mismo sobre los ataques de tipo SQLi tanto sobre los ficheros de log de Apache como los de ModSecurity con sus reglas activadas.

Ficheros de log de Apache Como ya vimos anteriormente el fichero de Apache que captura estos ataques es el access.log, en la siguiente imagen podemos observar como ha capturado el envío que hemos realizado desde nuestro navegador realizando el ataque de sql injection.

Ficheros de log de ModSecurity También vamos a observar de que manera quedan los ficheros de log de ModSecurity cuando se realiza un ataque de tipo SQLi y tenemos las reglas activadas. Para esta prueba voy a cambiar el payload que he utilizado anteriormente, así podremos ver también de que manera rechaza ModSecurity esta petición y nos muestra una pantalla de error en el navegador con el mensaje 501. Este será el codigo que usaremos para hacer evidente la vulnerabildiad: '+union+all+select+user%2C+password+from+dvwa.users De modo que los especificaremos sobre la casilla para intentar hacer el ataque y pulsamos sobre Sumbit:

Página 14 de 26



Y como las reglas están correctamente aplicadas, aquí podemos ver mensaje de error 501 comentado y que nos indica que el método no está implementado, es decir nuestro servidor web está enviando un mensaje de que no entiende esta petición y así lo protege:

Si nos dirigimos al fichero modsec_audit.log podremos ver igual que antes, con sus apartados específicos, de qué manera se ha realizado el ataque y como ha quedado referenciado en nuestros ficheros de log de ModSecurity:

Página 15 de 26



Ataques con herramientas automáticas A continuación vamos a ver de qué manera actúa con y sin protección nuestra aplicación web cuando realicemos ataques tanto de tipo XSS como SQLi con herramientas automatizadas, es decir que realizaran lo mismo que hemos hecho nosotros pero probando una gran cantidad de posibilidades de las que nosotros hicimos.

Ataque automático de XSS Para realizar este tipo de ataque utilizaré un complemento de Firefox que se llama XSS Me. Debemos saber que este complemento para Mozilla Firefox no funciona demasiado bien en la versión actual (9.0.1), y que en la que mejor funciona es en la v.3.6 por lo que instalaré esa versión que la podemos bajar de aquí y una vez instalado podemos añadir el complemento XSS ME dirigiéndonos a: https://addons.mozilla.org/es-es/firefox/addon/xss-me/

Página 16 de 26



Pulsaremos sobre Seguir a la descarga y completaremos el proceso para añadir el complemento a nuestro navegador.

Una vez terminado el proceso de instalación, reiniciaremos Mozilla Firefox y dentro del apartado Herramientas del menú superior del navegador tendremos una entrada nueva XSS ME:

Página 17 de 26



Ahora que ya lo tenemos instalado, podemos comprobar cómo es de vulnerable nuestro sitio web sin aplicar ningún tipo de seguridad. Abriremos XSS Me y desde el apartado de XSS Stored (es el único que me muestra errores) realizamos un ataque XSS automático de manera general con todos los payloads que tienen predefinidos el programa:

Podemos comprobar que el programa reconoce los campos que hay en la página web para introducir código, en este caso el nombre y el mensaje, los dejaremos en blanco para que analice por completo todos los payloads, seleccionaremos Runa ll tests y empezaremos pulsando sobre Execute:

Tardará unos segundos en completarse el test….

Página 18 de 26



…y podremos ver los resultados de nuestro sistema sin asegurar:

En anteriores pruebas los fallos (failures) obtenidos eran muchos mayores con la misma seguridad, sinceramente no sé porque ahora sale de este modo. De todas formas de 308 tests ejecutados 154 son peligrosos o avisan con warning. También nos indica al principio de la imagen, los caracteres que han hecho evidente la vulnerabilidad, en rojo, y los que no, en verde.

Corrigiendo los ataques XSS Lo normal sería copiar los ficheros que tenemos con las normas preestablecidas cuando nos descargamos ModSecurity, pero vamos a ver si somos capaces de crear un fichero propio para filtrar los ataques de tipo XSS. Lo primero que debemos saber es que el fichero en el que metamos las reglas tienes que acabar en .conf y estar dentro del directorio /etc/apache2/conf.d/modsecurity/ que es el que especificamos, al realizar la instalación, que se leerían los ficheros de configuración de ModSecurity.

Página 19 de 26



Por ejemplo, podemos crear un fichero que se llame protegerXSS.conf y especificar las reglas de tipo XSS que queramos:

Para tener mayor seguridad he copiado parte del código de protección que teníamos de las reglas por defecto de los ficheros de configuración descargados. Entonces probamos a realizar un ataque XSS como anteriormente:

La web se comporta de manera segura y omite el uso de estos payloads. Decir, que tras estas modificaciones he vuelto a pasar XSS ME y el resultado en cuanto a Fallos, Avisos y Pasados es el mismo que cuando estaba vulnerable y le he vuelto a pasar aplicando TODAS las reglas, lo que conllevaría un sistema completamente seguro y seguía siendo el mismo lo que no tiene ningún sentido.

Página 20 de 26



Ataque automático de SQLi Ya hemos visto de que manera protegernos de ataques automáticos de XSS, ahora vamos a ver, primero como sería un ataque de tipo SQLi mediante la herramienta SQLMap y a ver de qué manera podemos protegeremos y que reglas tenemos o podemos usar. Para que SQLMap pueda demostrar la vulnerabilidad en este sitio web, necesitaremos pasarle la cookie cuando hagamos la búsqueda, ya que si no se quedará en la página principal (login.php) y tendremos que tener activadas las cookies (PHPSSID) dentro de la seguridad de DVWA:

Ahora sí, podemos ejecutar nuestro SQLMap, y comprobar si el parámetro id, es el que demostramos que era vulnerable cuando hicimos la comprobación manualmente, es inyectable. El código a usar será:

Tardará un poco en ejecutarse, pero finalmente demostrará la vulnerabilidad:

Como hemos obtenido que la base de datos es MySQL a ver qué datos podemos obtener de ella, para eso usaremos el siguiente código:

Página 21 de 26



De este modo, nos mostrará las bases de datos que haya en el sistema, aunque parece ser que no puede darnos el nombre de la que hay por defecto al crear dvwa, aunque si detectarla.

Corrigiendo los ataques SQLi Para ello crearemos un nuevo fichero dentro de /etc/apache2/conf.d/modsecurity/ y copiaremos algunas reglas que protejan nuestro sitio web contra ataques de tipo SQLi. Primero creamos el fichero dentro del directorio correspondiente:

Y añadimos las reglas:

Y antes de ver si funcionan correctamente reiniciamos el servidor Apache:

Página 22 de 26



Ahora podemos probar si nuestro sitio es seguro, primero lo haré manualmente como lo hice al principio:

O con:

El resultado siempre es el mismo y se nos actualiza la página. Pero también vamos a probar a volver a ejecutar SQLMap:

Y aquí tenemos la respuesta de que esta vez nuestro parámetro no es inyectable:

Página 23 de 26



Conclusiones ModSecurity es una gran herramienta para proteger nuestras aplicaciones web, es bastante fácil de usar y cada cierto tiempo añaden nuevas reglas que se pueden descargar fácilmente. La verdad es que lo más complicado es aplicar tu mismo esas reglas y que tengan efecto que es lo que yo no he conseguido y por eso he tenido que copiar parte de los códigos que ya habíamos obtenido.

Página 24 de 26



Bibliografía y Webgrafía [1]”Wireshark” http://es.wikipedia.org/wiki/Wireshark [Consulta el 29 de enero de 2012]

Página 25 de 26

ModSecurity en acción

Recommend Documents