Curiosidades De Hackers: 2024

Vulnerabilidad Client-Side Template Injection (CSTI): Explicación y PoC

   El término Inyección de Plantillas en el Lado del Cliente (o CSTI por sus siglas en inglés, Client-Side Template Injection) hace referencia a una vulnerabilidad de seguridad en la que un atacante puede inyectar código malicioso en una plantilla de cliente, que se ejecuta en el navegador del usuario en lugar del servidor.

   A diferencia del Server-Side Template Injection (SSTI), en el que la plantilla de servidor se ejecuta en el servidor y es responsable de generar el contenido dinámico, en el CSTI, la plantilla de cliente se ejecuta en el navegador del usuario y se utiliza para generar contenido dinámico en el lado del cliente.

   Los atacantes pueden aprovechar una vulnerabilidad de CSTI para inyectar código malicioso en una plantilla de cliente, lo que les permite ejecutar comandos en el navegador del usuario y obtener acceso no autorizado a la aplicación web y a los datos sensibles.

   Una derivación común en un ataque de Client-Side Template Injection (CSTI) es aprovecharlo para realizar un ataque de Cross-Site Scripting (XSS).

   Una vez que un atacante ha inyectado código malicioso en la plantilla de cliente, puede manipular los datos que se muestran al usuario, lo que le permite ejecutar código JavaScript en el navegador del usuario. A través de este código malicioso, el atacante puede intentar robar la cookie de sesión del usuario, lo que le permitiría obtener acceso no autorizado a la cuenta del usuario y realizar acciones maliciosas en su nombre.

PoC

Nos encontramos ante un aplicativo web el cual utiliza AngularJS 1.5

Si intentamos inyectar etiquetas HTML para un ataque XSS, vemos que no podemos;

AngularJS analiza y renderiza cada expresión entre corchetes. Entonces, si pasamos una expresión aritmética, como {{7*7}}, deberíamos esperar 49 como resultado;

Ahora que sabemos que el aplicativo es vulnerable a una inyección de plantilla del lado del cliente, queremos hacer más que solo imprimir números agradables.

Al observar posibles payloads, encontramos una que funciona para Angular < = 1.5.0 en PayloadAllTheThings

Este payload define una expresión asincrónica la cual es interpretada por AngularJS como explicamos anteriormente y manipula un nodo de AST de JavaScript para crear una expresión con el fin de lanzar una alerta en el navegador del usuario

Como podemos ver, se ejecuta el Pop Up de "alert(1)" ejecutandose JavaScript;

Ahora podemos ejecutar código JavaScript en nuestro DOM. Este payload lo podemos modificar utilizando Python, es este le vamos a pedir cuando valdría en decimal la palabra CuriosidadesDeHackers;

Con la misma plantilla anterior usada modificamos el "Alert" y utilizaremos el método "String.fromCharCode()", Se utiliza en JavaScript para crear una cadena de caracteres a partir de los valores Unicode especificados. Toma una secuencia de números Unicode y devuelve una cadena que contiene los caracteres correspondientes a esos números Unicode.

Si lo ejecutamos vemos que nos lo muestra correctamente, esto lo podríamos derivar a diferentes ataques como un robo de cookie, obtener accesos no autorizados o realizar acciones en nombre de otro usuario.

Ataques de Deserialización: Explicación y PoC

   Los ataques de deserialización representan una amenaza significativa en el ámbito de la seguridad informática. Estos ataques se aprovechan de las debilidades en los procesos de serialización y deserialización de objetos en aplicaciones que utilizan la programación orientada a objetos (POO).

   La serialización, un proceso esencial en la transferencia de datos, convierte un objeto en una secuencia de bytes que puede almacenarse o transmitirse a través de una red. Por otro lado, la deserialización es la acción inversa, donde una secuencia de bytes se convierte de nuevo en un objeto. Los ataques de deserialización se producen cuando un atacante puede manipular los datos durante este proceso, lo que puede resultar en la ejecución de código malicioso en el servidor.

   Estos ataques pueden manifestarse en diversas aplicaciones, incluyendo aplicaciones web, móviles y de escritorio. Los atacantes pueden explotar estas vulnerabilidades de diferentes maneras:

      • Alterando el objeto serializado antes de su transmisión a la aplicación, lo que puede inducir errores en la deserialización y permitir la ejecución de código malicioso.

        • Enviando un objeto serializado malicioso que se aproveche de una vulnerabilidad en la aplicación para ejecutar código dañino.

        • Llevando a cabo un ataque de “man-in-the-middle” para interceptar y modificar el objeto serializado antes de su llegada a la aplicación.

   Estos ataques representan una seria amenaza, ya que podrían permitir a un atacante tomar el control completo del servidor o de la aplicación objetivo.

   Para mitigar estos riesgos, es fundamental que las aplicaciones validen y autentiquen meticulosamente todos los datos antes de proceder con la deserialización. Además, es esencial emplear bibliotecas de serialización y deserialización robustas y mantener actualizados todos los componentes de la aplicación para abordar posibles vulnerabilidades de seguridad.

