Vulnerabilidades Web y uso de mod-security

SSI 2013/14
29 de octubre de 2013

Indice
1. Previo: reto de desbordamiento de buffer

1.1. Documentaci
on a entregar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2. Entorno de pruebas

3. Ejercicio 1: Vulnerabilidades tpicas en aplicaciones web

3.1. Descripci
on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2. Aplicaciones vulnerables (Cross Site Scripting: XSS) . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2.1. Foro simple vulnerable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3. Aplicaciones vulnerables (Inyecci

on SQL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3.1. Inyecci
on SQL Foro simple vulnerable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3.2. Inyecci
on SQL en Wordpress 1.5.1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.4. Aplicaciones vulnerables educativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.5. Documentaci
on a entregar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4. Ejercicio 2: Instalaci
on y experimentaci
on con mod-security

1.

4.1. Descripci
on de mod-security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2. Instalaci
on y configuraci
on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3. Documentaci
on a entregar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Previo: reto de desbordamiento de buffer

1. Compilar y ejecutar el siguiente c

odigo C
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
char* crear_pin_aleatorio() {
char* pin = (char *) malloc(5);;
srand(time(0)); // Inicializa generador de nos. aleatorios
sprintf(pin, "%04d", rand()%10000);
return pin;
}
1

int main(int argc, char *argv[]) {

char pin_secreto[5];
strcpy(pin_secreto, crear_pin_aleatorio());
char pin_leido[5];
printf("Introducir PIN: ");
gets(pin_leido);
// No comprueba tamano de entrada
if (strcmp(pin_leido, pin_secreto) == 0){
printf("Acceso concedido, pin correcto\n");
}
else {
printf("Acceso denegado, pin incorrecto\n");
}
printf("PISTA:\n pin secreto: %s\n pin leido: %s\n", pin_secreto,pin_leido);
}
El programa implementa un control de acceso muy simple (y poco efectivo) basado en un pin aleatorio de 4
dgitos.
El c
odigo es vulnerable a un desbordamiento del buffer derivado del uso de la funcion gets()
2. Dise
nar un esquema que permita aprovechar el desbordamiento de buffer para sobrepasar el control de acceso
basado en pin aleatorio. Comprobar su funcionamiento.
Nota: En el caso de los equipos del laboratorio de practicas usan una version reciente del compilador GCC que
por defecto protege todos elementos de la pila contra desbordamiento de buffer (no solo la direccion de retorno).
Para poder realizar el ejemplo en esos equipos es necesario compilar con las opciones -fno-stack-protector
(deshabilita la protecci
on de pila) y -mno-sse (deshabilita las extensiones SSE en arquitecturas de 64 bits [hace
que se asigne el espacio en la pila en bloques/fronteras de 16 bytes]) del compilador gcc
3. Por defecto el compilador GCC compila el codigo con la opcion -fstack-protector-all (proteccion de pila).
C
omo funciona este mecanismo de proteccion de pila en GCC y que sucede si se introduce un PIN de gran
tama
no (5 bytes)?
4. Comprobar lo que sucede si se sustituye la llamada a gets(pin_leido) por una llamada a fgets(pin_leido, 4, stdin)

1.1.

Documentaci
on a entregar

Entregable: Documentar brevemente las cuestiones 2, 3 y 4 del ejemplo de desbordamiento de buffer.

2.

Entorno de pruebas

Im
agenes de partida
1. Script de instalaci
on: ejercicio-modsecurity.sh
2. Ejecutar desde el directorio de descarga
alumno@pc:~$ bash ejercicio-modsecurity.sh
3. El script descargar
a las siguientes im
agenes en el directorio $HOME/SSI1314
atacante.vdi: Imagen VirtualBox de la maquina con el framework Metasploit y otras herramientas complementarias (empleado en la pr
actica anterior).
modsecurity.vdi: Imagen VirtualBox de una maquina con aplicaciones web vulnerables
2

swap.vdi: Imagen VirtualBox de una unidad de disco formateada como SWAP

Usuarios configurados.
login
root
usuario1

password
purple
usuario1

4. Se pedir
a un identificador (sin espacios) para poder reutilizar las versiones personalizadas de las imagenes creadas
5. Arrancar las instancias VirtualBOX (si no lo hacen desde el script anterior) desde el interfaz grafico o desde
la lnea de comandos.
VBoxManage startvm ATACANTE-<id>
VBoxManage startvm METASPLOITABLE-<id>
Importante: Despues de finalizar cada ejercicio terminar la ejecucion de la maquina virtual desde lnea de
comandos con halt o sudo halt o desde el interfaz grafico LXDE.

3.

Ejercicio 1: Vulnerabilidades tpicas en aplicaciones web

3.1.

Descripci
on

En este ejercicio veremos ejemplos simples de vulnerabilidades web. Usaremos una apliacion PHP de muestra muy
simplificada que no realiza ning
un tipo de comprobacion de las entradas que recibe y que permite Inyeccion de SQL
(que usaremos para burlar la comprobaci
on de login y password) y XSS (Cross Site Scripting). Tambien veremos un
ejemplo de software real, una versi
on antigua del software para blogs WordPress, con vulnerabilidades XSS.
Por u
ltimo en la m
aquina virtual se encuentran instaladas tres aplicaciones web vulnerables para ser usadas con fines
did
acticos.

3.2.

Aplicaciones vulnerables (Cross Site Scripting: XSS)

3.2.1.

Foro simple vulnerable

En la m
aquina modsecurity hay una implementacion de un foro de juguete en PHP.
C
odigo fuente en: /var/www/foro
Cuenta con 2 usuarios creados (ana y pepe) ambos con password ssi
Desde la m
aquina atacante:
1. Abrir la direcci
on http://modsecurity.ssi.net/foro en un navegador WEB
2. Entrar como ana (password ssi)
A
nadir un mensaje con una parte de su ttulo y otra del cuerpo encerrada entre las etiquetas HTML de
texto en negrita: (<b>....</b>)
Revisar la lista de mensajes para comprobar que las marcas HTML incluidas en las entradas entrada se
copian 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 m

aquina atacante acceder a la URL http://modsecurity.ssi.net/foro con
las credenciales del usuario pepe (con password ssi) y entrar en el listado de mensajes
Se comprueba la ejecuci
on del c
odigo del ataque XSS preparado por ana
Un atacante real (el papel de ana) inyectara codigo Javascript mas da
nino, normalmente con la finalidad de
hacerse con informaci
on relevante del usuario atacado (el papel de pepe). Tpicamente se tratara de robar
cookies o informaci
on de la sesi
on abierta por el usuario atacado desde su navegador, para almacenarla con la
finalidad de suplantar la sesi
on de un usuario legtimo o incluso hacerse con el control del navegador del usuario
(ver Browser Exploitation Framework (BeEF)).

3.3.

Aplicaciones vulnerables (Inyecci

on SQL)

3.3.1.

Inyecci
on SQL Foro simple vulnerable

Desde la m
aquina atacante
Volver a la p
agina de inicial del foro: 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 c
omo se accede la aplicaci
on accede como un usuario autorizado (el primero de la base de datos)
En la m
aquina modsecurity, comprobar c
omo sera la consulta SQL que usara esos parametros (ver el c
odigo
en /var/www/foro/login.php)
root:~# leafpad /var/www/foro/login.php &

3.3.2.

Inyecci
on SQL en Wordpress 1.5.1.1

Ejemplo de vulnerabilidad en una versi

on antigua del software para blogs WordPress.
Los ataques de Inyecci
on SQL no tienen por que limitarse al acceso a traves de campos de formulario. En este caso el
c
odigo SQL inyectado se incluye en la barra de direcciones (en un parametro de la URL que se enva en la petici
on
HTTP GET)
1. Abrir desde el navegador de la m
aquina atacante la url del blog: http://modsecurity.ssi.net/wordpress
2. El usuario y el login de este blog son:
usuario: admin
passwd: secreto

3. Probaremos la inyecci
on SQL sobre los par
ametros de la consulta de categorias (http://modsecurity.ssi.net/wordpress/
a) Poner en barra de direcciones: (sin espacios)

http://modsecurity.ssi.net/wordpress/index.php?cat=999%20UNION%20SELECT%20null,CONCAT(CHAR(58),user_pass,CHA

Nota: puede copiarse y pegarse esta URL desde el archivo /root/aplicaciones_vulnerables/wordpress/url-wordp

de la m
aquina virtual modsecurity
b) Se mostrar
a en la columna derecha (zona de lista de categoras) 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 su
password
Para 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 lnea de comandos: echo -n "secreto" | md5sum

