Non autorizzato: Elevazione dei privilegi attraverso le applicazioni Microsoft

Questo articolo illustra una serie di scoperte del team di ricerca sulla sicurezza di Semperis che hanno portato alla possibilità di eseguire azioni in Entra ID al di là dei controlli di autorizzazione previsti, sulla base dell'analisi dell'ambito (permessi) di OAuth 2.0. La scoperta più preoccupante riguardava la possibilità di aggiungere e rimuovere utenti da ruoli privilegiati, compreso il ruolo più potente di Entra ID: Amministratore globale. Abbiamo segnalato le nostre scoperte al Microsoft Security Response Center (MSRC) e abbiamo collaborato con Microsoft per garantire che queste scoperte siano state risolte.

Sebbene non sia noto se alcune organizzazioni siano state compromesse in precedenza attraverso questa scoperta, un attore delle minacce potrebbe aver utilizzato tale accesso per eseguire l'elevazione dei privilegi ad amministratore globale e installare ulteriori mezzi di persistenza in un tenant. Un utente malintenzionato potrebbe anche utilizzare questo accesso per eseguire un movimento laterale in qualsiasi sistema di Microsoft 365 o Azure, nonché in qualsiasi applicazione SaaS collegata a Entra ID.

Il rilevamento richiede che l'iniziatore detenga il ruolo di Application Administrator o Cloud Application Administrator in Entra ID, che è considerato privilegiato. In molte aziende, purtroppo, gli utenti a cui vengono assegnati questi ruoli non vengono trattati come privilegiati, il che li rende bersagli privilegiati di un aggressore.

Le organizzazioni interessate dovrebbero capire come rilevare se le loro applicazioni Microsoft potrebbero essere state prese di mira, come documentato più avanti in questo articolo.

Primer sull'integrazione delle applicazioni

Per comprendere questo vettore di attacco, è necessario capire i componenti fondamentali coinvolti.

I clienti di Microsoft 365 e Azure potrebbero conoscere i sistemi e i servizi con cui interagiscono, tra cui Microsoft Teams, SharePoint Online, Exchange Online, Azure Key Vault, i portali di amministrazione come il portale Azure e Microsoft 365 Admin Center e la suite di altri servizi Microsoft. Ciò di cui potreste non essere a conoscenza sono le centinaia di applicazioni Microsoft che mantengono in funzione la vostra proprietà Microsoft. Al di fuori di Microsoft, queste applicazioni possono essere definite applicazioni di prima parte perché non sono fornite da un ISV di terze parti.

Entra ID è la piattaforma di identità e il motore di autorizzazione di ogni ambiente Microsoft 365 e Azure. I clienti che federano l'autenticazione a Okta, Ping Identity o altri fornitori di identità con i servizi Microsoft devono comunque gestire il modello di autorizzazione esistente all'interno della loro proprietà Microsoft. Entra ID è il meccanismo di autorizzazione di base che consente a queste applicazioni Microsoft di interagire e operare tra loro, utilizzando gli standard di settore per l'autenticazione e l'autorizzazione moderne: OpenID Connect e OAuth 2.0.

Ogni cliente Microsoft ha un proprio tenant Entra (precedentemente noto come Azure AD). In ogni tenant, ogni applicazione Microsoft è rappresentata da un oggetto principale di sicurezza noto come service principal. Gli utenti e i gruppi sono i presidi di sicurezza con cui abbiamo maggiore familiarità; è possibile assegnare ruoli e autorizzazioni a questi presidi. Proprio come gli utenti e i gruppi, i ruoli e le autorizzazioni possono essere assegnati alle applicazioni tramite i loro service principal. Questi ruoli e permessi vengono valutati quando si interagisce con Entra ID o con altri servizi Microsoft 365.

Applicazioni multitenant in Entra ID

Entra ID considera in genere tutte le applicazioni Microsoft, anche quelle che hanno proprietà uniche, come applicazioni multitenant.

Con le applicazioni multitenant, lo sviluppatore definisce il funzionamento dell'applicazione nella registrazione dell'applicazione. Ciò include azioni quali la definizione delle autorizzazioni API di Microsoft Graph di cui l'applicazione ha bisogno, nonché la credenziale utilizzata dall'applicazione per accedere a Microsoft Graph. Microsoft Graph è l'endpoint API unificato per diversi servizi Microsoft, tra cui Entra ID.

