Risultati principali
- L'attacco Application Consent, noto anche come attacco Illicit Consent Grant, è un tipo di attacco di phishing in cui un attore malintenzionato ottiene l'accesso a un'applicazione e poi sfrutta le autorizzazioni concesse a tale applicazione.
- Il ricercatore di Semperis Adi Malyanker ha scoperto che, in determinate circostanze, un soggetto malintenzionato potrebbe utilizzare l'autorizzazione Directory.ReadWrite.All o l'autorizzazione DelegatedPermissionGrant.ReadWrite.All all'interno di Microsoft Azure per scalare i privilegi, accedere a risorse e dati sensibili, sferrare un attacco Denial of Service (DoS) o addirittura assumere il controllo di un tenant Entra ID.
- Qualsiasi organizzazione che utilizzi applicazioni in Entra ID potrebbe essere vulnerabile a questo attacco, denominato attacco Hidden Consent Grant.
- Per quanto ne sa Semperis, non è stato documentato alcun attacco di questo tipo.
- I ricercatori di Semperis classificano questa vulnerabilità come potenzialmente GRAVE a causa della possibilità di acquisizione di un tenant Entra ID.
In Microsoft Azure, l'autorizzazione Directory.ReadWrite.All ha implicazioni significative. Questa autorizzazione consente una moltitudine di azioni, tra cui la modifica da parte dell'utente e l'accesso a tutti i dati della directory.
Sembra rischioso? Alcuni sostengono che se utilizzata isolatamente, l'autorizzazione non presenta rischi intrinseci. Tuttavia, le mie ricerche indicano che un utente malintenzionato potrebbe utilizzare l'autorizzazione Directory.ReadWrite.All (o DelegatedPermissionGrant.ReadWrite.All ) per causare gravi danni in un ambiente Microsoft Entra ID (precedentemente noto come Azure AD) o ibrido Microsoft Active Directory/Entra ID.
Cosa sono le autorizzazioni per le applicazioni?
In Entra ID, le autorizzazioni per le applicazioni consentono a un'applicazione specifica di eseguire determinate azioni o di accedere a determinate risorse all'interno di Entra ID o di altri servizi Microsoft. A differenza delle autorizzazioni delegate, che gli utenti concedono alle applicazioni autorizzate, le autorizzazioni delle applicazioni sono generalmente concesse da un amministratore durante il processo di registrazione dell'applicazione.
L'applicazione utilizza quindi queste autorizzazioni per eseguire attività per conto dell'organizzazione o dei suoi utenti, senza richiedere il consenso individuale o continuo dell'utente(Figura 1).
Le autorizzazioni per le applicazioni sono spesso utilizzate quando l'applicazione deve accedere a risorse o eseguire azioni che non dipendono dall'identità o dalle autorizzazioni di un utente specifico. Esempi di autorizzazioni per le applicazioni sono:
- Lettura dei profili utente
- Gestione dei gruppi
- Accesso ai dati organizzativi
È essenziale gestire e assegnare con cura i permessi delle applicazioni. Le organizzazioni devono garantire che le applicazioni abbiano il livello di accesso appropriato, mantenendo al contempo gli standard di sicurezza e conformità all'interno dell'ambiente Entra ID.
Che cos'è Directory.ReadWrite.All?
Durante la ricerca dei permessi delle applicazioni, ho incontrato il permesso Directory.ReadWrite.All. Secondo la documentazione di Microsoft:
"Directory.ReadWrite.All garantisce un accesso sostanzialmente equivalente a quello di un amministratore globale di un tenant. Le applicazioni a cui è stato concesso Directory.ReadWrite.All possono gestire l'intera gamma di risorse della directory e possono gestire l'autorizzazione per altre applicazioni e utenti ad accedere alle risorse in tutta l'organizzazione. Questo include risorse di directory come utenti, gruppi, applicazioni e dispositivi, e risorse non di directory in Exchange, SharePoint, Teams e altri servizi".
Dato il nome di questa autorizzazione, l'associazione con Entra ID e l'implicazione nella gestione delle directory, ho sospettato che fosse potenzialmente pericolosa.
Ma all'inizio, dopo aver esaminato le azioni che Directory.ReadWrite.All consente, non sono riuscito a trovare alcuna minaccia degna di nota. Altri sembrano aver tratto una conclusione simile. Ad esempio, in un eccellente articolo pubblicato da SpectreOps si afferma che questa autorizzazione, sebbene potente se combinata con altre autorizzazioni, difficilmente può rappresentare un rischio significativo da sola.
Tuttavia, ho deciso di dare un'occhiata più da vicino.
Ho iniziato a testare ciò che l'autorizzazione Directory.ReadWrite.All può fare ad alto livello. Cosa potrebbe fare un malintenzionato usando solo questa autorizzazione per le applicazioni?
La buona notizia è che non sono riuscito a usare l'autorizzazione per fare quanto segue:
- Aggiungere segreti alle applicazioni
- Aggiungi proprietari
- Aggiungere membri o proprietari con un ruolo a un gruppo di sicurezza
- Assegnare un ruolo all'applicazione
- Reimpostare la password di un utente
Queste chiamate API hanno restituito una risposta come quella mostrata nella Figura 2.
Tuttavia, sono riuscito a utilizzare Directory.ReadWrite.All per fare quanto segue:
- Aggiungere un nuovo membro o proprietario senza alcun ruolo assegnato a un gruppo di sicurezza
- Aggiungere utenti alla directory
- Modifica dei consensi dell'amministratore
- Modifiche limitate alle unità amministrative
Nota: oltre 400 chiamate API sono dedicate a Teams, dispositivi e OneDrive. Queste chiamate non rientrano nell'ambito di questa ricerca.
Azioni come l'aggiunta di nuovi utenti e membri, che non hanno un ruolo assegnato, ai gruppi potrebbero essere molto utili agli aggressori che cercano di ottenere l'accesso iniziale a una directory o alle risorse. Questa possibilità è abbastanza preoccupante, ma mi chiedevo se fosse possibile fare di più.
Posso usare l'autorizzazione Directory.ReadWrite.All per trasformarmi in un amministratore globale?
Directory.ReadWrite.All può essere un potenziale vettore di attacco?
Prima di passare alle cose divertenti, una nota: il token di accesso che vi aiuta ad accedere ad Azure contiene un campo speciale chiamato scope, o scp. Questo campo annota le autorizzazioni concesse all'utente(Figura 3).
Ho controllato questo valore durante la mia ricerca per determinare se i miei tentativi di elevare i permessi erano andati a buon fine.
Per verificare i miei sospetti su Directory.ReadWrite.All, ho scelto un'API di Microsoft Graph, oauth2PermissionGrant, che può creare una concessione di permessi delegati su una risorsa per un'entità scelta(Figura 4).
Per effettuare questa chiamata API, è necessario concedere a un'applicazione il permesso Directory.ReadWrite.All(Figura 5). Ho scelto postman-test(Figura 6).
Ho anche creato un account utente debole, Evil User(Figura 7), per rappresentare un aggressore (che simula un utente malintenzionato membro del tenant e un utente legittimo ottenuto da un aggressore). Non ho assegnato a questo utente alcun ruolo o permesso(Figura 8).
Per invocare le chiamate API, ho collegato il principio del servizio postman-test con Postman. Esaminiamo le proprietà e i requisiti dell'API(Figura 9):
- clientId identifica l'applicazione (in questo caso, Graph Explorer) che è autorizzata ad agire per conto di un utente che ha effettuato l'accesso. Il valore clientId sostituisce l'identità dell'utente.
- consentType indica se l'applicazione client è autorizzata a impersonare tutti gli utenti o solo un utente specifico.
- resourceId specifica la risorsa (in questo caso, Microsoft Graph) a cui il clientId può accedere con le autorizzazioni concesse.
- definisce le azioni specifiche (ad esempio, device.Read.All, Director.ReadWrite.All) che il clientId può eseguire sul resourceId.
Per riassumere le relazioni tra queste proprietà: Uno o più utenti concedono al clientId un insieme approvato di permessi, come definito dall'ambito. Il clientId può quindi utilizzare tali permessi per accedere alla risorsaId specificata.
Torniamo ora all'esplorazione delle chiamate API. Innanzitutto, mi serve l'ID dell'oggetto Graph Explorer. Per ottenere questo ID posso navigare nel portale delle applicazioni di Azure o utilizzare l'API Graph(Figura 10).
Per iniziare, ho usato Graph Explorer come clientId e resourceId.
Come Evil User, ho provato a leggere tutti i gruppi della directory. Come si può vedere dalla risposta 403 nella Figura 11, questa azione non è stata consentita a causa dei privilegi insufficienti.
Poi ho provato ad aggiungere un'autorizzazione delegata - GroupMember.Read.All - aGraph Explorer per l'intera directory(Figura 12). Se ci sono riuscito, ogni utente della directory (compreso l'utente malvagio) dovrebbe ottenere questa autorizzazione.
Ho verificato che l'aggiunta di questa autorizzazione sia avvenuta con successo. Si noti che nell'applicazione Graph Explorer l'autorizzazione è stata concessa per l'intera directory(Figura 13).
Ora dovrei essere in grado di utilizzare la chiamata API per ottenere tutti i gruppi(Figura 14).
Strano... Graph Explorer aveva l'autorizzazione GroupMember.Read.All con il consenso dell'amministratore, ma sto ancora ricevendo una risposta 403. Perché?
Ricordate la definizione di permessi delegati? Poiché Graph Explorer utilizzava i permessi dell'utente registrato, poteva leggere i membri solo se l'utente registrato aveva il ruolo o il livello di privilegio corretto per utilizzare quel permesso, cosa che Evil User non aveva. Il mio tentativo era un vicolo cieco.
Ma aspettate. Conoscete l'attacco della Sovvenzione per consenso illecito?
Che cos'è l'attacco di una Sovvenzione per consenso illecito?
In parole povere, un attacco di tipo Illicit Consent Grant, noto anche come attacco di tipo Application Consent, si verifica quando qualcuno viene ingannato nel concedere a un'applicazione di terze parti (cioè esterna) diritti eccessivi sui propri dati o sulla configurazione delle proprie applicazioni Office 365. La Figura 15 illustra il funzionamento di questo attacco.
In breve, un utente malintenzionato crea un'applicazione registrata su Azure. Poi:
- L'applicazione richiede l'accesso a dati sensibili come informazioni di contatto, e-mail o documenti.
- L'utente finale concede il consenso all'applicazione. Il consenso può essere ottenuto attraverso attacchi di phishing o iniettando codice illecito in un sito web affidabile.
- L'app dell'aggressore riceve l'approvazione del consenso e un token di accesso.
- L'app dannosa e l'aggressore hanno ora accesso ai dati dell'utente a livello di account.
Cosa succederebbe se un aggressore lanciasse un attacco di tipo Illicit Consent Grant, utilizzando un'applicazione dannosa a cui è stato concesso il permesso Directory.ReadWrite.All? Era giunto il momento di ritentare l'esperimento.
Incontro con l'attacco di Hidden Consent Grant
Questa volta ho agito come un aggressore che cercava di compromettere un utente della directory di destinazione attraverso un'applicazione con il permesso Directory.ReadWrite.All. L'applicazione iniziava con privilegi bassi e poi aumentava i suoi permessi dopo aver ottenuto il consenso dell'amministratore(Figura 16).
Questo flusso di attacco sarebbe possibile utilizzando una sola app, ma ho deciso di utilizzarne due per aumentare la furtività (separando l'app con i permessi Directory.ReadWrite.All dall'app di cui verranno aggiornati i permessi). Per questo esperimento:
- Ho creato un account per un utente con privilegi limitati: Harmless Attacker (harmless_attacker). Questo esperimento presuppone che un attaccante abbia già ottenuto l'accesso a questo account attraverso un precedente phishing, un altro attacco o l'appartenenza al tenant.
- Ho creato un account utente privilegiato, Privileged User (privileged_user), per rappresentare un amministratore globale.
- Ho usato Harmless Attacker per creare un'applicazione con i permessi Directory.ReadWrite.All (in questo caso, postman-test, che ho usato per concedere permessi delegati a 365stealer).
- Ho usato Harmless Attacker per creare un'altra applicazione, chiamata 365stealer. Questa app ha le impostazioni mostrate nella Figura 17. Si noti che l'URI di reindirizzamento dell'applicazione porta a un endpoint controllato dall'aggressore.
Harmless Attacker non è riuscito ad aggiungere permessi privilegiati all'app 365stealer durante la creazione, per cui all'inizio i permessi dell'app apparivano come quelli mostrati nella Figura 18.
Successivamente, ho utilizzato un endpoint controllato dall'aggressore per configurare un server HTTPS, in ascolto sulla porta 443(Figura 19).
Poi ho usato Harmless Attacker per costruire una pagina di phishing (Figura 20). In uno scenario reale, Harmless Attacker cercherebbe di ingannare l'utente privilegiato facendolo accedere a questa pagina tramite un'e-mail o un file dannoso.
La pagina di phishing conteneva un collegamento ipertestuale a una pagina di login Microsoft reindirizzata, in cui l'utente privilegiato veniva incoraggiato ad accedere all'app dannosa(365stealer). In base alla parte redirect_uri, i token saranno inviati al server HTTPS distribuito dall'aggressore(Figura 21).
Dopo aver effettuato con successo il login, all'utente verrà presentata una sfida di consenso(Figura 22).
Nulla di questi permessi o della richiesta di consenso sembra dannoso (non sono richiesti permessi sensibili), quindi l'utente accetterà il consenso. Nel nostro caso, gli verrà presentata una pagina come quella mostrata nella Figura 23, chiuderà il browser e continuerà la sua giornata.
Nota: anche se la pagina è contrassegnata come insicura, esistono modi per aggirarla. Tuttavia, ciò esula dallo scopo di questo articolo. È anche possibile vedere la nota non verificata nel consenso. Più avanti nell'articolo affronterò i modi per nasconderla.
Nel frattempo, all'insaputa dell'utente, l'aggressore riceve il token di accesso e lo utilizza per chiamare l'API /me(Figura 24).
Questo token di accesso contiene le autorizzazioni che l'utente ha accettato nella richiesta di consenso. Un'occhiata al campo scp del token lo conferma(Figura 25).
Quindi, ora l'attaccante ha un token di accesso (e un token di aggiornamento) di un utente privilegiato. Ma questo token può essere utilizzato solo con l'app e i permessi delegati elencati nell'ambito. All'attaccante manca ancora il permesso RoleManagement.ReadWrite.Directory, quindi qualsiasi tentativo di chiamare l'API directoryRoles (attraverso una richiesta a https://graph.microsoft.com/v1.0/directoryRoles) restituirà una risposta Access Denied(Figura 26).
Anche in questo caso, sembra che il potenziale dell'attaccante per causare danni sia molto limitato. Come potrebbe un aggressore aumentare i privilegi e chiamare altre API interessanti?
È qui che entra in gioco Directory.ReadWrite.All.
Potrei prendere l'API oauth2PermissionGrant del mio esperimento originale, che richiede solo l'autorizzazione Directory.ReadWrite.All, e usarla per concedere l'autorizzazione delegata RoleManagement.ReadWrite.Directory all'applicazione 365stealer ?
Per scoprirlo, uso prima l'API oauth2PermissionGrant per enumerare il clientId e il resourceId usati per 365stealer(Figura 27).
Successivamente, ho impostato il tipo di consenso su "AllPrincipals"(Figura 28). In questo modo si elimina il requisito del consenso dell'amministratore per la concessione dei permessi.
Aspettate un attimo. L'autorizzazione RoleManagement.ReadWrite.Directory è stata concessa, ma non è presente nell'elenco delle autorizzazioni configurate(Figura 29).
Aha! Harmless Attacker possiede l'app 365stealer . È sufficiente fare clic con il pulsante destro del mouse su RoleManagement.ReadWrite.Directory e selezionare Aggiungi alle autorizzazioni configurate (Figura 30). Anche senza questo passaggio, l'autorizzazione dovrebbe essere disponibile per me.
L'autorizzazione è ora configurata(Figura 31).
A questo punto, è sufficiente chiamare l'endpoint /refresh nel server HTTP per aggiornare il token di accesso dell'account utente privilegiato e le sue autorizzazioni(Figura 32).
Un'occhiata all'ambito del token verifica l'aggiunta dell'autorizzazione RoleManagement.ReadWrite.Directory(Figura 33).
Con questa autorizzazione nel token di accesso, ora posso chiamare GET https://graph.microsoft.com/v1.0/directoryRoles(Figura 34).
Ora posso chiamare POST https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments per assegnare all'Attaccante innocuo il ruolo di Amministratore globale(Figura 35).
Fatto! Un'occhiata alle assegnazioni attive dell'account dell'attaccante verifica l'escalation dei privilegi(Figura 36). Il mio tentativo di lanciare quello che ho chiamato Hidden Consent Grant ha avuto successo.
Concessione di consenso nascosta: Ora con un'aggiunta di furtività!
Ricordate la sfida di consenso che veniva presentata all'utente nelle prime fasi dell'attacco Hidden Consent Grant? Mi sono chiesto se fosse possibile nascondere quella sfida per rendere l'attacco ancora più furtivo. In questo modo si creerebbe un flusso di attacco simile, senza richiedere un'azione da parte dell'utente sotto forma di superamento di una sfida di consenso da parte della vittima, anche quando l'applicazione richiede permessi elevati(Figura 37).
Ho iniziato con le stesse autorizzazioni utilizzate nell'esperimento precedente. Tuttavia, ho concesso all'app 365stealer il consenso amministrativo(Figura 38). Ricordate che Directory.ReadWrite.All consente all'aggressore di farlo senza alcuna interazione con l'utente.
Ora dobbiamo eseguire il flusso di phishing e determinare se all'utente privilegiato viene presentata una richiesta di consenso quando fa clic sul link nella pagina di phishing. (Attenzione: non è così).
A questo punto, ho dimostrato due punti:
- Alla vittima del phishing non verrà presentata alcuna richiesta di consenso se i privilegi richiesti sono già stati approvati dall'amministratore.
- Anche dopo che l'amministratore ha approvato la richiesta di consenso per l'aggiunta dei permessi dell'app, l'aggressore può aggiungere altri permessi modificando manualmente le autorizzazioni, senza che la vittima lo sappia.
Diffusione del consenso nascosto Sovvenzione
Mi sono chiesto se potevo trasformare tutte le app della directory in link di phishing. Sapevo di poter trasformare ogni app che possedevamo in un'app di phishing modificando il suo URL di reindirizzamento. Ma che dire delle app che non soddisfano questo requisito?
Nel raro caso in cui un'applicazione abbia anche l'autorizzazione Application.ReadWrite.All, l'aggressore può modificare o aggiungere all'applicazione un altro URL di reindirizzamento - il server di ascolto dell'aggressore. In questo modo, ogni app presente nella directory viene trasformata in un'entità dannosa(Figura 39).
La chiamata all'API Graph mostrata nella Figura 40 può aiutare a modificare l'URI di reindirizzamento dell'applicazione(Figura 41).
Per questo vettore di attacco, l'attaccante deve ancora conoscere il segreto dell'applicazione. Fortunatamente per l'attaccante, Application.ReadWrite.All consente di aggiungere un nuovo segreto all'applicazione(Figura 42).
Nota: sembra esserci una discrepanza tra la documentazione di Microsoft e le mie osservazioni. In base ai miei test, sebbene sia menzionato Directory.ReadWrite.All, potrebbero essere necessarie altre autorizzazioni.
Per questa prova di concetto, Semperis ha costruito e pubblicato un nuovo strumento, HiddenConsentGrant, disponibile qui. Questo strumento può essere utilizzato per creare un server in ascolto, in attesa delle risposte dei token di accesso.
Rilevamento e mitigazione
Come si può individuare un attacco di Hidden Consent Grant?
- Gli utenti di Semperis Directory Services Protector ( DSP) o Purple Knight potranno utilizzare l'indicatore di sicurezza Entra tenant is susceptible to Hidden Consent Grant Attack per verificare e segnalare la possibilità di un attacco hidden consent grant al tenant.
- Cercate i presidi di servizio sospetti con privilegi elevati, ad esempio Gestione dei ruoli.ReadWrite.Directory, Application.ReadWrite.All, e AppRoleAssignment.ReadWrite.All. È possibile utilizzare la seguente chiamata API per enumerare questi permessi (Figura 43):
GET graph.microsoft.com/v1.0/oauth2PermissionGrants?$filter=consentType eq %27AllPrincipals%27
Figura 43. Enumerazione dei privilegi - Determinare se un amministratore ha concesso l'approvazione alle autorizzazioni.
- Verificare che le autorizzazioni siano utilizzate attivamente e richieste.
- Eliminare i privilegi non necessari.
- Nei registri di audit, cercare l'opzione Aggiungere la concessione di un'autorizzazione delegata con l'attore avviato Applicazione (Figura 44).
Figura 44. Esame della voce di registro Aggiungi concessione di autorizzazione delegata Il Tipo dovrebbe essere Applicazione e il Tipo di attività dovrebbe essere Aggiungere la concessione di un'autorizzazione delegata. È possibile utilizzare Graph API per ottenere tutti i registri di audit che hanno il Tipo di attività Aggiungere la concessione di un'autorizzazione delegata:
https://graph.microsoft.com/v1.0/auditLogs/directoryAudits?$filter=activityDisplayName eq 'Add delegated permission grant'È possibile cercare "user": null, il che significa che un'applicazione ha invocato la concessione dell'autorizzazione delegata (Figura 45).
Figura 45. Ricerca delle autorizzazioni delegate invocate dall'applicazione - Monitorare e revocare qualsiasi autorizzazione OAuth consenso. La seguente chiamata API può essere d'aiuto:
GET https://graph.microsoft.com/v1.0/oauth2PermissionGrants/
Questa chiamata restituisce tutti i permessi delegati concessi nel tenant, il tipo di consenso e l'entità (Figura 46).
Figura 46. Individuazione di concessioni di consenso OAuth non autorizzate - Infine, evitate di assegnare alle applicazioni i permessi Directory.ReadWrite.All o DelegatedPermissionGrant.ReadWrite.All come autorizzazioni per le applicazioni. (L'autorizzazione DelegatedPermissionGrant.ReadWrite.All consente a un utente malintenzionato di sferrare gli stessi attacchi descritti in questo articolo). Se possibile, configurate permessi più specifici per le vostre applicazioni.
Fare luce sulle sovvenzioni per il consenso nascosto
Questo articolo illustra il proof of concept di diversi flussi di attacco che abusano del ruolo Directory.ReadWrite.All per ottenere potenzialmente tutti i permessi che un attaccante potrebbe desiderare. Questi flussi di attacco potrebbero essere letali nelle mani di un attaccante esperto. Rivedete e rafforzate subito le autorizzazioni delle vostre applicazioni e chiudete questa potenziale apertura prima che gli attori delle minacce possano approfittarne.
