Práctica 3: Desbordamiento de Buffer y Vulnerabilidades Web SSI
1 Previo: reto de desbordamiento de buffer
Desbordamiento del búfer:
La vulnerabilidad de desbordamiento de búfer está presente en el código. La función
"gets()" no verifica el tamaño de la entrada, lo que permite escribir más allá del límite del
búfer "pin_leido". Este comportamiento puede causar problemas de seguridad. Debido a que
"pin_leido" es un array de cinco caracteres, solo admite entradas de hasta cuatro caracteres,
además del carácter nulo que indica el final de la cadena ("0”); El ingreso de un PIN de 5
dígitos o más causará un desbordamiento de búfer, que sobrescribirá la memoria adyacente,
en este caso el búfer "pin_secreto".
Al ingresar PINs de longitud superior a 4, se produce la alteración de "pin_secreto".
Por ejemplo, si se ingresa el PIN "12345", el valor de "pin_secreto" será el carácter de final
de la cadena (0, 0) en el caso de que el PIN sea "12345". El valor de "pin_secreto" será el
byte final si el PIN es "123456", y así sucesivamente. Esta acción permite alterar la
comparación de PINs para obtener un acceso no autorizado.
1 Gael Miguez Mendez
Práctica 3: Desbordamiento de Buffer y Vulnerabilidades Web SSI
Protección de pila:
Para evitar ataques de desbordamiento de búfer en la pila, se implementa la opción de
seguridad "-fstack-protector-all". El compilador introduce "canales aleatorios" en torno a las
variables locales y los registros de activación de funciones cuando se activa. Estos "canarios"
sirven como señales de advertencia, detectando cualquier intento de manipular la pila. En
nuestro ejemplo, al enviar un PIN de gran tamaño (más de 5 bytes), el programa no permite la
ejecución normal y muestra un mensaje de error como "*** stack smashing detected ***:
terminated; Abortado”.
Esquema para sobrepasar la protección de acceso:
Se puede introducir un PIN malicioso que sea lo suficientemente largo como para
sobrescribir otras variables en la pila, como la variable que almacena la comparación del PIN,
para aprovechar el desbordamiento de búfer y sobrepasar el control de acceso basado en el
PIN aleatorio. Esto permitiría el acceso no autorizado.
2 Gael Miguez Mendez
Práctica 3: Desbordamiento de Buffer y Vulnerabilidades Web SSI
Uso de `fgets()`:
Limitamos el tamaño máximo del búfer al reemplazar la llamada por "fgets(pin_leido,
5, stdin)". Esta medida evita problemas relacionados con la sobrescritura de memoria. La
función "fgets()" lee hasta cinco caracteres para evitar desbordamientos. Al imponer
restricciones a la entrada del usuario, esta modificación mejora significativamente la
seguridad del programa.
En resumen, la combinación de la vulnerabilidad de desbordamiento de búfer y la
protección de pila proporciona un escenario propicio para demostrar cómo un atacante podría
comprometer la seguridad del sistema. Además, la sustitución de `gets()` por `fgets()`
representa una práctica recomendada para evitar vulnerabilidades de desbordamiento de búfer
en futuras implementaciones.
3 Gael Miguez Mendez
Práctica 3: Desbordamiento de Buffer y Vulnerabilidades Web SSI
2 Vulnerabilidades típicas en aplicaciones web
Aplicaciones vulnerables (Cross Site Scripting: XSS)
1. Prueba de XSS Reflejado:
Acción Realizada: Se ingresó un mensaje con una parte de su título o cuerpo
encerrada entre las etiquetas HTML de texto en negrita <b>...</b>.
Resultado Obtenido: Las marcas HTML incluidas en las entradas se copiaron tal cual
en la lista de mensajes.
2. Ataque de XSS Persistente:
Acción Realizada: El usuario "ana" creó un mensaje nuevo incluyendo la etiqueta
<script> con comandos JavaScript.
Resultado Obtenido: Se espera que, al visualizar el listado de mensajes como el
usuario "pepe", se ejecute el código JavaScript incluido en el mensaje de "ana".
3. Comprobación desde la Máquina Víctima:
Resultado Obtenido: Se comprobó la ejecución del código JavaScript del "ataque"
XSS preparado por "ana". Se muestra un cuadro de alerta con el mensaje "esto admite
XSS".
4 Gael Miguez Mendez
Práctica 3: Desbordamiento de Buffer y Vulnerabilidades Web SSI
Ejemplo 1: despliegue del keylogger Javascript de Metasploit
1. Preparación del Entorno:
Inicio del servicio Metasploit Database (msfdb).
Inicio de la consola de Metasploit.
Selección del módulo http_javascript_keylogger.
Ejecución del módulo.
Resultado Esperado: El keylogger JavaScript está disponible
2. Despliegue del Ataque XSS Persistente:
Acceso al foro vulnerable desde la máquina atacante como "ana".
Creación de un nuevo mensaje con título "Un mensaje inocente" y contenido que
incluye la carga de la librería JavaScript del keylogger.
3. Verificación del Ataque XSS:
Acceso desde la víctima como "pepe" a la lista de mensajes para activar el keylogger.
Al solicitar la carga de la librería JavaScript, se accede a la URL donde el keylogger
de Metasploit está "escuchando".
Las pulsaciones de teclado en esa página serán capturadas.
5 Gael Miguez Mendez
Práctica 3: Desbordamiento de Buffer y Vulnerabilidades Web SSI
(Configuración del keyLogger)
Con esta configuración, conseguiremos que el keylogger esté disponible en
la URL: [Link]
Ejemplo 2: uso de BeeF
6 Gael Miguez Mendez
Práctica 3: Desbordamiento de Buffer y Vulnerabilidades Web SSI
1. Configuración de BeeF:
Inicio del demonio Beef-XSS en la máquina atacante.
Exposición de la librería JS en [Link]
Disponibilidad de la consola de control de Beef en [Link]
Resultado Esperado: La consola de control de BeeF se inicia, y se proporciona la
URL de la librería JS y la consola.
2. Despliegue del Ataque XSS con BeeF:
Acceso al foro vulnerable desde la máquina atacante como "ana".
Creación de un nuevo mensaje con título "Un mensaje inocente" y contenido que
incluye la carga de la librería JavaScript de BeeF.
3. Activación del Hook de BeeF:
Acceso desde la máquina víctima como "pepe" a la lista de mensajes para activar el
hook de BeeF.
4. Acceso a la Consola de Control de BeeF:
Acceso a la URL [Link] en la máquina atacante.
Observación de un nuevo zombie en [Link] en el panel de control Beef.
Posibilidad de lanzar comandos BeeF desde la pestaña Current Browser >
Commands.
7 Gael Miguez Mendez
Práctica 3: Desbordamiento de Buffer y Vulnerabilidades Web SSI
Haciendo uso de BeeF:
En la captura se muestra que después de que la computadora de la víctima fue
infectada con BeeF, se ha transformado en un "zombie", quedando vulnerable a una extensa
lista de comandos que el atacante puede ejecutar a través de su navegador. El comando
específico utilizado en esta captura es el siguiente:
Como resultado, en el ordenador de la víctima aparece un pop up del propio
navegador que nos incita a instalar un plugin:
8 Gael Miguez Mendez
Práctica 3: Desbordamiento de Buffer y Vulnerabilidades Web SSI
3 Aplicaciones vulnerables (Inyección SQL)
Inyección SQL Foro ”simple” vulnerable
1. Acceso a la Página de Inicio del Foro:
Desde la máquina atacante, se regresó a la página de inicio del foro:
[Link]
2. Inyección SQL para Acceder sin Credenciales:
En la casilla de usuario, se ingresó la siguiente cadena para realizar una inyección
SQL:
Usuario: ’ or 1=1 ; #
Contraseña: <vacío>
Se confirmó el ingreso para verificar el acceso a la aplicación como un usuario
autorizado (el primero de la base de datos).
3. Verificación de Acceso y Exploración de la Inyección SQL:
Se confirmó la manera en que la aplicación concede acceso como usuario autorizado,
demostrando la exitosa inyección SQL.
En la máquina ModSecurity, se verificó cómo sería la consulta SQL utilizada con esos
parámetros, examinando el código fuente en el archivo /var/www/html/foro/[Link].
La sentencia select final sería: SELECT id,nombre FROM usuarios where login=’’ or 1=1; la
cual siempre es verdadera por lo que proporciona acceso al foro.
9 Gael Miguez Mendez
Práctica 3: Desbordamiento de Buffer y Vulnerabilidades Web SSI
Extracción de información vía Inyección SQL en DVWA
1. Inicio de Sesión en DVWA:
Se inició sesión en la aplicación DVWA [Link] utilizando
el usuario "admin" y la contraseña "password".
2. Habilitación del Nivel de Seguridad Bajo:
Desde el menú lateral izquierdo, se habilitó el nivel de seguridad bajo desde el botón
"DVWA Security".
3. Acceso al Ejemplo de Inyección SQL:
Se accedió al ejemplo de Inyección SQL desde el botón "SQL Injection" en el menú
lateral izquierdo.
10 Gael Miguez Mendez
Práctica 3: Desbordamiento de Buffer y Vulnerabilidades Web SSI
4. Mostrar Información de Todos los Usuarios:
Se ingresó la siguiente tautología en la caja de búsqueda para que la condición del
WHERE sea siempre verdadera:
Tautología: ’ or ’a’=’a o alternativamente ’ or 1=1 #
Como resultado, se mostraron todos los registros de la tabla de usuarios, ya que la
condición siempre evalúa a verdadero.
5. Extracción de Información de Otras Tablas de la BD Usando UNION SELECT:
Se ingresó la siguiente consulta utilizando UNION SELECT para extraer información
sobre las tablas y columnas de la base de datos:
Consulta: ’ and 0=1 UNION SELECT table_name,column_name FROM
information_schema.columns;#
Como resultado, se mostraron los pares (tabla, columna) de todas las bases de datos
existentes en el servidor MySQL.
11 Gael Miguez Mendez
Práctica 3: Desbordamiento de Buffer y Vulnerabilidades Web SSI
6. Acciones Opcionales:
Se probó la siguiente consulta para extraer información específica de la tabla "users":
’ and 0=1 UNION SELECT user,password FROM users;#
El resultado mostró los nombres de usuario y contraseñas de la tabla "users".
CUESTIÓN 1.
Indicar como es la consulta que finalmente se envía a la BD en el punto 5 y
explicar por qué tiene éxito este ataque y se obtiene como resultado la lista de todos
los pares (tabla,columna).
La consulta final que se envía a la base de datos en el punto 5 del ejercicio de Inyección SQL
es la siguiente:
’ and 0=1 UNION SELECT table_name,column_name FROM
information_schema.columns;#
La técnica UNION SELECT se utiliza en esta consulta para combinar los resultados de dos
consultas. La primera parte de la consulta (and 0=1) crea una condición siempre falsa, lo que
anula la selección de datos de la consulta original y permite que solo se muestran los
resultados de la segunda consulta.
La segunda parte de la consulta, que se llama UNION SELECT table_name,column_name
FROM information_schema.columns, tiene como objetivo obtener información sobre las
tablas y columnas de la base de datos. En este caso, las columnas "nombre de la tabla" y
"nombre de la tabla" se han seleccionado de la tabla information_schema.columns.
12 Gael Miguez Mendez
Práctica 3: Desbordamiento de Buffer y Vulnerabilidades Web SSI
La modificación de la consulta original en el código del formulario de búsqueda es esencial
para el éxito de este ataque. La primera parte de la consulta original se anula al introducir una
condición siempre falsa (and 0=1), y la segunda parte de la consulta inyectada proporciona
los resultados deseados de la tabla information_schema.columns. Esto resulta en la obtención
de una lista de todos los pares (tablas o columnas) que se encuentran en la base de datos. Esto
revela la estructura de la base de datos y proporciona al atacante información sensible sobre
su diseño.
4 Instalación y experimentación con ModSecurity
Instalación y configuración (DetectionOnly)
Instalación de Paquetes Debian:
Se actualizaron los paquetes Debian.
Se instaló el módulo de seguridad2 de Apache y la colección de reglas Core Rule Set.
Descarga de Reglas del OWASP ModSecurity Core Rule Set Project:
Se descargaron las reglas del proyecto OWASP ModSecurity Core Rule Set desde
[OWASP ModSecurity Core Rule Set Project]([Link]
También se descargaron desde ([Link]
(ya incluido al instalar el paquete modsecurity-crs).
13 Gael Miguez Mendez
Práctica 3: Desbordamiento de Buffer y Vulnerabilidades Web SSI
Revisión de la Configuración por Defecto de ModSecurity:
Se revisó la configuración por defecto de ModSecurity en el archivo
`/etc/apache2/mods-available/[Link]`.
Se verificó la inclusión de las reglas de OWASP ModSecurity CRS en el archivo
`/usr/share/modsecurity-crs/[Link]`.
Configuración y Habilitación de Reglas OWASP:
Se accedió al directorio de configuración de ModSecurity.
Se renombró el archivo `[Link]-recommended` a `[Link]`.
Se realizó una edición importante para deshabilitar la notificación del uso de
ModSecurity a través de la red, editando el archivo
`/etc/modsecurity/[Link]` y estableciendo `SecStatusEngine` a `Off`.
Habilitación del Módulo Mod-Security en Apache y Reinicio del Servidor:
Se habilitó el módulo Mod-Security en Apache.
Se reinició el servidor Apache.
14 Gael Miguez Mendez
Práctica 3: Desbordamiento de Buffer y Vulnerabilidades Web SSI
Uso de modsecurity:
Se repitieron las pruebas sobre el "foro vulnerable" en el apartado 3.2 (Cross Site
Scripting).
Se verificaron las alertas generadas por ModSecurity.
Se localizaron algunas de las reglas de ModSecurity ejecutadas, se incluyeron en el
entregable y se explicaron brevemente:
Regla ModSecurity Ejecutada:
● Número de Regla: 941100
● Mensaje Asociado: "XSS Attack Detected via libinjection"
● Explicación Breve: La regla 941100 de ModSecurity se activó debido a la detección
de un ataque XSS utilizando la librería de inyección libinjection. Esta regla se disparó
cuando se encontraron datos coincidentes con un patrón de ataque XSS en el campo
"mensaje" de la solicitud POST a insertar_mensaje.php.
15 Gael Miguez Mendez
Práctica 3: Desbordamiento de Buffer y Vulnerabilidades Web SSI
Regla ModSecurity Ejecutada:
● Número de Regla: 941110
● Mensaje Asociado: "XSS Filter - Category 1: Script Tag Vector"
● Explicación Breve: La regla 941110 de ModSecurity se activó debido a la detección
de un vector de ataque XSS en el campo "mensaje". Esta regla detecta la presencia de
la etiqueta <script> en el contenido del mensaje.
Regla ModSecurity Ejecutada:
● Número de Regla: 941160
● Mensaje Asociado: "NoScript XSS InjectionChecker: HTML Injection"
● Explicación Breve: La regla 941160 de ModSecurity se activó debido a la detección
de una inyección HTML en el campo "mensaje". La regla detecta la presencia de la
etiqueta <script> y otros patrones asociados a inyecciones HTML.
Regla ModSecurity Ejecutada:
● Número de Regla: 949110
● Mensaje Asociado: "Inbound Anomaly Score Exceeded (Total Score: 15)"
● Explicación Breve: La regla 949110 de ModSecurity se activó debido a que el puntaje
total de anomalías entrantes superó el umbral establecido. En este caso, el puntaje fue
de 15, indicando la presencia de posibles ataques. Este puntaje se basa en diversas
reglas de detección aplicadas a la solicitud
Estos eventos están relacionados con la detección de un ataque XSS en el formulario
de inserción de mensajes en el foro vulnerable. Las reglas de ModSecurity han identificado y
registrado las posibles amenazas en los registros de errores y auditoría.
16 Gael Miguez Mendez
Práctica 3: Desbordamiento de Buffer y Vulnerabilidades Web SSI
Se repitieron las pruebas sobre el "foro vulnerable" en el apartado 3.3.1 (Inyección
SQL).
Se verificaron las alertas generadas por ModSecurity.
Se localizaron algunas de las reglas de ModSecurity ejecutadas, se incluyeron en el
entregable y se explicaron brevemente:
Regla ModSecurity Ejecutada:
● Número de Regla: 942100
● Mensaje Asociado: "SQL Injection Attack Detected via libinjection"
● Explicación Breve: La regla 942100 de ModSecurity se activó debido a la detección
de un ataque de inyección SQL mediante libinjection en el campo "login". Esta regla
detecta la presencia del patrón 's&1;c' en los datos enviados, lo que sugiere un intento
de inyección SQL.
17 Gael Miguez Mendez
Práctica 3: Desbordamiento de Buffer y Vulnerabilidades Web SSI
Instalación y configuración (Modo Rechazo)
Configuración de ModSecurity:
Se accedió al archivo de configuración de ModSecurity
/etc/modsecurity/[Link] mediante el comando:
Se modificó el parámetro SecRuleEngine a On, cambiándolo desde su valor por
defecto que era DetectionOnly.
Reinicio de Apache con la Nueva Configuración:
Se reinició el servicio de Apache para aplicar los cambios en la configuración de
ModSecurity.
Realización de Pruebas de Seguridad:
Se repitieron las pruebas de seguridad realizadas anteriormente en los apartados 3.2
(Cross Site Scripting) y 3.3.1 (Inyección SQL) sobre el foro vulnerable.
Durante las pruebas maliciosas, se esperaba recibir un error 403 del servidor, y las
alertas correspondientes se registrarían en los archivos de log
(/var/log/apache2/[Link] y /var/log/apache2/modsec_audit.log).
18 Gael Miguez Mendez
Práctica 3: Desbordamiento de Buffer y Vulnerabilidades Web SSI
Monitorización de Logs en Tiempo Real:
Se ejecutó el comando tail -f en un terminal diferente para monitorear en tiempo real
la generación de alertas ante cada uno de los accesos maliciosos.
Se ejecutó el comando tail -f en un terminal diferente para monitorear en tiempo realel
registro de errores de Apache:
Resultados Obtenidos:
La configuración de ModSecurity, en modo rechazo, impide la publicación de
mensajes en el foro que contengan la etiqueta <script> debido a restricciones de
permisos. Como resultado, se produce un error 403, denegando el acceso a la acción
de posteo de mensajes que incluyan este tipo de contenido considerado
potencialmente malicioso.
La configuración de ModSecurity en modo rechazo ha sido efectiva al prevenir la
ejecución de un ataque de inyección SQL durante el intento de inicio de sesión. Se
bloqueó la tentativa de utilizar la inyección SQL del tipo ' or 1 = 1; #, lo cual es un
intento común de evadir la autenticación mediante la explotación de la condición
siempre verdadera en la consulta SQL. Como resultado, se generó un error 403,
denegando el acceso y registrando la alerta correspondiente en los archivos de log de
ModSecurity.
19 Gael Miguez Mendez
Práctica 3: Desbordamiento de Buffer y Vulnerabilidades Web SSI
En el transcurso de estas prácticas, se exploraron y comprenden a fondo vulnerabilidades
comunes en aplicaciones web, como ataques XSS e Inyección SQL. Este método práctico
proporcionó una visión realista de los peligros de seguridad en el entorno web.
El uso de ModSecurity como sistema de prevención de intrusiones (WAF) se destacó como
una solución útil para reducir y bloquear intentos maliciosos. Se demostró que la capacidad
de configurar ModSecurity en modo rechazo era esencial para mejorar la seguridad de las
aplicaciones web.
En conclusión, estas prácticas han brindado una oportunidad valiosa para adquirir
conocimientos prácticos en seguridad informática, centrándose en problemas y soluciones
prácticas para proteger la integridad de las aplicaciones web.
20 Gael Miguez Mendez