PoC

Nos encotrasmos frente a un aplicativo web:

El cual tras capturarlo con burpsuite;

No encontramos frente a un objecto url-encodeado, si lo url-decodeamos vemos;

Nos encontramos con la estructurar la cual nos indica la cantidad de caracteres "0" y las strings "S"

Si echamos un vistazo al código del aplicativo entenderemos tod mejor;

Como podemos ver, hay una clase "pingTest" dentro del script. Podemos ver las diferentes variables dentro de la clase, como "ipAddress" e "isValid".

El script parece aceptar un objeto "pingTest" serializado a través de HTTP POST. Luego deserializa el objeto, llama a la función de validación y, a su vez, llama a la función ping. Por lo tanto, podemos ver que cuando escribimos una dirección IP en el aplicativo web y lo enviamos, Javascript serializa el objeto listo para PHP, y luego pasa ese objeto al script PHP. El script valida el valor de la dirección IP dentro del objeto y luego procede a pintarlo si la dirección IP es vailda.

Para hacer ping a la dirección IP, se llama al comando "shell_exec" que simplemente ejecuta el comando en el sistema local.

El aplicativo web no valida del todo el objeto "pingTest" enviado a través de la petición HTTP, podemos buscar establecer el booleano ‘ isValid ’, y engañar al aplicativo para que piense que la dirección IP sea un comando dándolo como valido puesto que confia en el input.

Crearemos un script con parte del código;

Al utilizar parte del código cambiando el "isValid" en "true", añadimos un "one liner" de una revshell y con el echo para que todo lo "url-encode" y lo "serialice". Como vemos, al ejecutarlo tenemos un objeto serializado con los datos del "one liner" incluido.

Copiamos todo el nuevo objeto y lo sustituimos en la petición HTTP capturada en burpsuite;

Estando a la escucha con NetCat, al ejecutarlo conseguimos una ejecución remota de comandos;

Inyecciones NoSQL; Explicación y PoC

       Las inyecciones NoSQL representan una amenaza significativa para la seguridad de las aplicaciones web que dependen de bases de datos NoSQL como MongoDB, Cassandra y CouchDB. Estas vulnerabilidades ocurren cuando los atacantes pueden introducir datos maliciosos en consultas de bases de datos, que luego son ejecutadas sin la debida validación o sanitización por parte de la aplicación.

   Al igual que las inyecciones SQL, las inyecciones NoSQL explotan vulnerabilidades específicas de las bases de datos NoSQL. Sin embargo, su enfoque difiere al aprovechar consultas basadas en documentos en lugar de tablas relacionales. En una inyección NoSQL, los atacantes pueden manipular consultas de base de datos para obtener información confidencial o realizar acciones no autorizadas.

   La falta de validación de datos en consultas a bases de datos NoSQL permite a los atacantes realizar estas manipulaciones. A diferencia de las inyecciones SQL, que se dirigen a bases de datos relacionales, las inyecciones NoSQL explotan la falta de validación en consultas a bases de datos NoSQL. Esta falta de validación significa que los atacantes pueden ejecutar consultas de manera no autorizada y acceder a datos sensibles sin restricciones.

   Para mitigar las vulnerabilidades de inyección NoSQL y proteger las aplicaciones web contra posibles ataques, es crucial implementar las siguientes prácticas de seguridad:

      •  Validación de entrada de datos: Validar cuidadosamente todos los datos ingresados por el usuario antes de procesarlos en consultas de base de datos. Esto puede incluir la verificación de tipos de datos, longitud y caracteres permitidos, así como la implementación de listas blancas (whitelists) para permitir solo entradas válidas.

         • Parámetros parametrizados o consultas preparadas: Utilizar parámetros parametrizados o consultas preparadas proporcionados por los marcos ORM (Mapeo Objeto-Relacional) o bibliotecas de acceso a datos. Estas técnicas aseguran que los datos proporcionados por el usuario se transmitan de manera segura a la base de datos, evitando así la ejecución no deseada de código malicioso.

      • Escapado de caracteres especiales: Escape de manera adecuada los caracteres especiales que podrían ser utilizados para realizar ataques de inyección. Esto implica convertir estos caracteres en su equivalente seguro para la base de datos antes de incluirlos en consultas.