Quando un'organizzazione consuma un'applicazione multitenant, l'applicazione è rappresentata nel tenant che la consuma da un service principal(Figura 1).

Il caso di credenziali multiple

Entra ID consente di assegnare e utilizzare due tipi di credenziali per l'autenticazione: segreti (password) e chiavi (certificati). Entrambi i tipi di credenziali funzionano nel contesto della nostra scoperta. In futuro, mi riferirò collettivamente sia ai segreti che alle chiavi semplicemente come credenziali.

Il punto interessante è che Entra ID consente la memorizzazione delle credenziali in due luoghi: nella registrazione dell'applicazione (che, come detto, viene gestita dallo sviluppatore) e nel service principal. Nel caso di applicazioni multitenant, il service principal si trova nel tenant del cliente ed è sotto il controllo del cliente, che può quindi assegnare le credenziali al service principal(Figura 2).

Per proteggere dall'assegnazione o dall'uso di segreti sui service principal, gli sviluppatori di applicazioni possono utilizzare un meccanismo di Entra ID chiamato blocco delle proprietà dell'istanza dell'applicazione. Dalle nostre ricerche e discussioni con Microsoft, quest'ultima sfrutta un meccanismo diverso che può fornire lo stesso risultato finale: non consentire l'autenticazione tramite credenziali su un service principal.

Sia che una credenziale sia assegnata alla registrazione di un'applicazione o a un service principal, entrambe possono essere utilizzate per eseguire un flusso di concessione di credenziali client OAuth 2.0 per agire come tale applicazione in Microsoft Graph(Figura 3).

Durante il flusso di concessione delle credenziali del client, si verificano le seguenti fasi:

1. L'applicazione utilizza il proprio ID cliente e la credenziale per autenticarsi a Entra ID. Un'applicazione è di fatto qualsiasi cosa che conosca l'ID del client, l'ID del tenant e la credenziale. Pertanto, ai fini di questo abuso, sebbene l'applicazione denominata possa essere un'applicazione Microsoft, l'applicazione che agisce è l'aggressore.
2. Entra ID convalida l'ID e la credenziale del cliente e risponde con un token di accesso.
3. L'applicazione richiede i dati da Microsoft Graph, passando il token.
4. Microsoft Graph convalida il token di accesso.
5. Se il token è valido, Microsoft Graph fornisce i dati o l'azione richiesti.

I dettagli completi su questo flusso sono disponibili nella documentazione Microsoft "Microsoft identity platform and the OAuth 2.0 client credentials flow".

Poiché Microsoft Graph è un'API REST, è possibile utilizzare azioni come GET per richiedere dati da Entra ID e azioni come POST e PATCH per creare o modificare dati in Entra ID.

Se a un'applicazione è assegnata l'autorizzazione Gruppo.Crea e si dispone della credenziale per quell'applicazione, è possibile creare un gruppo e i registri di verifica di Entra ID mostreranno che il gruppo è stato creato dal service principal per quell'applicazione.

A titolo di esempio, si supponga di avere un'applicazione di terze parti denominata Custom Application, utilizzata per accedere a Microsoft Graph tramite il Microsoft Graph PowerShell SDK. Le credenziali passate come $creds contengono l'ID dell'applicazione e la credenziale(Figura 4).

Se si eseguono azioni utilizzando le autorizzazioni consentite per questa applicazione, in questo caso Group.Create, taliazioni vengono visualizzate nei registri di verifica di Entra ID come eseguite dall'applicazione. Come si può vedere nella Figura 5, l'applicazione è il principale di sicurezza responsabile dell'operazione "Aggiungi gruppo".

Funzionano come applicazioni Microsoft

In Entra ID, Microsoft ha storicamente consentito ai clienti di assegnare credenziali a quasi tutti i principali servizi applicativi Microsoft. In casi limitati, queste credenziali possono essere utilizzate nei flussi di concessione delle credenziali client OAuth 2.0 per accedere a Microsoft Graph, agendo come applicazione Microsoft all'interno del tenant del cliente.

Come per l'applicazione personalizzata dell'esempio precedente, abbiamo assegnato una credenziale al service principal dell'applicazione Microsoft Device Registration Service. È stato quindi possibile autenticarsi e accedere a Microsoft Graph come Device Registration Service(Figura 6).

