Curiosidades De Hackers: abril 2024

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

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

El abuso de las API (interfaz de programación de aplicaciones) es una preocupación cada vez mayor para las empresas y organizaciones que dependen de las API para proporcionar acceso a sus servicios y datos. El abuso de las API puede adoptar muchas formas, desde el acceso no autorizado y las filtraciones de datos a los ataques DDoS y el spam. Para evitar el abuso de las API, es esencial implementar medidas de seguridad de API sólidas.

   Cuando nos referimos al abuso de APIs, estamos hablando de la explotación de debilidades en las interfaces de programación de aplicaciones (APIs), las cuales facilitan la comunicación y el intercambio de datos entre diferentes aplicaciones y servicios en una red.

   Un ejemplo práctico de API es la integración de Google Maps en una aplicación de transporte. En lugar de crear su propio sistema de mapas, la aplicación puede utilizar la API de Google Maps para mostrar la ubicación del vehículo y la ruta hacia el destino del usuario.

   La API de Google Maps proporciona una serie de funciones y protocolos que permiten a la aplicación de transporte comunicarse con los servidores de Google para acceder a los datos necesarios y mostrar el mapa y la ruta. Además, la API se encarga de adaptar la visualización del mapa y la ruta a diferentes dispositivos y navegadores, permitiendo que la aplicación de transporte se concentre en su funcionalidad principal.

  Los endpoints de una API pueden aceptar varios métodos de solicitud, como GET, POST, PUT, DELETE, entre otros. Los atacantes pueden utilizar herramientas de fuzzing para enviar una gran cantidad de solicitudes a un endpoint en busca de vulnerabilidades. Por ejemplo, podrían realizar solicitudes GET para listar todos los recursos disponibles o enviar solicitudes POST para agregar o modificar datos.

   Entre las posibles vulnerabilidades que pueden ser explotadas a través del abuso de APIs se incluyen:

       1. Falta de autenticación y autorización adecuadas: Si una API no requiere autenticación o autorización adecuadas para acceder a ciertos recursos o realizar ciertas acciones, los atacantes podrían aprovechar esto para acceder a información confidencial o realizar operaciones no autorizadas.

       2. Validación inadecuada de datos de entrada: Si una API no valida correctamente los datos de entrada proporcionados por el usuario, los atacantes podrían enviar datos maliciosos diseñados para explotar vulnerabilidades en el sistema subyacente.

       3. Falta de cifrado en la transmisión de datos: Si una API no utiliza cifrado para proteger los datos transmitidos entre el cliente y el servidor, los atacantes podrían interceptar y leer la información confidencial transmitida a través de la red.

       4. Exposición de información sensible: Si una API expone más información de la necesaria o información sensible que no debería ser accesible públicamente, los atacantes podrían utilizar esta información para realizar ataques dirigidos o comprometer la seguridad de los usuarios.

   Para mitigar el abuso de APIs y proteger contra estas vulnerabilidades, los desarrolladores deben diseñar APIs seguras que implementen medidas de seguridad adecuadas, como la autenticación robusta, la validación adecuada de datos de entrada, el cifrado de datos y la limitación del acceso a la información sensible. Además, es importante realizar pruebas exhaustivas de seguridad, utilizando herramientas como Postman, para identificar y corregir posibles vulnerabilidades antes de que sean explotadas por los atacantes.

USO DE POSTMAN

Postman es una herramienta ampliamente utilizada para probar y depurar APIs. Con Postman, los desarrolladores pueden enviar solicitudes a diferentes endpoints y verificar las respuestas para asegurarse de que la API está funcionando correctamente. Sin embargo, los atacantes también pueden aprovechar Postman para explorar los endpoints en busca de vulnerabilidades y debilidades de seguridad.

Nos registramos e identificamos el token una vez logueados por el método POST

Vamos a representar esta petición por POST la cual nos muestra el endpoint, el cuerpo y el token

que se vincula en la cabecera para futura peticiones que hagamos

Instalamos POSTMAN:

Así que lo vamos a añadir en nuestro proyecto de POSTMAN, antes que nada tenemos que crear un proyecto y guardar cada uno de los endpoints dentro de ese mismo proyecto. Vamos a añadir esta petición de login en el formato que hemos visto anteriormente, es decir en formato POST y la estructura en JSON, para que el valor del content type sea en formato JSON y lo interprete

Creamos una nueva colección y le damos a new http request, indicamos la url con método POST, si le damos a enviar vemos el token que el servidor nos otorga

Para que nos sea mas fácil poder trabajar vamos a crear una variable con nuestro access token la cual se va a arrastrar a todas las peticiones que hagamos desde postman, siempre y cuando no cambie

Añadimos un nuevo endpoint en este caso del dashboard por método GET;

Si le damos a enviar vemos que nos interpreta perfectamente nuestro usuario sin necesidad de estar arrastrando manualmente el acccess token;

PoC 1: Compra de productos

En este caso vamos a comprar uno de los artículos disponibles en la tienda, donde vemos que tenemos un saldo disponible de $90 y dos elementos: ‘Seat’ y ‘Wheel’. Si hacemos un pedido y examinamos de cerca la solicitud y la respuesta de la API de la tienda;

Podemos ver una petición por GET al endpoint "products" y el cuerpo, lo añadimos a postman nuevamente con el fin de ir enumerando endpoints y le damos a enviar para hacer un pedido. Nos indicar el precio de los artículos y el saldo restante;

Vamos a comprar uno de los productos y vemos que hace una petición por POST al endpoint "orders" donde nos indica que el pedido a sido enviado correctamente;

Así que lo añadimos a postman. Si vemos el cuerpo del mensaje a nivel de respuesta vemos el identificador del articulo junto con el crédito restante;

Y a nivel de solicitud nos indica la cantidad y el identificar del productos

Añadimos el endpoint "orders" por el método POST y añadimos el cuerpo de la solicitud en formato JSON, si le damos a enviar vemos que se realiza correctamente y la cantidad restante del saldo va bajando

PoC 2: Incremento de productos en negativo

En esta ocasión vamos a intentar añadir productos con un saldo en negativo para que en el momento de hacer la compra podamos aumentar nuestro saldo.

Si nos acordamos de PoC anterior de "orders", la solicitud era por POST, así que vamos a cambiar la solicitud a OPTION para que nos diga que métodos acepta el endpoint y la API:

Como vemos acepta GET, POST ,HEAD y OPTIONS.

En el endpoint de productos la cual la petición era por GET la vamos a cambiar por POST y vemos que tenemos un cuerpo distinto, que involucra unos campos como para poder añadir productos;

Podemos probar a enviarle una cuerpo rellenado con un nombre, precio e imagen, pero en el precio vamos a indicar que sea -200 con el fin de que cuando compremos nos den saldo, este ataque es llamdo Mass-Asignment Attack.