ModSecurity en acción

ModSecurity en AccinImplementando la seguridad de nuestro servidorEduardo Bayn Cascajo Implantacin de aplicaciones web 30/01/2012

Eduardo Bayn Cascajo

Implantacin de App Web

Tabla de contenidoIntroduccin ........................................................................................................ 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 automticas ........................................................... 16 Ataque automtico de XSS ........................................................................... 16 Corrigiendo los ataques XSS ........................................................................ 19 Ataque automtico de SQLi .......................................................................... 21 Corrigiendo los ataques SQLi ....................................................................... 22 Conclusiones .................................................................................................... 24 Bibliografa y Webgrafa ................................................................................... 25

Pgina 1 de 26



IntroduccinEn 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. Tambin instalaremos en nuestra mquina Ubuntu un capturador de trfico, para comprobar de que manera se ven los ataque se realizan a nuestras pginas web antes de especificar las reglas y despus.

Instalado WireSharkComo ya he comentado este ser nuestro primer paso, WireShark es un caputrador de trfico, un analizador de protocolos utilizado para realizar anlisis y solucionar problemas en redes de comunicaciones, para desarrollo de software y protocolos, y como una herramienta didctica para educacin. Cuenta con todas las caractersticas estndar de un analizador de protocolos. [1] Si vamos al sitio oficial de WireShark podremos ver mas informacin sobre esta aplicacin 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 instalacin podremos abrir el programa desde Aplicaciones>Internet>WireShark:

Pgina 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 configuracin /usr/share/wireshark/init.lua tiene una serie de reglas deshabilitadas en el caso de ejecutemos en el programa como root, aunque segn lo encontrado por foros el programa debera 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 tenamos sobre la carpeta dumcap para tener pleno control sobre ella. 4. Cerramos sesin y volvemos a entrar con el mismo usuario. Abrimos Wireshark desde el modo grfico o desde consola sin escribir sudo y comprobaremos que lo podemos usar sin necesidad de estar como root:

Pgina 3 de 26



Vamos hacer una pequea demostracin 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 trfico sobre esa interfaz, por ejemplo voy a realizar desde mi mquina antifriona (192.168.13.15) a la mquina Ubuntu(192.168.13.54):

Pgina 4 de 26



Automticamente 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 informacin sobre el paquete, como el comando usado.

Dejando al equipo vulnerableAntes de comenzar a demostrar las vulnerabilidades, lo que vamos hacer es dejar nuestra aplicacin sin proteccin alguna, por lo que iremos a dvwa y bajaremos la proteccin de esta aplicacin a low:

Si dejamos por defecto la seguridad que tiene la aplicacin, no podremos realizar ataques bsicos de ningn tipo, y cada vez que se acceda a la aplicacin por defecto habr cambiado a high por lo que tendremos que volver a este punto y cambiarlo.Pgina 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 estn protegidas en este momento y poder demostrar las vulnerabilidades.

Pgina 6 de 26



Comprobando Vulnerabilidades XSSUna vez instalado nuestro analizador de trfico y dejado totalmente vulnerable nuestro sitio web, vamos a realizar una serie de ataque XSS para despus 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 continuacin 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: alert(document.cookie);

De modo que se nos mostrar una ventana emergente con nuestra cookie o id de sesin:

Pgina 7 de 26



Trafico XSS con WireSharkEntonces ahora que hemos realizado nuestro ataque XSS, podemos dirigirnos a WireShark para comprobar de qu manera ha capturado el trfico:

Podemos observar como detecta el origen y el destino, el protocolo usando adems de otra informacin, como la categora 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 ms datos en la parte inferior de la pantalla del programa:

Pgina 8 de 26



Ver ataque XSS en los ficheros de logDel 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 informacin sobre los datos que recibe nuestra aplicacin. 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 adems de otros que hemos realizado, tambin de tipo XSS como se puede comprobar analizando la URL que nos devuelve.

