Panoramica
Nell'agosto 2022, il team Vectra ha individuato un'opportunità di post-sfruttamento che consentiva agli attori malintenzionati con un accesso sufficiente al file system locale o remoto di rubare credenziali utente valide da Microsoft Teams a causa della loro memorizzazione in chiaro su disco. È stato stabilito che questa gestione delle credenziali in chiaro avrebbe avuto un impatto su tutti i client commerciali e GCC Desktop Teams per Windows, Mac e Linux.
Sebbene la raccolta delle credenziali dalla memoria sia una fase comune post-sfruttamento, riteniamo che abbassare la soglia necessaria per raccogliere le 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 dai fastidiosi ostacoli dell'autenticazione a più fattori (MFA).
Con questi token, gli aggressori possono assumere l'identità del titolare del token per qualsiasi azione possibile tramite il client Microsoft Teams, incluso l'utilizzo di tale token per accedere alle funzioni API di Microsoft Graph dal sistema dell'aggressore. Inoltre, questi token sono ugualmente validi con gli account abilitati per l'autenticazione a più fattori (MFA), consentendo di aggirare i controlli MFA durante l'uso continuativo.
Microsoft è a conoscenza del problema, ma ha dichiarato che non soddisfa i propri requisiti per un intervento immediato. Fino a quando Microsoft non provvederà ad aggiornare l'applicazione desktop Teams, riteniamo che i clienti debbano essere consapevoli dei rischi derivanti dall'archiviazione dei token in chiaro e mitigare tali rischi implementando strumenti di monitoraggio per rilevare accessi anomali ai file o modifiche alle ACL del file system.
La genesi della caccia
L'indagine è iniziata quando un cliente Vectra ha lamentato il modo in cui Microsoft Teams gestisce le identità disabilitate. Gli utenti finali non possono rimuovere gli account disattivati tramite l'interfaccia utente perché l'applicazione Teams richiede che l'account sia connesso per poterlo rimuovere dal client. Ovviamente, gli utenti non possono farlo quando il loro account utente è disabilitato. Per aiutare a risolvere questo problema, abbiamo iniziato a esaminare i dati di configurazione locali all'interno del client Teams e a svelarne il funzionamento.
Elettrone: un fattore negativo per la sicurezza
Microsoft Teams è un'app basata su Electron. Electron funziona creando un'applicazione web che viene eseguita tramite 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, stringhe di sessione e registri.
È qui che risiede la radice del problema, poiché Electron non supporta i controlli standard dei browser come la crittografia e le posizioni dei file protette dal sistema non sono supportate da Electron fin da subito, ma devono essere gestite in modo efficace per garantire la sicurezza. Pertanto, per impostazione predefinita, il funzionamento di Electron incentiva la creazione di applicazioni eccessivamente trasparenti. Poiché Electron nasconde le complessità della creazione dell'applicazione, è lecito supporre che alcuni sviluppatori possano non essere consapevoli delle ramificazioni delle loro decisioni di progettazione ed è comune sentire i ricercatori di sicurezza delle applicazioni lamentarsi dell'uso di questo framework a causa di gravi negligenze in materia di sicurezza.
Immergersi nella struttura
Abbiamo iniziato a esplorare metodi per cancellare ogni riferimento agli account registrati. Il nostro obiettivo era quello di rimuovere i vecchi account e costringere Teams a funzionare come se fossero stati eliminati. Diversi tentativi di modificare il file di configurazione e i file di prima esecuzione non hanno portato a nulla. Come tentativo alla cieca, abbiamo cercato il nome principale dell'utente conosciuto e sono stati restituiti due file critici.
Il primo file importante era un file ldb con token di accesso in testo chiaro. Dopo averlo esaminato, è stato stabilito che questi token di accesso erano attivi e non il risultato di un dump accidentale di un errore precedente. Questi token di accesso ci hanno consentito 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 dei cookie del browser simile ai "cookie" che accettiamo su ogni sito web (grazie, GDPR). I cookie memorizzano dati quali informazioni sulla sessione, tag di marketing, informazioni sull'account e, in alcuni casi, token di accesso. (S)fortunatamente, anche l'applicazione Teams Desktop memorizza i token in questo file.
Il modo migliore per leggere il Cookie DB è 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 valore del token.
Abbiamo valutato ogni token rispetto al servizio di convalida jwt di Microsoft, https://jwt.ms. Ogni token che abbiamo trovato era attivo e funzionava senza richiedere un'autenticazione aggiuntiva. Abbiamo iniziato a renderci conto che il problema iniziale di dover reinstallare Teams era molto meno grave rispetto al potenziale rischio di abuso dell'identità che incombeva sul client Microsoft Teams.
Facciamo qualcosa
Il team si è messo al lavoro con queste informazioni e ha iniziato a creare strumenti che sfruttassero queste credenziali non protette. Dopo aver valutato diverse opzioni, è stato deciso che l'invio di un messaggio all'account del titolare delle credenziali tramite Teams con un token di accesso sarebbe stata la soluzione più appropriata. Con questo obiettivo in mente, abbiamo avviato il client Teams nel browser per tracciare le chiamate API durante l'invio dei messaggi e abbiamo trovato questa chicca:
https://amer.ng.msg.teams.microsoft.com/v1/users/ME/conversations/48:notes/messages
Questo endpoint API ci endpoint inviare messaggi a noi stessi, senza dover perdere tempo con l'enumerazione degli account. Successivamente, avevamo bisogno del token di accesso. Abbiamo utilizzato il motore SQLite. SQLite non richiede installazione, quindi lo strumento scarica SQLite in una cartella locale e lo esegue per leggere il database dei cookie, da cui 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 passo era quello di mettere insieme un messaggio. Ci è voluto un po' di tempo per far funzionare il corpo della richiesta, ma alla fine ci siamo riusciti. Abbiamo impostato il messaggio da inviare con il flag di alta importanza e l'oggetto "You've Been PWND" (Sei stato PWND). Il messaggio stesso è il token di accesso Skype.
A questo punto lo strumento invia il messaggio e possiamo verificare che il token di accesso sia presente nella nostra chat personale.
Non male per una mattinata di lavoro.
Le implicazioni delle credenziali non protette
Microsoft memorizza queste credenziali per creare un'esperienza di accesso singolo senza soluzione di continuità all'interno dell'applicazione desktop. Tuttavia, l'implementazione di queste opzioni di sicurezza abbassa il livello di sicurezza.
Chiunque installi e utilizzi il client Microsoft Teams in questo stato memorizza le credenziali necessarie per eseguire qualsiasi azione possibile tramite l'interfaccia utente di Teams, anche quando Teams è chiuso. Quando questi token vengono rubati, gli aggressori possono modificare i file di SharePoint, la posta e i calendari di Outlook e i file di chat di Teams. Gli aggressori possono manomettere le comunicazioni legittime all'interno di un'organizzazione distruggendo, sottraendo o effettuando phishing mirati in modo selettivo.
The Big Scary – Il Phish definitivo
Ciò che ci spaventa davvero è la proliferazione dei token utente post-MFA in un ambiente: essa consente attacchi successivi che non richiedono autorizzazioni speciali aggiuntive o malware avanzato malware causare gravi danni interni. Con un numero sufficiente di macchine compromesse, gli aggressori possono orchestrare le comunicazioni all'interno di un'organizzazione. Assumendo il controllo totale di posizioni critiche, come Head of , l'amministratore delegato o il direttore finanziario di un'azienda, gli aggressori possono convincere gli utenti a eseguire attività dannose per l'organizzazione. Come si esegue il phishing test in questo caso?
Raccomandazioni
Agli amministratori
Team di base, gestione delle configurazioni e monitoraggio delle modifiche ACL
Trattate i team come un'applicazione critica e una base di riferimento e applicate gli ACL che li proteggono. La modifica di questi ACL per estendere l'accesso in lettura ai file al di fuori dell'utente previsto esporrà effettivamente le credenziali di tale utente a qualsiasi azione dannosa sopra descritta.
Una volta che Microsoft avrà aggiornato le applicazioni Electron Teams, sarà comunque fondamentale passare a un modello altamente restrittivo per impedire l'installazione di app, bot, connettori ecc. non autorizzati.
Traccia l'accesso ai file
Creare una regola di monitoraggio del sistema per identificare i processi che accedono a questi file sensibili. Ci sono due raccomandazioni specifiche relative a file/cartelle:
• [Windows] %AppData%\Microsoft\Teams\Cookies
• [Windows] %AppData%\Microsoft\Teams\Local Storage\leveldb
• [macOS] ~/Libreria/Supporto applicazioni/Microsoft/Teams/Cookies
• [macOS] ~/Libreria/Supporto applicazioni/Microsoft/Teams/Archiviazione locale/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, significa che i dati memorizzati vengono consultati al di fuori del contesto dell'applicazione Teams.
Considerare l'applicazione web come alternativa
Se la definizione di linee guida e il monitoraggio risultano impraticabili, prendete in considerazione l'utilizzo del client Teams basato sul web all'interno di Microsoft Edge, che dispone di diversi controlli a livello di sistema operativo per proteggere dalle fughe di token. Fortunatamente, l'applicazione web Teams è robusta e supporta la maggior parte delle funzionalità abilitate tramite il 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 supporto per Teams per Linux entro dicembre 2022.
Agli sviluppatori
Se devi utilizzare Electron per la tua applicazione, assicurati di archiviare in modo sicuro i token OAuth. Un metodo per archiviare i segreti consiste nell'utilizzare il 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 è necessario archiviare i token, farlo in modo crittografato e aumentare il livello di sicurezza passando da un semplice accesso in lettura al file system a un accesso continuo alla memoria. Inoltre, consentiteci di rimuovere gli account disabilitati dall'app Teams senza dover procedere alla disinstallazione/reinstallazione completa.
Ai team di sicurezza
Per fermare un aggressore che sfrutta questo tipo di exploit, i team dovrebbero investire in soluzioni di rilevamento delle minacce e di risposta in grado di individuare il tipo di azioni prima e dopo lo sfruttamento dell'exploit. La piattaforma di rilevamento e risposta alle minacce di Vectra rileverebbe le tattiche di comando e controllo dell' e che ci si aspetterebbe prima di questo exploit e qualsiasi ricognizione della 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, inclusi privilegi in Azure AD, attacchi su larga scala contro fornitori cloud connessi come AWS e attacchi contro altre applicazioni Microsoft 365, tra cui Exchange, SharePoint e Power Automate.
Rilevamento delle minacce e risposta per Azure AD
Per ulteriori informazioni su come Vectra è in grado di individuare e bloccare le minacce, visitare il sito: https://www.vectra.ai/products/platform