Elevazione dei privilegi attraverso le applicazioni Microsoft

Nel corso delle nostre ricerche, abbiamo scoperto che a determinati presidi del servizio applicativo Microsoft era consentito eseguire determinate azioni che non erano definite nell'elenco delle autorizzazioni autorizzate. In altre parole, ci è stato permesso di eseguire determinate azioni privilegiate anche se non sembravamo avere il permesso di farlo.

All'interno di Microsoft Graph, le autorizzazioni disponibili possono essere determinate esaminando gli ambitiassegnati , iltermine OAuth 2.0 per indicare le autorizzazioni.

Nell'esempio mostrato nella Figura 6, si può notare che gli ambiti sono vuoti per il Device Registration Service (Figura 7). Questo dovrebbe significare che l'applicazione non ha il permesso di fare nulla attraverso l'API Graph e dovrebbe ricevere una risposta 403 non autorizzata quando si tenta un'azione non autorizzata.

Tuttavia, quando abbiamo tentato di eseguire alcune azioni privilegiate, siamo riusciti a farlo. In questo esempio, la Figura 8 e la Figura 9 mostrano un tentativo riuscito di aggiungere un utente al ruolo di Amministratore globale come Servizio di registrazione dispositivi.

I nostri risultati

Attraverso la nostra ricerca, abbiamo scoperto le seguenti capacità per ciascuno dei servizi specificati. La portata dell'impatto è all'interno del tenant Entra mirato.

Viva Engage (Yammer)

La possibilità di eliminare e cancellare definitivamente gli utenti, compresi gli utenti privilegiati come gli Amministratori globali. MSRC ha classificato questa capacità come una vulnerabilità di media gravità.

Servizio di gestione dei diritti Microsoft

La capacità di creare utenti. L'MSRC ha classificato questa capacità come di bassa gravità. La spiegazione della bassa gravità è dovuta al fatto che gli oggetti utente creati non sono privilegiati.

Servizio di registrazione dei dispositivi

La possibilità di modificare l'appartenenza a ruoli privilegiati, compreso il ruolo di Amministratore globale. MSRC ha classificato questa capacità come di gravità importante, elevazione dei privilegi sotto Identità (Entra ID).

Utilizzo del meccanismo per l'elevazione e la persistenza dei privilegi

Tutti i nostri risultati sono preoccupanti in quanto aggirano i controlli di autorizzazione noti. Tuttavia, la scoperta del Device Registration Service è il punto focale per l'elevazione dei privilegi e la potenziale persistenza da parte di un attaccante.

In un tenant Entra, gli Amministratori delle applicazioni, gli Amministratori delle applicazioni cloud, gli Amministratori globali e gli utenti assegnati come Proprietario di un'applicazione possono assegnare le credenziali al service principal.

L' Amministratore dell'applicazione e l'Amministratore dell'applicazione cloud sono considerati ruoli privilegiati da Microsoft, come indicato nella documentazione "Ruoli integrati in Microsoft Entra". In molte aziende, le integrazioni di applicazioni di terze parti potrebbero fornire altri percorsi di elevazione dei privilegi e di abuso nel caso in cui un Amministratore di applicazioni o un Amministratore di applicazioni cloud venisse compromesso, indipendentemente dal fatto che l'organizzazione sia consapevole o meno di aver impostato questi percorsi.

Tuttavia, in un tenant Entra greenfield (nuovo), né l'Application Administrator né il Cloud Application Administrator hanno i diritti per gestire l'assegnazione di ruoli privilegiati in un tenant Entra.

È inoltre importante notare che questi ruoli non hanno la possibilità di acconsentire alle autorizzazioni dell'API di Microsoft Graph, il che è un comune fraintendimento da parte di chi lavora con Entra ID.

Se un utente malintenzionato, a conoscenza della falla nel Device Registration Service, dovesse compromettere un utente a cui è stato assegnato il ruolo di Application Administrator o Cloud Application Administrator, potrebbe utilizzare tale accesso per ottenere il ruolo di Global Administrator o qualsiasi altro ruolo desiderato.

