Minería de tokens contra Microsoft Teams
Connor Peoples, SSPM Architect de Vectra AI explica cómo el equipo de Vectra Protect descubrió agujeros de seguridad en la aplicación Microsoft Teams.
En agosto de 2022, el equipo de Vectra Protect identificó una oportunidad post-explotación que permite a los actores maliciosos con acceso (local o remoto) al sistema de archivos robar las credenciales de cualquier usuario de Microsoft Teams que haya iniciado sesión. Los ciberatacantes no requieren permisos elevados para leer estos archivos, lo que expone este problema a cualquier ataque que proporcione a los actores maliciosos acceso al sistema local o remoto. Además, se determinó que esta vulnerabilidad afecta a todos los clientes comerciales y GCC Desktop Teams para Windows, Mac y Linux.
Nuestra investigación descubrió que la aplicación Microsoft Teams almacena tokens de autenticación en texto claro ('cleartext'). Con estos tokens, los atacantes pueden asumir la identidad del titular del token para cualquier acción posible a través del cliente de Microsoft Teams, incluyendo el uso de ese token para acceder a las funciones de la API de Microsoft Graph desde el sistema de un atacante. Y lo que es peor, estos tokens robados permiten a los atacantes llevar a cabo acciones contra cuentas habilitadas para MFA, creando un bypass de MFA.
Microsoft es consciente de este problema y cerró el caso indicando que no cumplía con su baremo de servicio inmediato. Hasta que Microsoft actualice la aplicación de escritorio de Teams, creemos que los clientes deberían considerar el uso exclusivo de la aplicación de Teams basada en la web. Para los clientes que deban utilizar la aplicación de escritorio instalada, es fundamental vigilar los archivos clave de la aplicación para evitar el acceso por parte de cualquier proceso que no sea la aplicación oficial de Teams.
El origen de la investigación
La investigación se inició cuando un cliente de Vectra Protect se quejó de cómo Microsoft Teams gestiona las identidades desactivadas. Los usuarios finales no pueden eliminar las cuentas desactivadas a través de la interfaz de usuario porque la aplicación Teams requiere que la cuenta haya iniciado sesión para eliminarla del cliente. Por supuesto, los usuarios no pueden hacer esto cuando su cuenta de usuario está desactivada. Para ayudar a resolver este problema, comenzamos a examinar los datos de configuración local dentro del cliente de Teams y a desentrañar cómo funciona.
Electron - un problema de seguridad
Microsoft Teams es una aplicación basada en Electron. Electron funciona creando una aplicación web que se ejecuta a través de un navegador personalizado. Esto es muy conveniente y hace que el desarrollo sea rápido y fácil. Sin embargo, la ejecución de un navegador web en el contexto de una aplicación requiere datos tradicionales del navegador como cookies, cadenas de sesión y registros. Aquí es donde radican los problemas en torno a esta vulnerabilidad.
Los desarrolladores que no entienden completamente cómo funciona Electron pueden crear aplicaciones demasiado transparentes. Dado que Electron esconde las complejidades de la creación de la aplicación, es lícito pensar que los desarrolladores no son conscientes de las consecuencias de sus decisiones de diseño. Electron no es compatible con los controles estándar de los navegadores, como la encriptación, ni con las ubicaciones de los archivos protegidos por el sistema, que deben gestionarse de manera efectiva para seguir siendo seguras. A menudo se escucha a los investigadores de seguridad de aplicaciones quejarse del uso de este marco precisamente por los grandes fallos de seguridad.
Estudiando la estructura a fondo
Primero empezamos a explorar métodos para eliminar cualquier referencia a la(s) cuenta(s) conectada(s). Nuestro objetivo era eliminar las antiguas cuentas y obligar a Teams a funcionar como si no estuvieran. Los múltiples intentos de modificar el archivo de configuración y los archivos de primera ejecución no dieron resultado. Como intento, buscamos el nombre principal del usuario conocido y encontramos dos archivos críticos.
El primer archivo importante era un archivo ldb con tokens de acceso en texto claro. Tras la revisión, se determinó que estos tokens de acceso estaban activos y no eran un volcado accidental de un error anterior. Estos tokens de acceso nos daban acceso a las APIs de Outlook y Skype. Es importante saber que la arquitectura de Microsoft Teams es un conglomerado de una amplia variedad de servicios M365 que depende de Skype, SharePoint y Outlook para funcionar, lo que explica la presencia de estos tokens.
El siguiente archivo es una base de datos de cookies del navegador, como las "cookies" que aceptamos en todos los sitios web (gracias, GDPR). Las cookies almacenan datos como la información de la sesión, las etiquetas de marketing, la información de la cuenta y, en algunos casos, los tokens de acceso. (Des)Afortunadamente, la aplicación Teams Desktop también almacena los tokens aquí.
La mejor manera de leer la base de datos de cookies es utilizar un cliente de base de datos sqlite3. Con este cliente, podemos extraer sólo los valores que necesitamos. La siguiente consulta devuelve el nombre del token y el valor del mismo.
Evaluamos cada token contra el servicio de validación jwt de Microsoft, https://jwt.ms. Todos los tokens que encontramos estaban activos y funcionaban sin requerir autenticación adicional. Empezamos a darnos cuenta de que el problema inicial de tener que reinstalar los equipos era un problema mucho menor que el evidente abuso de identidad que se cernía sobre el cliente de Microsoft Teams.
Hagamos algo
El equipo se puso a trabajar con este conocimiento y comenzó a elaborar un exploit que se aprovechara de estas credenciales desprotegidas. Tras considerar múltiples opciones, se determinó que enviar un mensaje a la cuenta del titular de la credencial a través de Teams con un token de acceso sería lo adecuado. Con este objetivo en mente, lanzamos el cliente de Teams en el navegador para rastrear las llamadas a la API al enviar mensajes y encontramos esta joya:
https://amer.ng.msg.teams.microsoft.com/v1/users/ME/conversations/48:notes/messages
Este punto final de la API nos permite enviarnos mensajes a nosotros mismos, y no tenemos que hacer elucubraciones con la enumeración de cuentas. A continuación, necesitamos el token de acceso. Utilizamos el motor SQLite. SQLite no requiere instalación, así que el exploit descarga SQLite en una carpeta local y lo ejecuta para leer la base de datos de cookies, donde extraemos el token de acceso de Skype necesario para enviar mensajes.
Con el token en la mano y nuestro destino en mente, la última pieza era encadenar un mensaje. El cuerpo de la solicitud tardó un poco en funcionar, pero finalmente lo conseguimos. Configuramos el mensaje para enviarlo con la bandera de alta importancia establecida, y el asunto de "You’ve been PWND". El mensaje en sí es el token de acceso a Skype.
La herramienta envía el mensaje en este punto, y podemos validar que el token de acceso está en nuestro chat personal.
Las implicaciones de tener credenciales no protegidas
Microsoft almacena estas credenciales para crear una experiencia de inicio de sesión único sin problemas dentro de la aplicación de escritorio. Sin embargo, la implementación de controles de seguridad permite a los atacantes acceder a los tokens. La aplicación de escritorio crea oportunidades para que los atacantes utilicen las credenciales fuera de su contexto previsto porque, a diferencia de los navegadores modernos, no hay controles de seguridad adicionales para proteger los datos de las cookies.
Cualquiera que instale y utilice el cliente de Microsoft Teams en este estado está almacenando las credenciales necesarias para realizar cualquier acción posible a través de la interfaz de usuario de Teams, incluso cuando Teams está cerrado. Esto permite a los atacantes modificar los archivos de SharePoint, el correo y los calendarios de Outlook y los archivos de chat de Teams. Y lo que es aún más perjudicial, los atacantes pueden manipular las comunicaciones legítimas dentro de una organización destruyendo, exfiltrando o realizando ataques de phishing selectivos. En este momento no hay límite a la capacidad de un atacante para moverse por el entorno de su empresa.
El gran temor es la suplantación de identidad definitiva
Esto es lo que realmente nos asusta de este ataque. Este ataque no requiere de permisos especiales o de malware avanzado para salirse con la suya y causar grandes daños internos. Con suficientes máquinas comprometidas, los atacantes pueden orquestar las comunicaciones dentro de una organización. Asumiendo el control total de los puestos críticos -como el Director General o el Director Financiero de una empresa- los atacantes pueden convencer a los usuarios de que realicen tareas perjudiciales para la organización. ¿Cómo se hace una prueba antiphishing para ataques de este tipo?
Recomendaciones a los administradores
Migrar a la aplicación web
No recomendamos utilizar el cliente completo de Microsoft Teams hasta que Microsoft parchee este problema de forma efectiva. Utilice el cliente de Teams basado en la web dentro de Microsoft Edge, que tiene múltiples controles a nivel de sistema operativo para proteger las fugas de tokens. Afortunadamente, la aplicación web de Teams es robusta y admite la mayoría de las características habilitadas a través del cliente de escritorio, manteniendo los impactos de productividad de la organización al mínimo.
Una vez que Microsoft haya actualizado las aplicaciones de Electron Teams, sigue siendo fundamental pasar a un modelo de alta restricción para evitar la instalación de Apps de Teams, bots, conectores, etc. no autorizados.
Para los usuarios de Linux, este es el camino recomendado sin más, ya que Microsoft ha anunciado el fin de la vida de Teams para Linux en diciembre de 2022.
Seguimiento del acceso a los archivos
Cree una regla de supervisión del sistema para identificar los procesos que acceden a estos archivos sensibles. Hay dos recomendaciones específicas de archivos/carpetas:
• [Windows] %AppData%\Microsoft\Teams\Cookies
• [Windows] %AppData%\Microsoft\Teams\Local Storage\leveldb
• [macOS] ~/Library/Application Support/Microsoft/Teams/Cookies
• [macOS] ~/Library/Application Support/Microsoft/Teams/Local Storage/leveldb
• [Linux] ~/.config/Microsoft/Microsoft Teams/Cookies
• [Linux] ~/.config/Microsoft/Microsoft Teams/Local Storage/leveldb
Si cualquier proceso que no sea Teams.exe accede a estos archivos, indica que se está accediendo a los datos almacenados fuera del contexto de la aplicación Teams.
Recomendaciones a los desarrolladores
Si debe usar Electron para su aplicación, asegúrese de almacenar de forma segura los tokens OAuth. Un método para almacenar secretos es utilizar el paquete KeyTar, que aprovecha los mecanismos de seguridad del sistema operativo local para la gestión de secretos.
Recomendaciones A Microsoft
Si debe almacenar los tokens, hágalo de forma encriptada. Esto aumenta significativamente el esfuerzo requerido para causar daño a los tokens al forzar a un atacante a comprometer la pila de memoria que alberga el proceso de ejecución de los equipos. Lo ideal sería aprovechar protecciones similares a las que ofrecen los navegadores de escritorio modernos, que cifran el contenido de las cookies con herramientas nativas del sistema operativo.
Y permítanos eliminar las cuentas deshabilitadas de la(s) aplicación(es) de Teams sin tener que hacer una desinstalación/reinstalación completa.
Recomendaciones a los equipos de seguridad
Para detener a un atacante que aproveche este tipo de exploits, los equipos deben invertir en soluciones de detección de amenazas y respuesta que puedan ver los tipos de acciones antes y después de que se aproveche el exploit. La plataforma de detección y respuesta a las amenazas de Vectra detectaría las tácticas de mando y control que se esperarían antes de este exploit y cualquier reconocimiento de la red, movimiento lateral o exfiltración que se produciría después del exploit. En la nube, Vectra alertaría sobre las actividades del atacante utilizando las credenciales comprometidas en Azure AD, incluyendo los privilegios en Azure AD, los ataques a gran escala contra los proveedores de servicios en la nube conectados como AWS, y los ataques contra otras aplicaciones de Microsoft 365, incluyendo Exchange, SharePoint y Power Automate.
Connor Peoples, SSPM Architect de Vectra AI
