Ad agosto il team di Vectra Protect ha identificato un percorso di attacco che consente ad attaccanti con accesso ai file system di rubare le credenziali di qualsiasi utente di Microsoft Teams che abbia effettuato l’accesso. Gli aggressori non necessitano di autorizzazioni elevate per leggere questi file, il che espone tale problematica a qualsiasi attacco che fornisca ai cybercriminali l’accesso al sistema locale o remoto. Inoltre, è stato provato che questa vulnerabilità ha impatto su tutti i client Desktop Teams commerciali e GCC per Windows, Mac e Linux.
La ricerca ha scoperto che l’applicazione Microsoft Teams memorizza i token di autenticazione in chiaro. Con questi token, gli aggressori possono assumere l’identità del titolare del token per qualsiasi azione possibile attraverso il client Microsoft Teams, compreso l’utilizzo del token per accedere alle funzioni API di Microsoft Graph dal sistema di un aggressore. Ancora peggio, questi token rubati consentono agli aggressori di eseguire azioni contro gli account abilitati all’MFA, creando un bypass dell’MFA stesso.
Microsoft è a conoscenza di questo problema e ha chiuso il caso dichiarando che non soddisfaceva i requisiti per un’assistenza immediata. In attesa che Microsoft aggiorni l’applicazione desktop di Teams, riteniamo che i clienti dovrebbero utilizzare esclusivamente l’applicazione web-based di Teams. Per coloro che hanno necessità di utilizzare l’applicazione desktop installata, è fondamentale controllare che i file chiave non siano accessibili da processi diversi dall’applicazione Teams ufficiale.
L’origine dell’indagine
L’indagine ha preso avvio dalla segnalazione di un cliente di Vectra Protect, che si è lamentato del modo in cui Microsoft Teams gestisce le identità disattivate. Gli utenti non possono rimuovere gli account disattivati attraverso l’interfaccia utente perché l’applicazione Teams richiede che l’account sia firmato per poterlo rimuovere dal client. Naturalmente, gli utenti non possono farlo quando il loro account utente è disattivato. Per risolvere questo problema, abbiamo iniziato a esaminare i dati di configurazione locale all’interno del client Teams e a svelarne il funzionamento.
Electron – un problema di sicurezza
Microsoft Teams è un’applicazione basata su Electron. Electron funziona creando un’applicazione web che viene eseguita attraverso un browser personalizzato. Ciò è molto comodo e rende lo sviluppo facile e veloce. Tuttavia, l’esecuzione di un browser web nel contesto di un’applicazione richiede dati tradizionali del browser come cookie, session string e log. È qui che risiedono i problemi legati a questa vulnerabilità.
Gli sviluppatori che non comprendono appieno il funzionamento di Electron possono creare applicazioni troppo trasparenti. Poiché Electron nasconde le complessità della creazione dell’applicazione, è lecito supporre che gli sviluppatori non siano consapevoli delle conseguenze delle proprie decisioni di progettazione. Electron non supporta i controlli standard del browser, come la crittografia, e le file location protette dal sistema, che devono essere gestite in modo efficace per rimanere sicure. Capita spesso di sentire ricercatori che si occupano di sicurezza delle applicazioni lamentarsi dell’uso di questo framework proprio a causa di importanti errori in materia di sicurezza.
Approfondiamo la struttura
Per prima cosa abbiamo iniziato a esplorare i metodi per eliminare qualsiasi riferimento agli account collegati. Il nostro obiettivo era rimuovere i vecchi account e costringere Microsoft Teams a operare come se non ci fossero più. I molteplici tentativi di modificare il file di configurazione e i file di prima esecuzione non hanno portato a nulla. Come tentativo, gli esperti di Vectra Protect hanno cercato il nome principale dell’utente noto e hanno trovato due file critici.
Il primo file era un file ldb con token di accesso in chiaro. Dopo un’analisi, è stato accertato che questi token di accesso erano attivi e non un dump accidentale di un errore precedente. Questi token di accesso hanno permesso a Vectra di accedere alle API di Outlook e Skype. È importante sapere che l’architettura di Microsoft Teams è un insieme di un’ampia varietà di servizi M365 che si basa su Skype, SharePoint e Outlook per funzionare: ciò spiega la presenza di questi token.
Il file successivo è un database di cookie del browser, come i “cookie” che accettiamo su ogni sito web (grazie, GDPR). I cookie memorizzano dati come informazioni sulla sessione, tag di marketing, informazioni sull’account e, in alcuni casi, token di accesso. (S)fortunatamente, anche l’applicazione Teams Desktop memorizza qui i token.
Il modo migliore per leggere il DB dei Cookie è utilizzare un sqlite3 database client. Con questo client, possiamo estrarre solo i valori di cui abbiamo bisogno. La seguente query restituisce il nome del token e il suo valore.
È stato valutato ogni token con il servizio di validazione Microsoft jwt, https://jwt.ms. Ogni token trovato era attivo e funzionava senza richiedere un’ulteriore autenticazione. Si è quindi capito che il problema iniziale legato alla necessità di dover reinstallare Teams era nulla in confronto all’evidente abuso di identità potenzialmente presente nel client di Microsoft Teams.
Cosa fare per porre rimedio alla vulnerabilità?
Grazie alle conoscenze acquisite, il team si è messo al lavoro e ha iniziato a creare un exploit che sfruttasse queste credenziali non protette. Dopo aver considerato diverse opzioni, si è capito che l’invio di un messaggio su Teams all’account del titolare delle credenziali con un token di accesso sarebbe stato appropriato. Con questo obiettivo in mente, Vectra ha lanciato il client di Microsoft Teams nel browser per tracciare le chiamate API durante l’invio dei messaggi ed è stata trovata questa perla:
https://amer.ng.msg.teams.microsoft.com/v1/users/ME/conversations/48:notes/messages
Questo endpoint API consente di inviare messaggi a noi stessi, senza dover smanettare con innumerevoli account. Poi ci serve il token di accesso. È stato usato il motore SQLite che non richiede installazione: l’exploit scarica SQLite in una cartella locale e lo esegue per leggere il DB Cookies, da cui estraiamo il token di accesso Skype necessario per l’invio dei messaggi.
In possesso del token e avendo ben chiaro l’obiettivo finale, l’ultimo passaggio consisteva nel mettere insieme un messaggio. Ciò ha richiesto un po’ di tempo per funzionare, ma alla fine è stato possibile: gli esperti hanno impostato il messaggio da inviare selezionando il flag “priorità alta” e inserendo come oggetto “You’ve Been PWND”, ovvero “il tuo account è stato compromesso”. Il messaggio stesso è il token di accesso Skype.
A questo punto lo strumento invia il messaggio e si può convalidare che il token di accesso si trova nella nostra chat personale.
Le implicazioni di avere credenziali non protette
Microsoft memorizza queste credenziali per creare un’esperienza di single sign-on senza soluzione di continuità all’interno dell’applicazione desktop. Tuttavia, l’implementazione dei controlli di sicurezza consente agli aggressori di accedere ai token. L’applicazione desktop offre agli aggressori l’opportunità di utilizzare le credenziali al di fuori del contesto previsto, poiché, a differenza dei browser moderni, non esistono controlli di sicurezza aggiuntivi per proteggere i dati dei cookie.
Chiunque installi e utilizzi il client Microsoft Teams in questo stato memorizza le credenziali necessarie per eseguire qualsiasi azione possibile attraverso l’interfaccia utente di Teams, anche quando Teams è spento. Ciò consente agli aggressori di modificare i file di SharePoint, la posta e i calendari di Outlook e i file delle chat di Teams. Ancora più dannoso è il fatto che gli aggressori possano manomettere le comunicazioni legittime all’interno di un’organizzazione, distruggendo, esfiltrando o effettuando attacchi di phishing mirati. A questo punto non c’è limite alla capacità di un aggressore di muoversi nell’ambiente aziendale.
La grande paura è il phishing definitivo
Ciò che preoccupa veramente di questo attacco è che non richiede autorizzazioni speciali o malware avanzati per riuscire a produrre gravi danni interni. Con un numero sufficiente di macchine compromesse, gli aggressori possono orchestrare le comunicazioni all’interno di un’organizzazione e, assumendo il pieno controllo di posti critici, come il CEO o il CFO di un’azienda, possono convincere gli utenti a eseguire operazioni dannose per l’organizzazione. Come si mette in atto un test anti-phishing per attacchi di questo tipo?
Raccomandazioni agli amministratori
- Migrare all’applicazione Web. Non si consiglia di utilizzare il client completo di Microsoft Teams fino a quando Microsoft non risolverà efficacemente il problema. Utilizzate il client Teams web-based all’interno di Microsoft Edge, che dispone di diversi controlli a livello di sistema operativo per proteggere il furto di token. Fortunatamente, l’applicazione web di Teams è robusta e supporta la maggior parte delle funzioni abilitate dal client desktop, riducendo al minimo l’impatto sulla produttività dell’organizzazione. Una volta che Microsoft ha aggiornato le applicazioni Electron Teams, è ancora fondamentale passare a un modello ad alta restrizione per prevenire l’installazione di app Teams non autorizzate, bot, connettori, ecc. Per gli utenti Linux, il percorso consigliato si ferma qui, dal momento che Microsoft ha annunciato che Teams per Linux non esisterà più dopo dicembre 2022.
- Tracciare l’accesso ai file. Creare una regola di monitoraggio del sistema per identificare i processi che accedono ai file sensibili. Ci sono due raccomandazioni specifiche per file/cartelle:
- [Windows] %AppData%\Microsoft\Teams\Cookies
- [Windows] %AppData%\Microsoft\Teams\Local Storage\leveldb
- [macOS] ~/Libreria/Application Support/Microsoft/Teams/Cookies
- ~/Libreria/Application Support/Microsoft/Teams/Local Storage/leveldb
- [Linux] ~/.config/Microsoft/Microsoft Teams/Cookies
- [Linux] ~/.config/Microsoft/Microsoft Teams/Local Storage/leveldb
Se un processo diverso da Teams.exe accede a questi file, ciò indica che si sta accedendo ai dati memorizzati al di fuori del contesto dell’applicazione Teams.
Raccomandazioni agli sviluppatori
Se si deve usare Electron per l’applicazione, è importante assicurarsi di memorizzare in modo sicuro i token OAuth. Un metodo per farlo è l’uso del pacchetto KeyTar, che sfrutta i meccanismi di sicurezza del sistema operativo locale.
Raccomandazioni a Microsoft
Se si devono memorizzare i token, bisogna farlo in modo criptato. Questo aumenta significativamente lo sforzo necessario per danneggiare i token, costringendo un aggressore a compromettere lo stack di memoria che ospita il processo in esecuzione di Teams. L’ideale sarebbe sfruttare protezioni simili a quelle fornite dai moderni browser desktop, che criptano il contenuto dei cookie con strumenti nativi del sistema operativo.
E permetteteci di rimuovere gli account disabilitati dalle app di Teams senza dover effettuare una disinstallazione/reinstallazione completa.
Raccomandazioni ai team di sicurezza
Per fermare un attaccante che sfrutta questo tipo di exploit, i team dovrebbero investire in soluzioni di threat detection and response in grado di rilevare queste tipologie di azioni prima e dopo l’exploit.
di Connor Peoples, SSPM Architect di Vectra AI
