Panoramica
Nell'agosto del 2022, il team di Vectra ha identificato un'opportunità di post-exploitation che permetteva ad attori malintenzionati con un accesso sufficiente al file system locale o remoto di rubare credenziali utente valide da Microsoft Teams grazie alla loro memorizzazione in chiaro su disco. È stato determinato che questa gestione delle credenziali in chiaro ha un impatto su tutti i client Desktop Teams commerciali e GCC per Windows, Mac e Linux.
Sebbene l'estrazione delle credenziali dalla memoria sia una fase comune di post-exploitation, riteniamo che abbassare la soglia necessaria per l'estrazione delle credenziali fino al semplice accesso in lettura al file system ampli le opportunità per un avversario, semplifichi il suo compito e sia particolarmente interessante quando le credenziali rubate offrono l'opportunità di mantenere l'accesso dell'utente senza essere ostacolati da un'autenticazione a più fattori (MFA) altrimenti fastidiosa.
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. Inoltre, questi token sono ugualmente validi con gli account abilitati alla MFA, consentendo di aggirare i controlli MFA durante l'utilizzo continuo.
Microsoft è a conoscenza di questo problema, ma ha indicato che non soddisfa i requisiti per un'assistenza immediata. Fino a quando Microsoft non aggiornerà l'applicazione Teams Desktop, riteniamo che i clienti debbano essere consapevoli dei rischi posti dall'archiviazione di token in chiaro e mitigarli monitorando con strumenti gli accessi insoliti ai file o le modifiche alle ACL del file system.
La genesi della caccia
L'indagine è stata avviata quando un cliente di Vectra si è lamentato del modo in cui Microsoft Teams gestisce le identità disattivate. Gli utenti finali non possono rimuovere gli account disattivati attraverso l'interfaccia utente, perché l'applicazione Teams richiede che l'account sia stato registrato 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.
L'elettrone - un negativo per la sicurezza
Microsoft Teams è un'applicazione basata su Electron. Electron funziona creando un'applicazione web che viene eseguita attraverso un browser personalizzato. Questo è 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, stringhe di sessione e registri.
È qui che risiede la radice del problema, poiché Electron non supporta i controlli standard del browser, come la crittografia, e le posizioni dei file protette dal sistema non sono supportate da Electron, ma devono essere gestite in modo efficace per rimanere sicure. Pertanto, per impostazione predefinita, il funzionamento di Electron incentiva la creazione di applicazioni eccessivamente trasparenti. Poiché Electron offusca le complessità della creazione dell'applicazione, è lecito supporre che alcuni sviluppatori non siano consapevoli delle ramificazioni delle loro decisioni di progettazione ed è comune sentire ricercatori sulla sicurezza delle applicazioni lamentarsi dell'uso di questo framework a causa di sviste critiche sulla sicurezza.
Immersione nella struttura
Per prima cosa abbiamo iniziato a esplorare metodi per eliminare qualsiasi riferimento agli account collegati. Il nostro obiettivo era rimuovere i vecchi account e costringere Teams a operare come se non ci fossero. I molteplici tentativi di modificare il file di configurazione e i file di prima esecuzione non hanno portato a nulla. Come tentativo nel buio, abbiamo cercato il nome principale dell'utente noto e abbiamo trovato due file critici.
Il primo file importante era un file ldb con token di accesso in chiaro. Dopo un'analisi, è stato determinato che questi token di accesso erano attivi e non un dump accidentale di un errore precedente. Questi token di accesso ci hanno permesso di accedere alle API di Outlook e Skype. È importante sapere che l'architettura di Microsoft Teams è un conglomerato di un'ampia varietà di servizi M365 che si basa su Skype, SharePoint e Outlook per funzionare: questo 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. (Per fortuna, anche l'applicazione Teams Desktop memorizza qui i token.

Il modo migliore per leggere il DB dei cookie è utilizzare un client di database sqlite3. Con questo client, possiamo estrarre solo i valori di cui abbiamo bisogno. La seguente query restituisce il nome del token e il suo valore.

Abbiamo valutato ogni token rispetto al servizio di validazione jwt di Microsoft, https://jwt.ms. Ogni token trovato era attivo e funzionava senza richiedere un'ulteriore autenticazione. Ci siamo resi conto che il problema iniziale di dover reinstallare Team era molto più piccolo dell'opportunità di abuso dell'identità potenzialmente presente nel client di Microsoft Teams.
Facciamo qualcosa
Il team si è messo al lavoro con queste conoscenze e ha iniziato a creare strumenti che sfruttassero queste credenziali non protette. Dopo aver considerato diverse opzioni, è stato stabilito che l'invio di un messaggio all'account del titolare della credenziale attraverso Teams con un token di accesso sarebbe stato appropriato. Con questo obiettivo in mente, abbiamo lanciato il client di Teams nel browser per tracciare le chiamate API durante l'invio dei messaggi e abbiamo trovato questo gioiello:
https://amer.ng.msg.teams.microsoft.com/v1/users/ME/conversations/48:notes/messages
Questo endpoint dell'API ci consente di inviare messaggi a noi stessi e di non dover smanettare con l'enumerazione degli account. Poi, ci serve il token di accesso. Abbiamo usato il motore SQLite. SQLite non richiede installazione, quindi il tooling scarica SQLite in una cartella locale e lo esegue per leggere il DB Cookies, dove estraiamo il token di accesso Skype necessario per l'invio dei messaggi.
Con il token in mano e la nostra destinazione in mente, l'ultimo pezzo era mettere insieme un messaggio. Il corpo della richiesta ha richiesto un po' di tempo per funzionare, ma alla fine ci siamo riusciti. Abbiamo impostato il messaggio da inviare con il flag di importanza elevata e l'oggetto "You've Been PWND". Il messaggio stesso è il token di accesso Skype.