Pgina 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 instalacin que hice, siguiendo la prctica 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 estn enlazados y ambos apuntan al mismo (ambos tienen los ficheros modsec_audit.log y modsec_debug.log, los dos muestran similar informacin pero es el primero el que la analiza ms 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 ningn 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 instalacin:

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

Pgina 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 informacin 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 auditora. B Representa el encabezado de la solicitud F Representa una cabecera de respuesta H Representa un triler de registros de auditora. K Parte opcional de los registros de auditora. Z Es el final de una entrada de registro de auditora.

Pgina 11 de 26



Comprobando vulnerabilidades SQLiYa hemos visto como se muestra en nuestro sistema, en los ficheros de log y en WireShark, cuando realizamos un ataque de tipo XSS, a continuacin 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 configuracin 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:

Pgina 12 de 26



Trafico SQLi con WireSharkAhora que ya sabemos cmo trabaja, ms o menos, WireShark a la hora de capturar el trfico lo veremos ms rpidamente, 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 peticin que hemos hecho que hacia carente la vulnerabilidad de tipo SQLi:

Pgina 13 de 26



Ver ataques SQLi en los ficheros de logAl 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 envo que hemos realizado desde nuestro navegador realizando el ataque de sql injection.

Ficheros de log de ModSecurity Tambin 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 tambin de que manera rechaza ModSecurity esta peticin 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:

Pgina 14 de 26



Y como las reglas estn correctamente aplicadas, aqu podemos ver mensaje de error 501 comentado y que nos indica que el mtodo no est implementado, es decir nuestro servidor web est enviando un mensaje de que no entiende esta peticin y as lo protege:

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

Pgina 15 de 26



Ataques con herramientas automticasA continuacin vamos a ver de qu manera acta con y sin proteccin nuestra aplicacin 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 automtico de XSSPara 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 versin actual (9.0.1), y que en la que mejor funciona es en la v.3.6 por lo que instalar esa versin que la podemos bajar de aqu y una vez instalado podemos aadir el complemento XSS ME dirigindonos a: https://addons.mozilla.org/es-es/firefox/addon/xss-me/

Pgina 16 de 26



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

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

Pgina 17 de 26



Ahora que ya lo tenemos instalado, podemos comprobar cmo es de vulnerable nuestro sitio web sin aplicar ningn tipo de seguridad. Abriremos XSS Me y desde el apartado de XSS Stored (es el nico que me muestra errores) realizamos un ataque XSS automtico de manera general con todos los payloads que tienen predefinidos el programa:

Podemos comprobar que el programa reconoce los campos que hay en la pgina web para introducir cdigo, 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.

Pgina 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. Tambin 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 XSSLo normal sera 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 instalacin, que se leeran los ficheros de configuracin de ModSecurity.

Pgina 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 cdigo de proteccin que tenamos de las reglas por defecto de los ficheros de configuracin 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 conllevara un sistema completamente seguro y segua siendo el mismo lo que no tiene ningn sentido.

Pgina 20 de 26



Ataque automtico de SQLiYa hemos visto de que manera protegernos de ataques automticos de XSS, ahora vamos a ver, primero como sera 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 bsqueda, ya que si no se quedar en la pgina 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 parmetro id, es el que demostramos que era vulnerable cuando hicimos la comprobacin manualmente, es inyectable. El cdigo 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 cdigo:

Pgina 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 SQLiPara 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 aadimos las reglas:

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

Pgina 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 pgina. Pero tambin vamos a probar a volver a ejecutar SQLMap:

Y aqu tenemos la respuesta de que esta vez nuestro parmetro no es inyectable:

Pgina 23 de 26



ConclusionesModSecurity es una gran herramienta para proteger nuestras aplicaciones web, es bastante fcil de usar y cada cierto tiempo aaden nuevas reglas que se pueden descargar fcilmente. La verdad es que lo ms 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 cdigos que ya habamos obtenido.

Pgina 24 de 26



Bibliografa y Webgrafa[1]Wireshark http://es.wikipedia.org/wiki/Wireshark [Consulta el 29 de enero de 2012]

Pgina 25 de 26

Documents

ModSecurity en acción