Vulnerabilidades Web y uso de mod-security SSI 2013/14 29 de octubre de 2013
´Indice 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´´on on SQL Foro ”simple” vulnerable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
3.3.2. Inyecci Inyecci´´on on SQL en Wordpress 1.5.1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
3.4. Aplicacion Aplicaciones es vulnerables vulnerables educativas educativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3.5. Documentaci´ Documentaci´ on on a entregar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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´n y configuraci´on on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
4.3. Documentaci´ Documentaci´ on on a entregar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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´odigo 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´odigo es vulnerable a un desbordamiento del buffer derivado del uso de la funci´on 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´on reciente del compilador GCC que por defecto protege todos elementos de la pila contra desbordamiento de buffer (no s´olo la direcci´on 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 c´odigo con la opci´on -fstack-protector-all (protecci´on de pila). ¿C´ omo funciona este mecanismo de protecci´on 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´a las siguientes im´agenes 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´a un identificador (sin espacios) para poder reutilizar las versiones personalizadas de las im´agenes creadas 5. Arrancar las instancias VirtualBOX (si no lo hacen desde el script anterior) desde el interfaz gr´afico o desde la l´ınea de comandos. VBoxManage startvm ATACANTE- VBoxManage startvm METASPLOITABLE-
Importante: Despu´ es de finalizar cada ejercicio terminar la ejecuci´o n de la m´ aquina virtual desde l´ınea de comandos con halt o sudo halt o desde el interfaz gr´afico 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´on PHP de muestra muy simplificada que no realiza ning´un tipo de comprobaci´on de las entradas que recibe y que permite Inyecci´on de SQL (que usaremos para burlar la comprobaci´on de login y password) y XSS ( Cross Site Scripting ). Tambi´en 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 implementaci´on 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 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´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) inyectar´ıa c´odigo Javascript m´as da˜ nino, normalmente con la finalidad de hacerse con informaci´on relevante del usuario atacado (el papel de pepe). T´ıpicamente se tratar´ıa 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 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´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 p´agina de login. Indicar lo siguiente en la casilla usuario: usuario: ’ or 1=1 ; # password:
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 ser´ıa la consulta SQL que usar´ a esos par´ametros (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 trav´ es de campos de formulario. En este caso el c´ odigo SQL inyectado se incluye en la barra de direcciones (en un par´ametro de la URL que se env´ıa 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,CH
Nota: puede copiarse y pegarse esta URL desde el archivo /root/aplicaciones_vulnerables/wordpress/url-wordp de la m´aquina 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´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 (Inyecci´on 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_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´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 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´on SQL y XSS sobre el foro y wordpress Editar /etc/modsecurity/modsecurity.conf para establecer el par´ametro SecRuleEngine a On Nota: el acceso a las URL debe hacerse con el nombre de la m´ aquina 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 instalaci´on de Mod-Security, indicando los resultados obtenidos (si se considera oportuno, pueden mostrarse fragmentos de log relevantes, etc).
7