•Aplicación del principio de menor privilegio: Limitar los privilegios de acceso de la aplicación a la base de datos. Específicamente, asegúrese de que la aplicación solo tenga acceso a las operaciones y datos necesarios para su funcionamiento, reduciendo así el impacto de posibles ataques.

•Actualizaciones y parches regulares: Mantener actualizados todos los sistemas y bibliotecas utilizados en el desarrollo de la aplicación, incluyendo el sistema operativo, el servidor web, la base de datos y cualquier software de terceros. Las actualizaciones y parches suelen incluir correcciones de seguridad que pueden mitigar vulnerabilidades conocidas.

• Monitorización y registro de actividades: Implementar sistemas de monitorización y registro de actividades para detectar y registrar posibles intentos de ataque. Esto permite una respuesta rápida ante posibles incidentes de seguridad y facilita la identificación de patrones de actividad maliciosa.

• Auditorías de seguridad regulares: Realizar auditorías de seguridad periódicas para evaluar la robustez de las medidas de seguridad implementadas y detectar posibles vulnerabilidades. Estas auditorías pueden ser realizadas internamente por el equipo de desarrollo o mediante la contratación de servicios externos de seguridad informática.

Al implementar estas prácticas de seguridad, se pueden reducir significativamente el riesgo de ataques de inyección NoSQL y proteger sus aplicaciones web contra posibles brechas de seguridad.

PoC

Nos encontramos frente a un dashboard de una maquina vulnerable la cual contempla Mongo como base de datos

Vamos a intentar iniciar sesión en el panel de login con usuarios y contraseñas por defecto;

Nos identifica la estructura por la cual se procesan los datos, vamos a capturar la petición con burpsuite;

Vemos que nos indica que el usurario o la contarseña son invalidos, tras aplicar numerosas inyecciones sql vamos a aplicar inyecciones NoSQL.

En este caso vamos a filtrar por el usuario "admin" y le vamos a indicar en el campo "password" mediante el operador "$ne" que la contraseña no es igual a admin;

Como vemos nos hemos conseguido loguear, si vamos un poco mas allá, en este caso vamos a utilizar el operador "$ne" en ambos casos para que diga que el usuario no es igual a "CuriosidadesDeHackers" y que la contraseña no es igual a "admin";

Conseguimos logearnos como administradores.

De la misma manera lo podemos hacer con el operador "$regex"(El operador $regex se utiliza para realizar coincidencias basadas en expresiones regulares en MongoDB) y con el operador "$ne".

Le indicamos que estamos buscando "documentos" donde el campo "username" mediante una expresión regular que comience con la letra "a" gracias al acento circunflejo. Y de la misma manera con el operador "$ne" le indicamos que la contraseña no sea igual a "admin".

Nuevamente nos logeamos somo administradores, en caso de que hubiera mas usuarios podríamos jugar con el operador "$regex" variando la letra

En el panel de busqueda si indicamos el usuario no nos da informacion;

Pero al cambiar la petición a POST y la estructura a JSON nos vuelca información confidencial;