Sebbene possa sembrare un po' banale per un utente malintenzionato persistere con il ruolo di Amministratore globale, la persistenza potrebbe essere installata con questi privilegi creando una nuova registrazione di app e un service principal con autorizzazioni privilegiate per le applicazioni. Allo stesso modo, un aggressore potrebbe installare nuovi permessi applicativi privilegiati in un'applicazione single-tenant esistente o trovare un'applicazione privilegiata esistente e installare credenziali aggiuntive. Le organizzazioni che non monitorano costantemente questo tipo di modifiche e che non dispongono della maturità necessaria per determinare le operazioni note da quelle dannose in Entra ID, probabilmente non si accorgeranno dell'installazione di un accesso persistente o della modifica temporanea dell'assegnazione dei ruoli in Entra ID.

La correzione e l'anello mancante nascosto

Apprezziamo le conversazioni avute con MSRC e con il team Microsoft Identity durante la risoluzione dei nostri problemi. Le nostre preoccupazioni riguardavano principalmente la mancanza di un ambito di applicazione (autorizzazione) nell'accesso a Microsoft Graph.

Durante la nostra conversazione, Microsoft ha fatto presente di avere altri meccanismi di autorizzazione che esistono dietro le quinte per le applicazioni Microsoft. Questi meccanismi ci hanno permesso di eseguire le azioni descritte in questo articolo.

Microsoft ha giustamente sottolineato che questa funzionalità non costituisce un difetto sostanziale all'interno di nessuno dei suoi modelli di autorizzazione. Tuttavia, ha riconosciuto che esternamente, sulla base di ciò che possiamo vedere e a cui abbiamo accesso, le funzionalità potrebbero sembrare in errore. Esternamente a Microsoft, gli ambiti di OAuth 2.0 sono assoluti quando si interagisce con Microsoft Graph, quindi, senza conoscere altri sistemi di autorizzazione, possiamo solo dedurre.

Inoltre, la nostra ricerca ha portato a molte modifiche da parte di Microsoft per limitare ulteriormente la possibilità di utilizzare le credenziali nelle applicazioni Microsoft. Microsoft ha implementato ulteriori controlli che limitano la possibilità di utilizzare le credenziali sui service principal. Abbiamo osservato che l'elenco dei service principals con cui è possibile autenticarsi si è continuamente ridotto.

Quando ora tentiamo di autenticarci come Device Registration Service, riceviamo un errore da Microsoft Graph(Figura 10).

Rilevamento di abusi precedenti

Le applicazioni al centro delle nostre scoperte sono probabilmente presenti nella maggior parte dei clienti Microsoft. Siamo convinti che questa falla esista almeno da quando esistono queste applicazioni, ovvero da diversi anni.

I due metodi di rilevamento di questo abuso sono i registri di audit Entra ID e le credenziali persistenti nelle applicazioni abusate. Purtroppo, entrambi i metodi hanno dei limiti. I registri di audit forniscono valore solo per il tempo in cui vengono conservati e un utente malintenzionato potrebbe aver rimosso le credenziali sulle applicazioni inizialmente abusate dopo aver installato un'ulteriore persistenza.

Se un'organizzazione trova dati che indicano che sono state assegnate credenziali al Device Registration Service o scopre dati di audit per il Device Registration Service, deve avere un alto livello di preoccupazione. Non conosciamo alcun motivo valido per cui al Device Registration Service sia stata assegnata una credenziale.

Credenziali persistenti

È possibile utilizzare Microsoft Graph per ispezionare i presidi di servizio interessati, in modo da determinare se sono state aggiunte credenziali supplementari.

Per queste query di Graph, ispezionare l'output per determinare se i valori sono stati impostati o se la credenziale viene restituita come nulla.

L'ID applicazione è un valore univoco a livello globale. Questi comandi PowerShell e la query Microsoft Graph funzionano in qualsiasi tenant Entra.

Servizio di registrazione dei dispositivi

Microsoft Graph PowerShell SDK

((Get-MGServicePrincipal -Filter "AppId eq '01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9'").KeyCredentials).count

((Get-MGServicePrincipal -Filter "AppId eq '01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9'").PasswordCredentials).count

Query Microsoft Graph

https://graph.microsoft.com/v1.0/servicePrincipals(appId='01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9')?$select=keyCredentials,passwordCredentials

