In questo articolo Indice dei contenuti 3 sezioni
Una vulnerabilità individuata in Microsoft Authenticator per Android consentiva a un’applicazione qualunque, priva di permessi speciali, di presentarsi come Teams e farsi consegnare token validi per accedere a posta, file, calendari e altre risorse dell’utente. Microsoft ha corretto la falla nelle scorse settimane e indica come vulnerabili le versioni dalla 6.0.0 fino a quelle precedenti alla 6.2606.4246. A scoprire il problema sono stati i ricercatori di Enclave, che hanno chiamato l’attacco AuthMask.
Per capire la portata della questione bisogna ricordare che nelle configurazioni aziendali Authenticator non si limita a generare codici temporanei o ad approvare richieste MFA. Fa da broker di autenticazione per le app che si appoggiano a Microsoft Identity Platform, centralizza l’accesso agli account e rende possibile il Single Sign On (SSO) tra Teams e gli altri client Microsoft. MSAL, la Microsoft Authentication Library, può infatti delegare la richiesta dei token a un broker installato sul dispositivo, ruolo che possono ricoprire anche Intune Company Portal e Collegamento a Windows. L’utente entra una volta sola e da lì in poi è il broker a gestire le richieste delle app autorizzate, con il supporto a funzioni come Conditional Access, registrazione del dispositivo e gestione centralizzata degli account.
Il controllo sulla firma che guardava nel posto sbagliato
Tutto questo regge solo se il broker sa con certezza quale applicazione gli sta chiedendo un token. Il punto di ingresso studiato da Enclave è AccountChooserActivity, una Activity eseguita nel processo :auth di Authenticator e marcata nel manifest con android:exported=”true”. Tradotto in parole semplici, altre app presenti sul telefono potevano avviarla senza problemi.
Authenticator effettuava una verifica che a prima vista sembra corretta. Ricostruiva il redirect URI legato al pacchetto dichiarato usando la firma dell’app installata e lo confrontava con quello inserito nella richiesta. Il guaio è che controllava la coerenza tra due dati riferiti al pacchetto che il richiedente diceva di rappresentare, senza mai accertare che quel pacchetto fosse davvero l’app che aveva aperto l’Activity. Un’app malevola poteva quindi individuare Teams tramite PackageManager, recuperarne le informazioni pubblicamente accessibili e costruire il redirect URI giusto. Nel loro proof of concept i ricercatori hanno dichiarato il package com.microsoft.teams insieme al client ID di Teams e all’UID dell’app installata. Nessun bisogno di manomettere Teams o di violare la sandbox di Android, l’app ostile restava separata e senza alcun permesso dichiarato.
Da Microsoft 365 fino alle passkey
Qui non si parla di una password rubata ma di credenziali già pronte per interrogare le API autorizzate, visto che un token OAuth valido permette di operare con i privilegi dell’utente senza ripetere autenticazione e MFA a ogni chiamata. Fingendosi Teams e interrogando Microsoft Graph con lo scope .default, Enclave ha ottenuto autorizzazioni come Mail.ReadWrite, Mail.Send, Files.ReadWrite.All, Calendars.ReadWrite, ChatMessage.Send e Sites.ReadWrite.All. In base ai permessi concessi all’account, un’app di terze parti avrebbe potuto leggere e modificare messaggi, spedire posta, mettere mano ai file, alterare i calendari e interagire con i contenuti di Microsoft 365.
I ricercatori hanno poi provato a impersonare anche altri client Microsoft registrati nei servizi di autenticazione. Usando l’identità del componente che gestisce le funzioni di chat di Teams hanno ricevuto un token con scope user_impersonation, utile ad agire verso quel servizio per conto dell’utente entro i limiti previsti dall’applicazione. Il test più delicato però ha riguardato lo stesso Authenticator. Facendo passare l’app malevola per il broker, Enclave ha ottenuto token con permessi come UserAuthenticationMethod.ReadWrite, Passkey.Create e Passkey.Delete, cioè autorizzazioni che toccano direttamente i metodi con cui l’account dimostra la propria identità, passkey comprese.
Un attacco locale che richiede un’app sul telefono
Perché AuthMask funzioni serve che il codice malevolo arrivi in qualche modo sul dispositivo Android dove è installato Authenticator con un account aziendale configurato. Microsoft classifica l’attacco come locale, a bassa complessità e senza privilegi iniziali. Non basta visitare un sito Web per finire nel mirino, il pericolo diventa concreto quando un telefono aziendale permette l’installazione di software non fidato, di APK scaricati fuori dallo store o di app dall’aspetto innocuo che nascondono codice ostile.
Chi utilizza Microsoft Authenticator dovrebbe controllare di avere la versione 6.2606.4246 o una successiva, meglio ancora lasciando attivi gli aggiornamenti automatici tramite Google Play o il sistema di distribuzione aziendale.
Fonte: TecnoAndroid