Curiosidades De Hackers: marzo 2024

Vulnerabilidad Session Puzzling(Session Fixation , Session Variable); Explicación y PoC

   Session Puzzling es una vulnerabilidad a nivel de aplicación que ocurre cuando la variable de sesión de la aplicación se utiliza para más de un propósito. Otro nombre para la sesión Puzzling es la sobrecarga de variables de sesión.

   El atacante intenta acceder a los puntos de entrada de la aplicación. La creación de objetos de sesión puede iniciarse de manera indirecta mientras se explotan las Session Puzzling y luego explotarse, accediendo a un punto de entrada como servicios web, páginas web, llamadas a procedimientos remotos, etc.

   La Session Puzzling permite a los atacantes eludir la autenticación, suplantar a usuarios legítimos, elevar privilegios, eludir restricciones de flujo e incluso ejecutar ataques adicionales. A esto de le suma Session Fixation y Session Variable que afectan a la manera en que se gestionan las sesiones en las aplicaciones web.

   Session Fixation ocurre cuando un atacante establece un identificador de sesión válido para un usuario y espera a que este inicie sesión. Una vez que el usuario lo hace, el atacante puede acceder a su sesión y llevar a cabo acciones maliciosas en su nombre. Esto puede lograrse engañando al usuario para que utilice un enlace con un identificador de sesión válido o aprovechando una debilidad en la aplicación para establecer el identificador de sesión.

   Session Variable, por otro lado, es un tipo específico de ataque de Session Fixation donde el atacante envía una gran cantidad de datos a la aplicación web con el fin de saturar las variables de sesión. Si la aplicación no valida adecuadamente la cantidad de datos que pueden almacenarse en estas variables, el atacante puede sobrecargarlas con datos maliciosos, causando problemas de rendimiento.

   Para prevenir estas vulnerabilidades, es crucial utilizar identificadores de sesión aleatorios y seguros, validar la autenticación y autorización del usuario antes de establecer una sesión, y limitar la cantidad de datos que pueden almacenarse en las variables de sesión, además de separar claramente las funciones de cada variable de sesión, validar y sanitizar las entradas de usuario, utilizar prácticas de gestión de sesiones seguras, implementar un control de acceso basado en roles, realizar revisiones de código y pruebas de penetración, monitorizar y registrar actividades para detectar posibles ataques, y educar a desarrolladores y usuarios sobre buenas prácticas de seguridad.

PoC

Nos encontramos frente a un panel de inicio de sesión

Acedemos mediante Admin/Admin y podemos ver información confidencial puesto que somos administradores.

Estando logueado podemos ver un JWT;

El cual en esta pagina podemos ver la estructura del mismo. Nos representa un log y username

Ahora, supongamos que el usuario cierra sesión y olvida su contraseña, intenta recuperarla proporcionando su nombre de usuario (admin) y si el nombre de usuario es válido, la aplicación indica que debería recibir su nueva contraseña a través de un correo electrónico.

Ponemos el usuario admin, y lo interceptamos con Burpsuite

Al interceptarlo nos da una cookie de sesión, la cual si nos lo traemos a nuestro dashboard, podemos acceder a páginas autenticadas sin iniciar sesión en la aplicación, lo que demuestra que podemos eludir con éxito el mecanismo de autenticación.

Todo esto viene dado a que si nosotros creamos una sesión, la construimos en una url y la mandamos a nuestra victima, el accedería mediante esa cookie de sesión y nosotros al recargar veríamos su sesión.