Voci del registro di audit

Le organizzazioni possono esaminare i dati dei registri di audit Entra ID che corrispondono a determinati modelli. Si noti che la possibilità di ricercare i dati dei registri di audit sarà possibile solo a partire dalla data in cui l'organizzazione ha memorizzato tali registri.

Caccia alle azioni da parte del Servizio di registrazione dispositivi

AuditLogs

| where parse_json(tostring(InitiatedBy.app)).displayName == "Device Registration Service"

Caccia all'assegnazione dei segreti al servizio di registrazione dei dispositivi

AuditLogs

| where OperationName == "Add service principal credentials"

| where TargetResources[0].displayName == " Device Registration Service"

Protezione dei clienti Semperis

Per gli utenti di Semperis Directory Services Protector ( DSP) o Purple Knightstiamo rilasciando un indicatore di sicurezza, Credenziali sospette sul service principal di Microsoft, che controllerà e segnalerà le credenziali assegnate a Device Registration Services e Viva Engage. Nell'ottica di una sicurezza dell'identità a più livelli, le organizzazioni possono anche controllare i log di audit SIEM per individuare eventuali marcatori.

Bloccare gli attacchi che colpiscono le applicazioni privilegiate

Le applicazioni privilegiate e i relativi presidi di servizio in Entra ID sono uno dei mezzi più comuni che gli aggressori hanno per prendere piede e mantenere la persistenza in Entra ID e per spostarsi in altre proprietà del cloud come Microsoft 365, Azure e applicazioni multicloud e SaaS che si integrano con Entra ID.

Una delle migliori difese che le organizzazioni possono adottare è quella di garantire che l'Amministratore delle applicazioni e l'Amministratore delle applicazioni cloud siano considerati altamente privilegiati come gli Amministratori globali, e che le best practice come la separazione dei privilegi, le postazioni di lavoro ad accesso privilegiato e l'autenticazione forte e resistente al phishing siano considerate come requisiti, non come opzioni.

Ricerche correlate e riconoscimenti

La ricerca nello spazio delle applicazioni Entra ID e dei service principal non è un concetto nuovo. La nostra ricerca si sovrappone a quella analoga del 2019 di Dirk-jan Mollema, che ha esplorato l'assegnazione di credenziali ai service principal e lo sfruttamento delle autorizzazioni delle applicazioni OAuth 2.0 per eseguire funzioni che un Application Administrator non dovrebbe essere in grado di eseguire. Da allora, l'elenco delle applicazioni utilizzabili si è ridotto ed è stato ulteriormente ridotto nel luglio 2024 a seguito della risposta di Microsoft alle nostre scoperte.

Divulgazione e tempistica

Le scoperte descritte in questo post sono state comunicate al MSRC come documentato nella seguente cronologia. Essendo una scoperta complessa, è stato necessario un po' di tempo per esaminare i risultati con MSRC. Apprezziamo la rapidità con cui è stato risolto il problema del Device Registration Service e l'impegno di Microsoft a proteggere ulteriormente le sue applicazioni sulla base del nostro lavoro di collaborazione.

• 11 gennaio 2024: Creazione di casi MSRC
• 30 gennaio 2024: MSRC ha fornito una risposta iniziale di bassa gravità
• 6 febbraio 2024: Risposta fornita al MSRC in merito all'assegnazione della gravità
• 4 marzo 2024: Il servizio di registrazione dei dispositivi è stato riclassificato come gravità importante.
• 4 marzo 2024: Viva Engage classificato a bassa gravità
• 4 marzo 2024: Microsoft Rights Management Services classificato come di bassa gravità
• 4 marzo 2024: Caso Microsoft Rights Management Services risolto e chiuso
• 4 marzo 2024: Caso del servizio di registrazione dei dispositivi risolto e chiuso
• 1 aprile 2024: Viva Engage è stato riclassificato a media gravità.
• 17 aprile 2024: Fornito avviso iniziale a MSRC in merito alla divulgazione.
• 19 aprile 2024: Caso Viva Engage risolto e chiuso
• 5 giugno 2024: Invio della bozza dell'articolo di divulgazione al MSRC.
• 13 giugno 2024: Incontro con l'MSRC in merito a casi e divulgazione
• 7 agosto 2024: Divulgazione al pubblico