En el mismo panel de búsqueda podemos utilizar cadenas, este caso jugaremos con la cadena "admin' || '' == '1", donde `'1' == '1' siempre es verdadero y al utilizar el operador o tuberías "||" (OR) la condición será siempre verdadera para "admin", como vemos nos vuelca información la cual no deberíamos de estar viendo;

PoC 2

En este otro escenario nos encontramos nuevamente frente a un panel de login;

Vamos a logeranos capturando la peticion con burpsuite, vemos que "nanai de la china limonera";

Vamos a utilizar los operadores "$ne" nuevamente, sin embargo, obtenemos un "302 Found", que se corresponde con una respuesta positiva de la base de datos;

Vamos a utilizar un script de PayloadsAllTheThings para conseguir extraer usuarios y contraseñas;

   Este script es un ejemplo de un ataque de inyección basado en MongoDB;

       1. Importa las bibliotecas necesarias, como "requests", "urllib3", "string", "re" y "time".
       2. Desactiva las advertencias de "urllib3"para evitar mensajes molestos.
       3. Define algunas variables importantes, como "username" y "password".
       4. Define la URL del objetivo "u" y establece los encabezados HTTP.
       5. Inicia un bucle infinito ("while True:") para realizar el ataque de manera continua.
       6. Itera a través de todos los caracteres imprimibles ("string.printable") y construye un payload para la solicitud POST. Este payload se inyecta en el campo "username" y contiene una expresión regular ("$regex") que coincide con la cadena "username" más un carácter ("c") de "string.printable".
       7. Realiza una solicitud POST al objetivo con el payload construido.
       8. Verifica si la respuesta tiene un código de estado 302 (Redirección encontrada). Esto puede indicar que se ha encontrado un usuario válido.
       9. Si se encuentra una redirección, imprime el carácter encontrado y lo agrega al "username".
       10. El bucle continúa hasta que se encuentran todos los caracteres del "username".

Utilizaremos "$regex" para filtrar por usuarios y nos muestres las coincidencias, como vemos, obtenemos el usuario "admin";

De la misma manera, al indicar en la variable "username="m" le estamos indicando que comience por la letra "m" y nos itere todos los caracteres validos restantes;

Una vez tenemos los usuarios, podemos modificar el script para que utilice el operador "$regex" en el campo de "password" utilizando como variable "username" los usuarios que hemos encontrado;

Al ejecutarlo nos va mostrando los caracteres validos para el usuario "admin";

Y de la misma manera para el usuario "mango";

Explotación de APIs: Explicación y PoC (2/2)

Como estuvimos viendo el la primera parte la explotación de APIs conlleva un gran peligro a nivel de seguridad tanto empresaria como de usuario:

Explotación de APIs: Explicación y Poc (1/2)

PoC 3: Cambio de contraseña a usuarios

En este caso vamos a intentar cambiar la contraseña a un usuario (nosotros), pero aplicaria a cualquier usuario;

En nuestro correo vemos que necesitamos un OTP, por lo tanto ya vemos que el OTP es un número entre 0000 y 9999;

La solicitud a sido tramitada por POST a un endpoint llamado "check-out";

Y en el cuerpo de la solicitud nos indica la estructura, así que podemos hacer fuerza bruta para obtener el OTP;

Lo añadimos a postman de la misma manera que hemos hecho anteriormente, si lo enviamos vemos que obviamente el OTP es incorrecto;

Pero con FUFF podríamos hacer fuerza bruta, indicamos que el Content-Type es en JSON para que se pueda tramitar bien y que nos muestre solo códigos de estado "200"

Pero vemos que tiene una limitación de peticiones llegando a dar error;

En el endpoint inicial vimos que la versión de la API que utilizaba era v3, pero en anteriores solicitudes que añadimos eran v2, de eso lo bueno de enumerar todos los endpoints posibles en postman, así que cambiamos la versión con el fin de que carezca de limitaciones de intentos;

Como vemos no tenemos limitación de intentos así que ahora si podríamos hacer fuerza bruta

En esta caso lo vamos a hacer con FFUF pero lo podríamos hacer mediante burpsuite con un ataque "snipper"

Obtenemos el OTP y conseguimos cambiar la contraseña del usuario, esto nos indica que se han dejado una versión de la API antigua. De la misma manera lo podríamos hacer con cualquier otro usuario.

PoC 4 : Obtención de cupones

Vamos a intentar añadir cupones, si enviamos un numero aleatorio tenemos la petición por POST al endpoint "validate-coupon";

Lo añadimos a a postman y añadimos la cuerpo de estructura, de primeras vemos que el cuerpo esta fallando puesto que el cupón es erróneo. Vamos a inspiramos en una colección de cargas útiles de inyección NoSQL disponibles en GitHub en PayloadsAllTheThings

Apoyándonos con el uso de la inyección NoSQL, indicamos que el código de cupón no es igual a 1;

Y nos responde con un cupón, el cual lo podemos validad correctamente;

PoC 5: Obtención de información de usuarios

En este caso tenemos un vehículo, y nos indica la localización del vehículo, si le damos a refrescar localización, vemos que envía una petición por GET al endopoint "locatión" junto con el identificador del vehículo

Vemos que en el cuerpo donde nos indica el nombre del propietario, localización y el id del vehículo;

Así que lo añadimos a postman indicando el cuerpo y el endpoint;

Si enumeramos la web encontramos con mas usuarios, el cual al seleccionar a uno de ellos, la API en la respuesta nos da la información de el: id del vehículo, localización, etc...;

Si cambiaos el identificado en la url, vemos que hemos sido capaz de enumerar la localización y más detalles del usuario