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