Cómo las credenciales compartidas abren la puerta a los ataques
Contenido
Introducción
Ya sea a través de un portal de inicio de sesión en un banco, software de código abierto, o incluso el propio sistema operativo, la dependencia moderna de la tecnología ha hecho que tanto los profesionales de la tecnología como el público en general se topen con el código de otras personas. La necesidad de consistencia y practicidad nos ha traído cosas como bibliotecas de códigos, ya que escribir cada pieza de código desde cero no es escalable.
Cuanto más complejos sean los entornos, más importante es encontrar lugares donde pueda automatizar y reutilizar las herramientas que ya tiene disponibles.
Sin embargo, el uso de código de estas bibliotecas preestablecidas por un desarrollador como base para su propio código crea "problemas de confianza"; es decir, requiere un nivel de confianza que un profesional de seguridad podría considerar arriesgado. Cuanto más profundamente se esconda una vulnerabilidad en el código fuente, más difícil es encontrarla, y eso suponiendo que sabes buscar esa aguja digital en el pajar.
Encontramos un ejemplo de estos problemas de confianza en nuestro propio proceso de desarrollo. Un uso aparentemente rutinario de uno de nuestros servicios externos nos llevó al descubrimiento de varias oportunidades de ataque graves. Después de comunicar la información al proveedor, se abordaron los problemas identificados. En esta entrada de blog compartimos lo que encontramos, detallamos cómo lo encontramos y debatimos las maneras en que los atacantes pueden usarlo potencialmente en su beneficio.
Echemos un vistazo
Durante una prueba de optimización rutinaria, uno de nuestros ingenieros de DevOps creó un nuevo contenedor para una herramienta de pruebas de terceros. Ejecutó el comando, que es muy conocido: apt get update && apt get install XXXX -y.
Después de introducir el comando, queríamos ver qué se estaba ejecutando en nuestro terminal durante el proceso de creación. Para ello, ejecutamos el comando de proceso de lista simple ps en nuestro terminal y nos encontramos con esta interesantísima línea:
Pudimos usar las credenciales identificadas para autenticarnos en un sitio que contenía cientos de compilaciones de clientes.
El hecho de que hubiera una clave de texto claro era alarmante, pero podría explicarse/contenerse mediante un control de usuario adecuado; por ejemplo, si el token era por uso de la aplicación. Claramente, este no era el caso aquí. El nombre de usuario proporcionado contenía la cadena "default" (predeterminado), y esto nunca es una buena señal.
Decidimos profundizar un poco más e intentamos usar las credenciales para autenticarnos en la API, lo que nos permitió consultar información potencialmente sensible. Y mucha. Resultó que el usuario "predeterminado" era de hecho muy predeterminado: el usuario no estaba dedicado para el uso de Akamai, sino que toda la base de clientes de la aplicación lo utilizaba.
Armado con este secreto de texto sin formato, cualquier atacante podría usarlo para recuperar datos sensibles, como resultados de ejecución de pruebas internas, grabaciones de vídeo, capturas de pantalla y flujos de ejecución de scripts internos, para la mayoría de los clientes de la aplicación (Figura 1).
Fig. 1: Example of improperly accessed sensitive customer data
La extraordinaria cantidad de datos que se expusieron y el hecho de que la vulnerabilidad estaba visible a plena vista nos hicieron querer mirar más a fondo su base de código y ver qué más se podía encontrar.
No se debería compartir todo
Después de identificar un secreto compartido que la aplicación estaba utilizando de forma muy indebida, decidimos intentar identificar otros secretos de este tipo. Después de unas cuantas búsquedas bien establecidas (y muchísimos adornos) dentro del código fuente de las aplicaciones, encontramos tres secretos adicionales:
- Una clave privada Coralogix
- Una clave de API de Google
- Un token ngrok
Examinemos cada uno de estos secretos y su potencial para el abuso.
Coralogix: una clave privada (muy pública)
Uno de los secretos que identificamos en la base de código de nuestras aplicaciones fue una clave privada, que despertó nuestro interés, por lo que buscamos cualquier nombre de usuario que pudiera estar vinculado a esta clave privada. Conseguimos encontrar un nombre de usuario unas líneas más abajo de la tecla como parte de una función de registro. Utilizamos otras pistas que se dejaron atrás y descubrimos que la clave privada pertenece al marco de registro de Coralogix.
Las credenciales estaban codificadas, lo que significa que diferentes clientes también las estaban compartiendo. Esto podría significar otra posible fuga de datos, pero afortunadamente este usuario/atacante tenía pocos privilegios y solo se le permitía escribir mensajes de registro en el marco.
Aunque no es tan fuerte como la primitiva anterior, una primitiva de escritura todavía puede permitir algunos vectores interesantes en el propio vendedor: un atacante puede insertar mensajes de registro falsificados en el entorno del proveedor o intentar inyectar registros maliciosos para realizar ataques, como los de scripts entre sitios (XSS) o inyección de lenguaje de consulta estructurado (SQL).
Clave de API de Google
OAuth es un mecanismo de autorización que todas las operaciones de Google utilizan. Las aplicaciones y los sitios pueden dar a los usuarios la posibilidad de iniciar sesión en sus aplicaciones o sitios con su cuenta de Google facilitada por OAuth. Para habilitar esta opción a través del código, los desarrolladores necesitan varios parámetros que pueden obtener de su cuenta de Google, a saber, su clave de API: su google_name y su google_secret.
Al navegar por el código, encontramos una referencia a la API de Google. Por lo general, en los casos en que vemos una clave de "google api", solo vemos eso, pero esta vez no. Esta vez también encontramos la clave "google api", el identificador único de google_client y (¡lo más desconcertante!) el identificador de google_secret identifier. Con los tres, los atacantes pueden solicitar un enlace de autenticación de Google como proveedor. Este enlace se puede utilizar como parte de una campaña de phishing para engañar a las víctimas y que otorguen a los atacantes permiso para acceder a su cuenta de Workspace.
Explotación de phishing potencial
Los atacantes pueden crear un correo electrónico de phishing que contiene un enlace a un sitio que es idéntico al sitio del proveedor con un cambio crucial: el enlace para iniciar sesión con Google es el enlace que el atacante obtuvo utilizando los detalles de la API de Google del proveedor (Figura 2).
Fig. 2: Malicious Google login page appears to be legitimate
Al iniciar sesión, la víctima otorga al atacante permiso para acceder a toda su cuenta de Google Workspace.. Con acceso a algo tan sensible como una identidad de Google, las posibilidades de un atacante son vastas. Una explotación correcta permitiría a un atacante manipular cualquier aspecto de la cuenta de Google Workspace de la víctima, incluidas la vulneración del correo electrónico, la descarga de archivos y mucho más. Esto podría ser muy útil como parte de un ataque de ingeniería social contra las organizaciones.
ngrok
La estrategia de los túneles de red es una solución casi universal para la transferencia segura de datos, que puede proporcionar a un atacante el cofre del tesoro lleno de oportunidades maliciosas si se ve vulnerado. Descubrimos muchos parámetros relacionados con los túneles en la instalación de la aplicación vulnerada, incluida una configuración ngrok , lo que nos llevó a investigar más a fondo. Las mismas características que fomentan una mejor colaboración entre los desarrolladores son precisamente las que hacen que sean atractivas para un atacante.
Ngrok es un servicio que se especializa en proporcionar una plataforma para los túneles de información a través de servidores. Ngrok hace que sea muy simple exponer los servicios a Internet, lo que permite una depuración más rápida y bucles de retroalimentación de desarrollo más eficientes. Desafortunadamente, si un atacante ha tomado el control del túnel, esa simplicidad también está disponible para ellos.
Al invocar un simple comando ps, un atacante puede ver el ID único y el token de autenticación de la empresa. Este ID único no se puede cambiar; seguirá siendo el mismo en otros usos de la aplicación en otros terminales. Los atacantes pueden utilizar esos parámetros para enviar el ID y el token al servidor online de un proveedor para recibir los detalles del servicio ngrok de la empresa (Figura 3).
Fig. 3: Ngrok token received from the vendor’s server
Eso significa que después del acceso inicial Los atacantes pueden copiar el ID único y el token de la víctima, y usarlos para leer los datos que se envían o se reciben de la aplicación de la víctima (Figura 4).
Fig. 4: Example of data being read from ngrok tunnel
Conclusión
Las amenazas no son exclusivamente externas; de hecho, aceptamos voluntariamente algunas amenazas internamente. Muchas personas piensan que el software de código abierto representa el mayor peligro debido a la confianza que le damos, pero las herramientas de terceros pueden plantear un mayor desafío para las empresas en comparación con el código abierto.
Después de nuestros descubrimientos, revelamos los problemas que se han resaltado en este blog al proveedor afectado y se solucionaron. A pesar de eso, los nuevos defectos de seguridad siempre están a la vuelta de la esquina.
Creemos que en este caso (y en muchos otros), la supervisión de la seguridad es tan importante como formar a los desarrolladores para que tengan una mentalidad basada en la seguridad. Estas dos cosas pueden ayudar a garantizar que los servicios gestionados no causen ningún problema a las empresas.