Ataque de Deserialización Pickle (DES-Pickle): Explicación y PoC

   Un ataque de Deserialización Pickle (DES-Pickle) es un tipo de vulnerabilidad que puede surgir en aplicaciones Python que utilizan la biblioteca Pickle para serializar y deserializar objetos.

   La vulnerabilidad aparece cuando un intruso consigue controlar la entrada Pickle que se suministra a una función de deserialización en la aplicación. Si el código de la aplicación no valida de manera apropiada la entrada Pickle, podría permitir que un intruso inyecte código malicioso en el objeto deserializado.

   Una vez que el objeto ha sido deserializado, el código malicioso podría ejecutarse dentro del contexto de la aplicación, lo que posibilitaría al intruso hacerse con el control del sistema, acceder a información delicada, o incluso ejecutar código de manera remota.

   Los intrusos pueden aprovechar las vulnerabilidades de DES-Pickle para llevar a cabo ataques denegación de servicio (DoS), inyectar código maligno, o incluso hacerse con el control total del sistema.

   El impacto de un ataque de Deserialización Pickle depende del tipo y la sensibilidad de los datos obtenidos, pero podría ser extremadamente grave. Por lo tanto, resulta fundamental que los desarrolladores de aplicaciones Python validen y filtren adecuadamente la entrada Pickle suministrada a las funciones de deserialización, y que empleen técnicas de seguridad como la restricción de recursos para prevenir ataques DoS y la desactivación de la deserialización automática de objetos no confiables.

   La serialización se emplea en las aplicaciones para almacenar de forma sencilla un objeto y transferirlo a través de sistemas y redes. Si una aplicación requiere almacenar una instancia de una clase, puede emplear la serialización para obtener una representación en cadena de dicho objeto. Cuando la aplicación o cualquier otra necesite utilizar nuevamente la instancia, deserializará la cadena para recuperar el objeto.

PoC

Comenzamos y tenemos un panel de la web

Si le echamos un ojo al código;

Este código Python define una ruta en una aplicación web usando Flask. Cuando se recibe una solicitud POST en la ruta "/sync", la función `deserialization()` se ejecuta. Esta función toma datos de un formulario, los convierte de hexadecimal a bytes y los escribe en un archivo. Luego carga los datos del archivo usando pickle para deserializarlos y los muestra en una página HTML renderizada. Es importante tener cuidado con la deserialización de datos, ya que puede ser una operación peligrosa si los datos provienen de fuentes no confiables.

En el proceso de deserializacion la podemos controlar e indicar como queremos que deserialice o que queremos que ejecute:

Creamos un script que crea las palabras es ASCII:

Este código crea un objeto serializado por Pickle de una llamada a os.system pasando sleep 5 como argumento. La deserialización de esta clase debería hacer que el sistema se duerma durante 5 segundos. Vamos a ejecutar el exploit y ver la salida.

Lo ejecutamos y nos da la cadena;

Si la pegamos en la web;

Vemos la pestaña de Red y vemos de que la solicitud sincrónica tarda aproximadamente 5 segundos en responder. Esto demuestra que el comando sleep 5 se ejecutó correctamente y se logró la Ejecución Remota de Código.

Si ahora en vez de hacer la llamada a os.system pasando sleep 5 como argumento, pasamos una reverse shell;

Ejecutamos el exploit;

Y pegamos la cadena en la web estando en escucha con netcat

Conseguimos tener una reverse shell.

Os dejo el video explicativo en mi canal de YouTube

Vulnerabilidad Cross-Site Scripting (XSS): Explicación y PoC

Los ataques XSS pueden acarrear consecuencias graves tanto para las empresas como para los usuarios individuales. Por este motivo, resulta fundamental que los desarrolladores web implementen medidas de seguridad adecuadas para prevenir este tipo de vulnerabilidades. Estas medidas pueden incluir la validación de los datos de entrada, la eliminación del código HTML peligroso y la restricción de los permisos de JavaScript en el navegador del usuario.

Los ataques de Cross-Site Scripting (XSS) implican la inserción de código malicioso en sitios web, a menudo considerados seguros. Este tipo de ataque ocurre cuando los ciberdelincuentes insertan scripts dañinos en el contenido de un sitio web comprometido, que luego se incorpora al contenido dinámico enviado al navegador del usuario. El navegador del usuario, al no discernir la naturaleza maliciosa de los scripts, los ejecuta. Esta ejecución posibilita que los scripts accedan a cookies, tokens de sesión y otra información sensible almacenada por el navegador y utilizada en el sitio afectado. Además, los atacantes pueden propagar malware, modificar el contenido de sitios web y llevar a cabo ataques de phishing para obtener credenciales de usuario.

