Upload
xavi-luna
View
42
Download
4
Embed Size (px)
Citation preview
Vulnerabilidades Web y uso de mod-security
SSI 2012/13
23 de octubre de 2012
Indice
1. Entorno de pruebas 1
1.1. Imagenes a utilizar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Establecer el entorno virtualizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Ejercicio 1: Vulnerabilidades tıpicas en aplicaciones web 2
2.1. Descripcion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2. Aplicaciones vulnerables (Cross Site Scripting: XSS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2.1. Foro ”simple” vulnerable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.3. Aplicaciones vulnerables (Inyeccion SQL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3.1. Inyeccion SQL Foro ”simple” vulnerable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3.2. Inyeccion SQL en Wordpress 1.5.1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Aplicaciones vulnerables educativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.5. Documentacion a entregar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Ejercicio 2: Instalacion y experimentacion con mod-security 5
3.1. Descripcion de mod-security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Instalacion y configuracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Documentacion a entregar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Entorno de pruebas
1.1. Imagenes a utilizar
Imagenes de partida
Imagen y script comprimido: modsecurity.tgz [0,6 GB]
Contenido:
• modsecurity.vdi: Imagen VirtualBox de la maquina con aplicaciones web vulnerables.Usuarios configurados.login passwordroot purpleusuario1 usuario1usuario2 usuario2
1
• swapSSI.vdi: Imagen VirtualBox de una unidad de disco formateada como SWAP
• ejemplo-modsecurity.sh: Script bash que configura las maquinas virtuales y las arranca.
1.2. Establecer el entorno virtualizado
Creacion de la red donde se realizara el ejercicio:
La ”vıctima” se accedera desde el equipo atacante empleado en la practica anterior
Se establecera una red entre ambos en el segmento 192.168.100.0/24
1. Descomprimir las imagenes en el directorio actual
tar xzvf modsecurity.tgz
2. Configurar y registrar las maquinas virtuales en VirtualBOX (solo la primera vez)
Script de configuracion y arranque:
GNU/Linux: ejercicio-modsecurity.sh
Nota: ejecutarlos desde el directorio donde se hayan descomprimido las imagenes
Para GNU/Linux
alumno@pc:~$ bash ejercicio-modsecurity.sh
3. Arrancar las instancias VirtualBOX (si no lo hacen desde el script anterior) desde el interfaz grafico o desdela lınea de comandos.
VBoxManage startvm MODSECURITY
Importante: Despues de finalizar cada ejercicio terminar la ejecucion de la maquina virtual desde lınea decomandos con halt o sudo halt o desde el interfaz grafico LXDE.
2. Ejercicio 1: Vulnerabilidades tıpicas en aplicaciones web
2.1. Descripcion
En este ejercicio veremos ejemplos simples de vulnerabilidades web. Usaremos una apliacion PHP de muestra muysimplificada que no realiza ningun tipo de comprobacion de las entradas que recibe y que permite Inyeccion de SQL(que usaremos para burlar la comprobacion de login y password) y XSS (Cross Site Scripting). Tambien veremos unejemplo de software real, una version antigua del software para blogs WordPress, con vulnerabilidades XSS.
Por ultimo en la mnaquina virtual se encuentran instaladas tres aplicaciones web vulnerables para ser usadas con finesdidacticos.
2.2. Aplicaciones vulnerables (Cross Site Scripting: XSS)
2.2.1. Foro ”simple” vulnerable
En la maquina modsecurity hay una implementacion de un foro de juguete en PHP.
Codigo fuente en: /var/www/foro
2
Cuenta con 2 usuarios creados (ana y pepe) ambos con password ssi
Desde la maquina atacante:
1. Abrir la direccion http://192.168.100.33/foro o http://modsecurity.ssi.net/foro en un navegador WEB
2. Entrar como ana (password ssi)
Anadir un mensaje con una parte de su tıtulo y otra del cuerpo encerrada entre las etiquetas HTML detexto en negrita: (<b>....</b>)
Revisar la lista de mensajes para comprobar que las marcas HTML incluidas en las entradas entrada secopian tal cuales
3. Preparar un ataque de XSS persistente
Ana crea otro mensaje nuevo, incluyendo en el texto la siguiente etiqueta <script> con comandos JavaScript
<script> alert(’’esto admite XSS’’) </script>
Desde otro navegador de la maquina atacante acceder a la URL http://192.168.100.33/foro o http://modsecurity.ssi.net/forocon las credenciales del usuario pepe (con password ssi) y entrar en el listado de mensajes
Se comprueba la ejecucion del codigo del ”ataque” XSS preparado por ana
Un atacante real (el papel de ana) inyectarıa codigo Javascript mas danino, normalmente con la finalidad dehacerse con informacion relevante del usuario atacado (el papel de pepe). Tıpicamente se tratarıa de ”robar”cookies o informacion de la sesion abierta por el usuario atacado desde su navegador, para almacenarla con lafinalidad de suplantar la sesion de un usuario legıtimo o incluso hacerse con el control del navegador del usuario(ver Browser Exploitation Framework (BeEF)).
2.3. Aplicaciones vulnerables (Inyeccion SQL)
2.3.1. Inyeccion SQL Foro ”simple” vulnerable
Desde la maquina atacante
Volver a la pagina de inicial del foro: http://192.168.100.33/foro o http://modsecurity.ssi.net/foro
Veremos como acceder sin disponer de nombre de usuario ni clave en la pagina de login.
Indicar lo siguiente en la casilla usuario:
usuario: ’ or 1=1 ; #password: <vacıo>
Confirmamos como se accede la aplicacion accede como un usuario autorizado (el primero de la base de datos)
En la maquina modsecurity, comprobar como serıa la consulta SQL que usara esos parametros (ver el codigoen /var/www/foro/login.php)
root:~# leafpad /var/www/foro/login.php &
3
2.3.2. Inyeccion SQL en Wordpress 1.5.1.1
Ejemplo de vulnerabilidad en una version antigua del software para blogs WordPress.
Los ataques de Inyeccion SQL no tienen por que limitarse al acceso a traves de campos de formulario. En este caso elcodigo SQL inyectado se incluye en la barra de direcciones (en un parametro de la URL que se envıa en la peticionHTTP GET)
1. Abrir desde el navegador de la maquina atacante la url del blog: http://192.168.100.33/wordpress o http://modsecurity.ssi.net/wordpress
2. El usuario y el login de este blog son:
usuario: adminpasswd: secreto
3. Probaremos la inyeccion SQL sobre los parametros de la consulta de categorias (http://192.168.100.33/wordpress/?cat=1)
a) Poner en barra de direcciones: (sin espacios)
http://192.168.100.33/wordpress/index.php?cat=999%20UNION%20SELECT%20null,CONCAT(CHAR(58),user_pass,CHAR(58),user_login,CHAR(58)),null,null,null%20FROM%20wp_users
hhttp://modsecurity.ssi.net/wordpress/index.php?cat=999%20UNION%20SELECT%20null,CONCAT(CHAR(58),user_pass,CHAR(58),user_login,CHAR(58)),null,null,null%20FROM%20wp_users
Nota: puede copiarse y pegarse esta URL desde el archivo /root/aplicaciones_vulnerables/wordpress/url-wordpress.txtde la maquina virtual modsecurity
b) Se mostrara en la columna derecha (zona de lista de categorias) el par:
admin:e201994dca9320fc94336603b1cfc970
c) Vemos el contenido de la primera fila de la tabla de usuarios, con nombre de usuario admin y el md5 de supasswordPara comprobar que ese es efectivamente es el resumen md5 de la cadena secreto:
Buscar la cadena e201994dca9320fc94336603b1cfc970 en google (sale asociado a la palabra ”secreto”)Ejecutar en lınea de comandos: echo -n "secreto" | md5sum
2.4. Aplicaciones vulnerables educativas
En la maquina virtual modsecurity se encuentra instaladas tres aplicaciones vulnerables (2 en PHP y 1 en Java)disenadas para experimentar con ellas.
Damm Vulnerable Web App en http://192.168.100.33/dvwa o http://modsecurity.ssi.net/dvwa, con lo-gin admin y password password
Implementa ejemplos de XSS e inyeccion SQL y otras vulnerabilidades en tres niveles de dificultad
Web: http://www.dvwa.co.uk/
Mutillidae (NOWASP) en http://192.168.100.33/mitillidae o http://modsecurity.ssi.net/mutillidae
Web: http://sourceforge.net/projects/mutillidae/
WebGoat en http://192.168.100.33:8080/WebGoat/attack o http://modsecurity.ssi.net:8080/WebGoat/attack,con login guest y password guest
Instalacion y arranque: desde el directorio /root/aplicaciones-vulnerables/WebGoat/WebGoat-5.3-RC1
~:# ./webgoat.sh start8080
Web: https://www.owasp.org/index.php/Category:OWASP WebGoat Project
4
2.5. Documentacion a entregar
3. Ejercicio 2: Instalacion y experimentacion con mod-security
3.1. Descripcion de mod-security
Resumen mod-security: pdf
Web: http://www.modsecurity.org/
3.2. Instalacion y configuracion
1. Instalar los paquetes debian (ya hecho)
apt-get install libapache-mod-security
2. Descargar y descomprimir la reglas del OWASP ModSecurity Core Rule Set Project
Descarga: OWASP ModSecurity Core Rule Set Project
En la maquina modsecurity estan en el directorio /root/modsecurity
cd /root/modsecurity
tar xzvf SpiderLabs-owasp-modsecurity-crs-v2.2.5.tar.gz
mv SpiderLabs-owasp-modsecurity-crs-v2.2.5 /etc/modsecurity/owasp_rules
3. Ajustar la configuracion por defecto de mod-security e indicar el uso de las reglas
cd /etc/modsecurity
cp modsecurity.conf-recommended modsecurity.conf
nano modsecurity.conf
Editar modsecurity.conf para anadir lo siguiente al final (carga de las reglas OWASP)
# Incluir OWASP Core Rule Set
Include "/etc/modsecurity/owasp_rules/modsecurity_crs_10_setup.conf"
Include "/etc/modsecurity/owasp_rules/activated_rules/*.conf"
4. Configurar y habilitar las reglas OWASP a utilizar
cd owasp_rules
cp modsecurity_crs_10_setup.conf.example modsecurity_crs_10_setup.conf
ln -s $PWD/base_rules/* activated_rules
Enlazar en el directorio base_rules los ficheros con las reglas a utilizar (en este caso el conjunto de reglas basicocompleto)
5. Habilitar el modulo mod-security en Apache y reiniciar el servidor
a2enmod mod-security
/etc/init.d/apache2 restart
Comprobar los ficheros /etc/apache2/mods-enabled/modsecurity.load y /etc/apache2/mods-enabled/modsecurity.conf
5
6. Repetir las pruebas de inyeccion SQL y XSS sobre el foro y wordpress
7. Mod-security estaba configurado en modo deteccion (ver /etc/modsecurity/modsecurity.conf).
En /var/log/apache2/ se pueden ver los ficheros de log con las reglas activadas (access.log , error.log,modsec_audit.log)
8. Configurar mod-security en modo rechazo y repetir las pruebas de inyeccion SQL y XSS sobre el foro y wordpress
Editar /etc/modsecurity/modsecurity.conf para establecer el parametro SecRuleEngine a On
Nota: el acceso a las URL debe hacerse con el nombre de la muina modsecurity, no con su direccion IP.(http://modsecurity.ssi.net/foro, etc)
3.3. Documentacion a entregar
<pendiente>
6