Professional Documents
Culture Documents
Tabla de contenido
Introduccin ........................................................................................................ 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
Introduccin
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. 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 WireShark
Como 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.
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
De modo que se nos mostrar una ventana emergente con nuestra cookie o id de sesin:
Pgina 7 de 26
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
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
Pgina 12 de 26
Pgina 13 de 26
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
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:
Pgina 18 de 26
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.
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
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:
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.
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:
Pgina 23 de 26
Conclusiones
ModSecurity 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