3.4.

Aplicaciones vulnerables educativas

En la m
aquina virtual modsecurity se encuentra instaladas tres aplicaciones vulnerables (2 en PHP y 1 en Java)
dise
nadas para experimentar con ellas.
Damm Vulnerable Web App en http://modsecurity.ssi.net/dvwa, con login admin y password password
Implementa ejemplos de XSS e inyecci
on SQL y otras vulnerabilidades en tres niveles de dificultad
Web: http://www.dvwa.co.uk/
Mutillidae (NOWASP) en http://modsecurity.ssi.net/mutillidae
Web: http://sourceforge.net/projects/mutillidae/
WebGoat en http://modsecurity.ssi.net:8080/WebGoat/attack, con login guest y password guest
Instalaci
on 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

3.5.

Documentaci
on a entregar

Entregable:
Documentar las pruebas realizadas en los apartados 3.2 (Cross Site Scripting) y 3.3 (Inyeccion SQL), indicando
los resultados obtenidos.
En el caso de las pruebas sobre el foro vulnerable (secciones 3.2.1 y 3.3.1) indicar si es posible los fragmentos
de c
odigo fuente PHP del foro que est
an implicados en dichas vulnerabilidades.
En el caso (opcional) de haber realizado alguna prueba adicional con las aplicaciones vulnerables educativas
aportadas (DVWA, Mutillidae, WebGoat) documentar las mismas.

4.
4.1.

Ejercicio 2: Instalaci
on y experimentaci
on con mod-security
Descripci
on de mod-security

Resumen mod-security: pdf

Web: http://www.modsecurity.org/
Reglas mod-security:
OWASP ModSecurity Core Rule Set Project: https://www.owasp.org/index.php/Category:OWASP_ModSecurity_
Core_Rule_Set_Project
Atomi ModSecurity Rules: http://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules

4.2.

Instalaci
on y configuraci
on

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 m
aquina modsecurity est
an 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 configuraci
on 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 a

nadir 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 b
asico
completo)
5. Habilitar el m
odulo 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.

6. Repetir las pruebas de inyecci
on 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 maquina modsecurity, no con su direcci
on IP.
(http://modsecurity.ssi.net/foro, etc)
6

4.3.

Documentaci
on a entregar

Entregable:
Documentar las pruebas realizadas en los puntos 6 y 8 del ejemplo de instalacion de Mod-Security, indicando los
resultados obtenidos (si se considera oportuno, pueden mostrarse fragmentos de log relevantes, etc).