Dado que JavaScript se ejecuta en el navegador del usuario, los detalles de la sesión del usuario autenticado pueden ser robados, permitiendo a los atacantes dirigirse a los administradores del sitio y causar daños. Dependiendo de cómo se inyecte el código, el contenido malicioso puede no estar presente en la página web en sí, sino que solo aparece temporalmente durante el ataque, lo que puede dar la impresión de que el sitio está en peligro cuando no es así.

Los ataques de XSS pueden desencadenarse de varias formas, como la ejecución automática al cargar la página o al pasar el cursor sobre elementos específicos, como hipervínculos. En algunos casos, el XSS puede ocurrir de manera más directa, por ejemplo, a través de un correo electrónico malicioso. Algunos ataques de XSS no tienen un objetivo específico, aprovechando cualquier vulnerabilidad en la aplicación o el sitio.

Existen diversas modalidades de vulnerabilidades XSS, entre las que se incluyen:

- Reflejado: Esta forma de XSS ocurre cuando los datos ingresados por el usuario se reflejan en la respuesta HTTP sin ser debidamente validados. Esto permite que un atacante inyecte código malicioso en la respuesta, el cual luego se ejecuta en el navegador del usuario.

- Almacenado: Esta variante de XSS ocurre cuando un atacante logra guardar código dañino en una base de datos o en el servidor web que aloja una página web vulnerable. Este código se ejecuta cada vez que la página es cargada.

- DOM-Based: Esta forma de XSS ocurre cuando el código malicioso se ejecuta en el navegador del usuario a través del DOM (Modelo de Objetos del Documento). Esto sucede cuando el código JavaScript en una página web modifica el DOM de una manera que es susceptible a la inyección de código dañino.

Dependiendo de la gravedad del ataque, las cuentas de usuario pueden comprometerse, pueden activarse troyanos y el contenido de la página puede ser modificado para engañar a los usuarios y obtener sus datos privados. Las cookies de sesión también pueden ser expuestas, lo que permitiría a los atacantes hacerse pasar por usuarios reales y explotar sus cuentas privadas.

Si un ataque de Cross-Site Scripting tiene éxito, puede tener consecuencias devastadoras para la reputación de una empresa en línea y su relación con los clientes. Lamentablemente, los errores que permiten estos ataques son bastante comunes y pueden explotarse en varios entornos de programación, incluyendo VBScript, Flash, ActiveX y, especialmente, JavaScript debido a su estrecha integración con la mayoría de los navegadores. Esta capacidad para afectar plataformas ampliamente utilizadas hace que los ataques de XSS sean peligrosos y prevalentes.

PoC 1

Para la prueba de concepto utilizaremos el laboratorio Gossip World!

Al abrir la web tenemos un panel de registro. Así que nos vamos a registrar y vamos a ver que nos encontramos.

Vemos un buscador y vamos a lanzar el script básico de reconocimiento para ver si es vulnerable a XSS

Como vemos si es vulnerable, llegados a este punto podríamos realizar diversos ataques.

Como al registrarnos nos da la opcion de escribir articulos, vamos a crear uno, en este articulo vamos a hacer que cuando algun visitante vaya a leerlo le sale un popup solicitandole en correo para poder continuar.

Este script solicitará al usuario que ingrese su dirección de correo electrónico. Si el usuario proporciona una dirección de correo electrónico, el script realizará una solicitud a un servidor remoto utilizando la función fetch(), enviando la dirección de correo electrónico como parte de la URL de la solicitud.

Como vemos nos a pedido un correo, y teniendo levantado un servidor en Python(por ejemplo) nos lo va a mandar

Y vemos el correo proporcionado.

PoC 2

Otro caso de uso seria solicitando al usuario que se valide mediante usuario y contraseña para poder ver el articulo

Este script creara un formulario solicitando al usuario que ingrese su dirección de correo electrónico y su contraseña.

Una vez que el usuario ingresa su dirección de correo electrónico y contraseña y hace clic en el botón "Submit", se llama a la función submitForm(). Esta función recupera los valores ingresados por el usuario para la dirección de correo electrónico y la contraseña y realiza una solicitud a un servidor remoto utilizando la función fetch(). La dirección de correo electrónico y la contraseña se incluyen como parámetros en la URL de la solicitud.

Y vemos como efectivamente nos a llegado el email junto al usuario

