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 atacantes 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.
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.
¿Cómo
almacenar de forma segura información sensible en Electron con node-keytar | por Cameron Nokes | Cameron Nokes | Medium
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.
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.
Detección y respuesta a las amenazas para Azure AD
Para más información sobre cómo Vectra puede ver y detener las amenazas, visite:
https://www.vectra.ai/attack-surface/azure-ad