Uso Modsecurity

Vulnerabilidades Web y uso de mod-security SSI 2013/14 29 de octubre de 2013

Índice 1. Previo: Previo: reto de desbordamiento desbordamiento de buffer

1

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

2

2. Entor Entorno no de prueba pruebass

2

3. Ejercicio 1: Vulnerabilidades t´ıpicas en aplicaciones web

3

3.1.. Descri 3.1 Descripci´ pci´ on on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

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

3

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

3

3.3. Aplicacion Aplicaciones es vulnerables vulnerables (Inyecci´ (Inyecci´ on on SQL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

3.3.1. Inyecci Inyecci´ón on SQL Foro ”simple” vulnerable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

3.3.2. Inyecci Inyecci´ón on SQL en Wordpress 1.5.1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

3.4. Aplicacion Aplicaciones es vulnerables vulnerables educativas educativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5


5

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

1.

5

4.1.. Descri 4.1 Descripci´ pci´ on on de mod-security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

4.2.. Instal 4.2 Instalaci aci´ on oń y configuración on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6


7

Previo Previo:: reto reto de de desbord desbordam amien iento to de de buffer buffer

1. Compilar Compilar y ejecutar ejecutar el siguiente siguiente código odigo C #include #include #include char* crear_pin_ crear_pin_aleat aleatorio orio() () { char* char* pin = (char (char *) malloc malloc(5) (5);; ;; srand( srand(tim time(0 e(0)); )); // Inicia Inicializ liza a genera generador dor de nos. nos. aleato aleatorio rios s sprintf(pin, "%04d", rand()%10000); return 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 d´ıgitos. El código es vulnerable a un desbordamiento del buffer derivado del uso de la función 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 pr´ acticas usan una versión reciente del compilador GCC que por defecto protege todos elementos de la pila contra desbordamiento de buffer (no sólo la dirección de retorno). Para poder realizar el ejemplo en esos equipos es necesario compilar con las opciones -fno-stack-protector (deshabilita la protección 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 código con la opción -fstack-protector-all (protección de pila). ¿C´ omo funciona este mecanismo de protección de pila en GCC y qu´ e 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á las siguientes imágenes en el directorio $HOME/SSI1314 aquina con el framework Metasploit y otras herramientas comatacante.vdi: Imagen VirtualBox de la m´ plementarias (empleado en la pr´ actica anterior). aquina con aplicaciones web vulnerables modsecurity.vdi: Imagen VirtualBox de una m´ 2

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

Usuarios configurados. login

password

root usuario1

purple usuario1

4. Se pedirá un identificador (sin espacios) para poder reutilizar las versiones personalizadas de las imágenes creadas 5. Arrancar las instancias VirtualBOX (si no lo hacen desde el script anterior) desde el interfaz gráfico o desde la l´ınea de comandos. VBoxManage startvm ATACANTE- VBoxManage startvm METASPLOITABLE-

Importante: Despu´ es de finalizar cada ejercicio terminar la ejecució n de la m´ aquina virtual desde l´ınea de comandos con halt o sudo halt o desde el interfaz gráfico LXDE.

3.

Ejercicio 1: Vulnerabilidades t´ıpicas en aplicaciones web

3.1.

Descripci´ on

En este ejercicio veremos ejemplos simples de vulnerabilidades web. Usaremos una apliación PHP de muestra muy simplificada que no realiza ningún tipo de comprobación de las entradas que recibe y que permite Inyección de SQL (que usaremos para burlar la comprobación de login y password) y XSS ( Cross Site Scripting ). También veremos un ejemplo de software real, una versión antigua del software para blogs WordPress, con vulnerabilidades XSS. Por u ´ ltimo en la máquina 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áquina modsecurity hay una implementación de un foro de juguete en PHP. Código fuente en: /var/www/foro Cuenta con 2 usuarios creados ( ana y pepe) ambos con password ssi Desde la máquina atacante: 1. Abrir la direcci´ on http://modsecurity.ssi.net/foro en un navegador WEB 2. Entrar como ana (password ssi ) Añadir un mensaje con una parte de su t´ıtulo y otra del cuerpo encerrada entre las etiquetas HTML de texto en negrita: (....) 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’’)

3

Desde otro navegador de la máquina 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ón del código del ”ataque” XSS preparado por ana Un atacante real (el papel de ana) inyectar´ıa código Javascript más da˜ nino, normalmente con la finalidad de hacerse con información relevante del usuario atacado (el papel de pepe). T´ıpicamente se tratar´ıa de ”robar” cookies o información de la sesión abierta por el usuario atacado desde su navegador, para almacenarla con la finalidad de suplantar la sesión de un usuario leg´ıtimo 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áquina atacante Volver a la página de inicial del foro: http://modsecurity.ssi.net/foro Veremos como acceder sin disponer de nombre de usuario ni clave en la página de login. Indicar lo siguiente en la casilla usuario: usuario: ’ or 1=1 ; # password:

Confirmamos cómo se accede la aplicación accede como un usuario autorizado (el primero de la base de datos) En la máquina modsecurity , comprobar cómo ser´ıa la consulta SQL que usar´ a esos parámetros (ver el código 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ón SQL no tienen por que limitarse al acceso a trav´ es de campos de formulario. En este caso el c´ odigo SQL inyectado se incluye en la barra de direcciones (en un parámetro de la URL que se env´ıa en la petición HTTP GET) 1. Abrir desde el navegador de la máquina 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ámetros 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,CH

Nota: puede copiarse y pegarse esta URL desde el archivo /root/aplicaciones_vulnerables/wordpress/url-wordp de la máquina virtual modsecurity a en la columna derecha (zona de lista de categor´ıas) el par: b ) Se mostrar´ 4

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 l´ınea de comandos: echo -n "secreto" | md5sum

3.4.

Aplicaciones vulnerables educativas

En la máquina 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ón 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.


Entregable: Documentar las pruebas realizadas en los apartados 3.2 (Cross Site Scripting) y 3.3 (Inyección 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ódigo fuente PHP del ”foro” que están 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_ModSecuri ty_ Core_Rule_Set_Project

Atomi ModSecurity Rules: http://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules

5

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áquina 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ásico completo) 5. Habilitar el módulo 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 detecci´ on (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 inyección SQL y XSS sobre el foro y wordpress Editar /etc/modsecurity/modsecurity.conf para establecer el parámetro SecRuleEngine a On Nota: el acceso a las URL debe hacerse con el nombre de la m´ aquina modsecurity , no con su dirección IP. (http://modsecurity.ssi.net/foro, etc) 6

4.3.


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

7

Uso Modsecurity

Recommend Documents