PoC 3

En este otro caso lo haremos utilizando un keylogger

Este script está configurado para registrar cada tecla presionada por el usuario y enviar esa información a un servidor en python.

Cuando el usuario presiona una tecla, el evento onkeypress se activa, lo que desencadena la ejecución de la función asociada. Esta función captura la tecla presionada utilizando el objeto de evento e, y luego concatena esa tecla a la variable k. Posteriormente, se crea un nuevo objeto de imagen (<img>), y se establece su atributo src para que apunte a una URL específica en un servidor remoto, incluyendo la información de las teclas presionadas hasta el momento como parte de la URL.

Y vemos que nos devuelve todas las teclas pulsadas por el usuario.

Como vemos lar oportunidades de aprovechar un XSS son inmensas y puede desencadenar grandes desastres, os dejo mas información sobre otro articulo que escribí profundizando de forma teorica sobre los XSS y como podemos mitigar esta vulnerabilidad

Qué es un ataque de XSS o Cross-Site Scripting, qué consecuencias tiene, qué tipos hay y cómo protegernos

Ataques de asignación masiva (Mass-Asignment Attack) Parameter Binding; Explicación y PoC

   El ataque de asignación masiva (Mass Assignment Attack) se basa en la manipulación de parámetros de entrada de una solicitud HTTP para crear o modificar campos en un objeto de modelo de datos en la aplicación web. En lugar de agregar nuevos parámetros, los atacantes intentan explotar la funcionalidad de los parámetros existentes para modificar campos que no deberían ser accesibles para el usuario.

   Por ejemplo, en una aplicación web de gestión de usuarios, un formulario de registro puede tener campos para el nombre de usuario, correo electrónico y contraseña. Sin embargo, si la aplicación utiliza una biblioteca o marco que permite la asignación masiva de parámetros, el atacante podría manipular la solicitud HTTP para agregar un parámetro adicional, como el nivel de privilegio del usuario. De esta manera, el atacante podría registrarse como un usuario con privilegios elevados, simplemente agregando un parámetro adicional a la solicitud HTTP.

   Muchos marcos de aplicación web ofrecen características de registro activo y mapeo objeto-relacional, donde los datos externos en formatos de serialización se convierten automáticamente en objetos internos al ingresar y, a su vez, en campos de registro de la base de datos. Si la interfaz del marco para esa conversión es demasiado permisiva y el diseñador de la aplicación no marca campos específicos como inmutables, es posible sobrescribir campos que nunca se pretendió modificar desde el exterior (por ejemplo, permisos de administrador).

PoC 1

Para la primera prueba de concepto utilizaremos el laboratorio Juice-Shop

Tenemos un panel de registro y vamos a interceptar la petición de registro.

Vemos que los datos se tramitan en formato JSON y vamos a intentar añadirle parametros para ver si cuela

Le metemos un nuevo role y nos registra como admin, nos toma en cuenta por los parámetros, puesto que no esta sanitizado y confía en que la solicitud no va a ser manipulada

PoC 2

En esta prueba de concepto usaremos el laboratorio skf-labs parameter-binding

Tenemos un panel en el que encontramos una tabla con algunos detalles sobre los usuarios

Si echamos un ojo al código fuente, descubrimos que utiliza un marco ORM para escribir consultas em la base de datos. Esta línea de código es crucial para explotar el ataque puesto que nos permite añadir todos los atributos se pasen al modelo

Y necesitamos examinar las propiedades del modelo "user";

Como vimos al inicio encontramos una tabla con algunos detalles sobre los usuarios activos.

Cuando hacemos clic en un usuario para actualizar su configuración, descubrimos que la aplicación no tiene la intención de que actualicemos la propiedad "privileged".

Si recordamos la linea señalada anteriormente, no encontramos con el método "permit" que devuelve una copia de los parámetros con solo las claves permitidas. Al crear un nuevo modelo, solo se envían los atributos permitidos. Sin embargo, si no se especifican atributos permitidos, todos los atributos se pasan al modelo. Esto permite abusar del enlace automático de parámetros para actualizar propiedades como "is_admin" al agregar parámetros adicionales a la solicitud.