A questo punto lo strumento invia il messaggio e possiamo convalidare che il token di accesso si trovi nella nostra chat personale.

Non male per una mattinata di lavoro.
Le implicazioni delle credenziali non garantite
Microsoft memorizza queste credenziali per creare un'esperienza di single sign-on senza soluzione di continuità all'interno dell'applicazione desktop. Tuttavia, l'implementazione di queste scelte di sicurezza abbassa l'asticella.
Chiunque installi e utilizzi il client Microsoft Teams in questo stato memorizza le credenziali necessarie per eseguire qualsiasi azione attraverso l'interfaccia utente di Teams, anche quando Teams è spento. Il furto di questi token consente agli aggressori di modificare i file di SharePoint, la posta e i calendari di Outlook e i file delle chat di Teams. Gli aggressori possono manomettere le comunicazioni legittime all'interno di un'organizzazione distruggendo selettivamente, esfiltrare o intraprendere attacchi phishing mirati.
Il grande spavento - L'ultimo Phish
In questo caso, ciò che ci spaventa veramente è la proliferazione dei token utente post-MFA in tutto l'ambiente, che consente agli attacchi successivi che non richiedono ulteriori autorizzazioni speciali o malware avanzato di farla franca con danni interni importanti. Con un numero sufficiente di macchine compromesse, gli aggressori possono orchestrare le comunicazioni all'interno di un'organizzazione. Assumendo il pieno controllo di postazioni critiche, come quelle del responsabile tecnico, del CEO o del CFO di un'azienda, gli aggressori possono convincere gli utenti a eseguire operazioni dannose per l'organizzazione. Come si fa a praticare il phish test per questo?
Raccomandazioni
Agli amministratori
Team di base, gestione delle configurazioni e monitoraggio delle modifiche ACL
Trattate i team come un'applicazione critica e applicate le ACL che la proteggono. La modifica di queste ACL per estendere l'accesso ai file di lettura al di fuori dell'utente previsto esporrà di fatto le credenziali di tale utente a qualsiasi azione dannosa sottolineata in precedenza.
Una volta che Microsoft ha aggiornato le applicazioni Electron Teams, è ancora fondamentale passare a un modello ad alta restrizione per impedire l'installazione di app Teams non autorizzate, bot, connettori, ecc.
Tracciare l'accesso ai file
Creare una regola di monitoraggio del sistema per identificare i processi che accedono a questi file sensibili. Esistono due raccomandazioni specifiche per i file/cartelle:
- [Windows] %AppData%\Microsoft\Teams\Cookies
- [Windows] %AppData%\Microsoft\Teams\Magazzino locale\leveldb
- [macOS] ~/Libreria/Application Support/Microsoft/Teams/Cookies
- [macOS] ~/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, indica che si sta accedendo ai dati memorizzati al di fuori del contesto dell'applicazione Teams.

Considerate l'applicazione web come un'alternativa
Se il baselining e il monitoraggio non sono praticabili, si può prendere in considerazione l'utilizzo del client Teams basato sul web all'interno di Microsoft Edge, che dispone di molteplici controlli a livello di sistema operativo per proteggere le fughe 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.
Per gli utenti Linux, questo è il percorso consigliato, poiché Microsoft ha annunciato la fine del ciclo di vita di Teams per Linux entro dicembre 2022.
Agli sviluppatori
Se dovete usare Electron per la vostra applicazione, assicuratevi di memorizzare in modo sicuro i token OAuth. Un metodo per memorizzare i segreti è l'uso del pacchetto KeyTar, che sfrutta i meccanismi di sicurezza del sistema operativo locale per la gestione dei segreti.
Come archiviare in modo sicuro le informazioni sensibili in Electron con node-keytar | di Cameron Nokes | Cameron Nokes | Medium
A Microsoft
Se dovete memorizzare i token, fatelo in modo criptato e alzate la soglia da un semplice accesso in lettura al file system a un accesso continuo alla memoria. E permetteteci di rimuovere gli account disabilitati dalle app Teams senza dover effettuare una disinstallazione/reinstallazione completa.
Ai team di sicurezza
Per fermare un attaccante che sfrutta questo tipo di exploit, i team dovrebbero investire in soluzioni di rilevamento delle minacce e di risposta in grado di individuare i tipi di azioni prima e dopo l'exploit. La piattaforma di rilevamento e risposta alle minacce di Vectra è in grado di rilevare le tattiche di comando e controllo di che sarebbero previste prima di questo exploit e qualsiasi ricognizione di rete, movimento laterale o esfiltrazione che si verificherebbe dopo l'exploit. Nel cloud, Vectra segnalerebbe le attività dell'aggressore che utilizza le credenziali compromesse in Azure AD, compresi gli attacchi privilegiati in Azure AD, gli attacchi su larga scala contro i provider di servizi cloud connessi come AWS e gli attacchi contro altre applicazioni Microsoft 365, tra cui Exchange, SharePoint e Power Automate.
Rilevamento e risposta alle minacce per Azure AD
Per saperne di più su come Vectra è in grado di vedere e bloccare le minacce, visitate il sito: https://www.vectra.ai/products/platform.