EntraGoat Scenario 3: Sfruttare la proprietà del gruppo in Entra ID

Nota dell'editore

Questo scenario fa parte di una serie di esempi che dimostrano l'uso di EntraGoat, il nostro ambiente di simulazione Entra ID. Una panoramica di EntraGoat e del suo valore è disponibile qui.

Membro del gruppoIl naufragio: in acque amministrative

Lo scenario 3 di EntraGoat dimostra come le funzioni amministrative legittime di Entra ID - proprietà dei gruppi, gruppi assegnabili per ruolo e gestione del service principal - possano essere concatenate in un percorso di escalation dei privilegi non intenzionale da un utente con privilegi bassi all'amministratore globale.

L'attaccante inizia con un account di supporto IT compromesso che possiede diversi gruppi, tra cui uno che è assegnabile con il ruolo Application Administrator ruolo. Aggiungendosi a questo gruppo, l'attaccante eredita il ruolo e ottiene un ampio controllo sulle applicazioni e sui principali servizi del tenant.

Da qui, identificando un committente di servizio ad alto valore che è membro di un altro gruppo assegnabile al ruolo che detiene il Privileged Authentication Administrator l'attaccante aggiunge un segreto del client, si autentica come principale del servizio privilegiato e reimposta la password dell'amministratore globale.

Questo scenario evidenzia come le funzionalità Entra ID, singolarmente legittime, se combinate con una configurazione errata della proprietà di gruppo, possono creare una catena di escalation dei privilegi che eleva un account di basso livello in una minaccia per tutto il condominio.

Panoramica del percorso di attacco

1. Storia di un primo punto d'appoggio: L'attaccante si autentica come Michael Chen, un utente IT Support Specialist compromesso che, secondo la descrizione dello scenario, "gestisce alcuni gruppi di sicurezza".
2. Enumerazione: L'attaccante scopre la proprietà di sei gruppi, tra cui un gruppo assegnabile al ruolo chiamato IT Application Managers che contiene il Application Administrator ruolo.
3. Escalation dei privilegi: L'attaccante si aggiunge al gruppo di sicurezza per ereditare il ruolo privilegiato.
4. Servizio principale mirato: Con il Application Administrator ruolo di directory, l'attaccante identifica il Identity Management Portal servizio principale come membro di un gruppo con il Privileged Authentication Administrator e vi aggiunge un segreto del cliente.
5. Pivoting: L'attaccante si autentica tramite il flusso OAuth2 di concessione delle credenziali del client come mandante del servizio compromesso con il nuovo segreto aggiunto.
6. Compromissione dell'account: utilizzando i privilegi intrinseci del service principal, l'attaccante reimposta la password dell'amministratore globale, si autentica come GA e recupera il flag di scenario.

Flusso di attacco

La Figura 1 mostra il flusso di questo attacco.

Perché questo attacco funziona

Questo scenario mette insieme diverse funzioni legittime dell'Entra ID che, se mal configurate, creano un percorso di escalation:

• Proprietà del gruppo: Il modello di proprietà dei gruppi di Entra ID garantisce un ampio controllo sull'appartenenza e sulle proprietà. Sebbene abbia lo scopo di delegare le attività amministrative, diventa rischioso quando viene applicato a gruppi con ruoli assegnati o concesso a utenti non appropriati, poiché un proprietario può aggiungere direttamente se stesso (o qualsiasi account controllato) al gruppo ed ereditare i ruoli assegnati.
• Gruppi assegnabili ai ruoli: I gruppi di sicurezza con assegnazione di ruoli consentono agli amministratori di assegnare ruoli di directory a gruppi piuttosto che a singoli utenti, semplificando la gestione dei ruoli su scala e facendo sì che qualsiasi membro del gruppo riceva automaticamente i ruoli assegnati. In combinazione con i permessi di proprietà dei gruppi, si crea un percorso di escalation dei privilegi in cui i proprietari dei gruppi possono effettivamente concedersi i ruoli assegnati ai gruppi che controllano.
• Appartenenza al gruppo principale del servizio: I principali del servizio, come gli utenti, possono essere membri di gruppi di sicurezza ed ereditare i ruoli assegnati a tali gruppi. Questo design consente agli amministratori di gestire le autorizzazioni delle applicazioni attraverso l'appartenenza a un gruppo piuttosto che attraverso l'assegnazione di ruoli individuali. Tuttavia, i presidi di servizio presentano superfici di attacco uniche che i normali utenti di Entra ID non hanno. Questi meccanismi aggiuntivi creano un maggior numero di potenziali vettori per ottenere un accesso non autorizzato a qualsiasi servizio privilegiato principale che detiene appartenenze a gruppi privilegiati.
  • Possono essere compromessi attraverso i rapporti di proprietà (come si è visto nello Scenario 1).
  • Sono soggetti a controlli di gestione delle applicazioni, identità con il sistema di controllo incorporato. Application Administrator o Cloud Application Administrator ruoli, ruoli personalizzati che includono l'opzione microsoft.directory/applications/credentials/update o microsoft.directory/servicePrincipals/credentials/update azioni, o presidi di servizio con il Application.ReadWrite.All che può aggiungere o modificare le credenziali del preside del servizio.
  • Possono essere gestiti in modo programmatico attraverso API e flussi di lavoro di automazione.
  • A differenza delle identità utente, non possono essere assegnati come idonei al PIM; possono solo avere assegnazioni di ruolo attive (che possono essere limitate nel tempo). Quando un mandante di servizio è in un gruppo assegnabile a un ruolo, il suo accesso aggira i controlli di attivazione just-in-time di PIM, fornendo un'appartenenza al ruolo sempre attiva durante la finestra di assegnazione.
  • Possono autenticarsi in un contesto di sola app (credenziali client OAuth2) utilizzando un segreto o un certificato del client, aggirando così i controlli incentrati sull'utente come l'MFA interattivo e i requisiti di accesso condizionato interattivo.
• Ambito dell'amministratore delle applicazioni: Il ruolo fornisce un ampio controllo sulle registrazioni delle applicazioni e sui principali servizi, compresa la possibilità di aggiungere credenziali di autenticazione (segreti e certificati) alle applicazioni nel tenant, creando opportunità per gli aggressori di effettuare il backdoor dei principali servizi di alto valore che non sono configurati con il blocco dell'istanza dell'applicazione.

Ciascuna di queste funzioni di Entra ID è legittima e necessaria per la delega amministrativa, ma in combinazione creano percorsi di escalation dei privilegi non voluti che possono elevare un'identità a basso privilegio fino ad amministratore globale.

Come individuare e difendersi dall'uso improprio della proprietà di gruppo

Il monitoraggio della proprietà del gruppo è un requisito di sicurezza fondamentale in qualsiasi ambiente Entra ID.

I proprietari possono gestire l'appartenenza, modificare le proprietà del gruppo e controllare indirettamente i ruoli di directory assegnati ai loro gruppi. Senza una chiara visibilità delle relazioni di proprietà e delle assegnazioni di ruolo, i percorsi di escalation dei privilegi attraverso i gruppi assegnati ai ruoli possono rimanere nascosti sia ai difensori che ai revisori.

I difensori devono monitorare e correlare:

• Quali gruppi assegnabili al ruolo esistono nel tenant?
• Quali ruoli di directory sono assegnati a questi gruppi?
• Chi li possiede e quale giustificazione commerciale esiste per tale proprietà?
• Gli utenti non privilegiati possiedono gruppi con assegnazione di ruoli privilegiati?
• Quali sono i presidi di servizio che fanno parte di gruppi assegnabili per ruolo?
• Ci sono gruppi inutilizzati o orfani che possono essere disattivati?

Le soluzioni Semperis aiutano a colmare le lacune nella comprensione di queste domande con molteplici livelli di difesa, a partire dagli indicatori di esposizione (IOE) e dagli indicatori di compromissione (IOC).

Questi indicatori rilevano automaticamente e segnalano le impostazioni predefinite e le configurazioni errate pericolose, come i gruppi assegnabili per ruolo con proprietari non appropriati, i principali servizi con autorizzazioni pericolose e le linee di base deboli della governance dei gruppi che consentono l'escalation dei privilegi attraverso la manipolazione dei membri dei gruppi.

Approfondimento dello scenario: Soluzione descritta passo dopo passo

La guida completa e i relativi comandi sono disponibili nel repository GitHub di EntraGoat, alla voce solutions/EntraGoat-Scenario3-Solution.ps1.

Fase 1: Punto d'appoggio iniziale

Iniziamo lo Scenario 3, come Figura 2 mostra, con l'accesso a un utente compromesso a basso privilegio di nome Michael Chen, uno specialista dell'assistenza informatica. L'antefatto ci dice che Michael possiede diversi gruppi di sicurezza: una configurazione errata che pone le basi per un'escalation.

Ci si autentica con le sue credenziali utilizzando Connect-MgGraph e poi eseguire Get-MgContext per confermare il nostro attuale contesto di sicurezza (Figura 3).

Fase 2: Enumerazione

Quindi, dato che il suggerimento ci indica questa direzione, enumeriamo tutti i gruppi posseduti dall'utente corrente(Figura 4).

Scopriamo che possiede sei gruppi in totale. Per valutare il potenziale di escalation dei privilegi, verifichiamo se uno di essi è assegnabile a un ruolo e se ha effettivamente dei ruoli assegnati(Figura 5).

Un gruppo si distingue immediatamente: IT Application Managers, che detiene il Application Administrator ruolo.

Questo ruolo è potente perché garantisce il pieno controllo su tutte le registrazioni delle applicazioni e sui service principal del tenant, compresa la possibilità di aggiungere segreti o certificati a qualsiasi applicazione di terze parti (nel caso in cui non siano configurate con il blocco dell'istanza dell'app). Quindi, l'attaccante può usare l'identità del service principal per autenticarsi al tenant tramite il flusso di concessione delle credenziali del client OAuth 2.0, operando in un contesto di sola applicazione che aggira le protezioni incentrate sull'utente.

Nota: i passaggi di enumerazione sopra descritti possono essere racchiusi in funzioni ausiliarie dedicate (ad esempio, Get-GroupsOwnedBy per la proprietà e Get-GroupRoles per i ruoli assegnati) per rendere il processo più interattivo e verboso, simile a come gli strumenti open-source presentano i risultati.

La Figura 6 e la Figura 7 mostrano l'implementazione.

La Figura 8 mostra come appare l'output appariscente quando si esegue questa funzione di enumerazione con l'ID dell'utente corrente.

Sebbene ciò possa essere utile in ambienti di grandi dimensioni, Microsoft Graph offre anche un cmdlet molto più efficiente: Get-MgUserOwnedObject (Figura 9).

Get-MgUserOwnedObject enumera tutti gli oggetti della directory di proprietà di un utenteeliminando la necessità di interrogare singolarmente ogni tipo di oggetto (gruppi, dispositivi, app e presidi di servizio), a differenza della nostra implementazione intenzionale. Il comando può essere leggermente modificato con Sonnet per ottenere un output più gradevole (Figura 10).

Il comando Get-MgUserOwnedObject tipicamente fa una richiesta API a https://graph.microsoft.com/v1.0/users/{userId}/ownedObjects (eventualmente aggiungendo una o due richieste in più, a seconda della paginazione), mentre il resto è gestito dalla logica locale di PowerShell per elaborare, estrarre e formattare la risposta.

In confronto, il Get-GroupsOwnedBy La funzione che abbiamo creato, che potrebbe essere più interattiva e facile da usare, rende 100-1000x richieste APIanche se controlla un solo tipo di oggetto posseduto.

Quando si scelgono gli strumenti di enumerazione, è sempre una buona idea dare la priorità all'efficienza. Meno chiamate API significano meno registri e una minore impronta di rilevamento. Esistono molti strumenti open-source fantastici (e alcuni meno fantastici) per l'enumerazione degli ambienti Entra ID. Il punto chiave è che, sebbene gli strumenti possano essere utili scorciatoie, non dovrebbero mai essere utilizzati come scatole nere. Se potete leggere il codice sorgente, fatelo. Prendetevi il tempo necessario per capire come vengono costruite le query, quali endpoint API vengono raggiunti e quali dati vengono effettivamente restituiti. Gli strumenti sono efficaci quanto la comprensione dei loro metodi e dei loro limiti da parte dell'operatore.

Fase 3: costruzione della catena di attacco

Possedere un gruppo con Application Administrator presenta un potenziale significativo di escalation dei privilegi perché una volta che ci aggiungiamo come membri, possiamo gestire (== aggiungere un segreto del cliente) qualsiasi del servizio principale nel tenant, che apre più vie alla compromissione del tenant.

Ma aggiungersi in questo momento sarebbe rumoroso e inutile dal punto di vista dell'OPSEC. Per prima cosa, dovremmo confermare l'esistenza di un servizio privilegiato principale che possiamo sfruttare per raggiungere la catena successiva dell'attacco: il ruolo GA.

È tempo di andare a caccia di committenti di servizi di alto valore.

Nota: in questa guida, ci concentreremo sull'enumerazione dei presidi di servizio con ruoli privilegiati che possono reimpostare la password del GA con pochi passaggi:

• Amministratore di ruolo privilegiato (PRA)
• Amministratore di autenticazione privilegiata (PAA)
• Amministratore globale (GA)

Tuttavia, in un tenant reale non ci si può fermare qui. È altrettanto importante enumerare i principali servizi con altri ruoli e con potenti autorizzazioni per le applicazioni, poiché questi possono aprire percorsi di escalation altrettanto pericolosi, come si è visto nello Scenario 2.

Inizieremo utilizzando la funzione Get-MgRoleManagementDirectoryRoleAssignment per verificare se a un preside di servizio sono assegnati direttamente ruoli privilegiati (Figura 11).

Risultato? Nulla. Non c'è un solo responsabile di servizio che detenga direttamente GA, PRA o PAA nel mio inquilino.

Ma questo non è l'insieme completo dei principali servizi che potrebbero avere ruoli privilegiati assegnati. Entra ID consente di assegnare ruoli ai gruppi e, proprio come gli utenti, i service principal possono essere membri di tali gruppi. Se un gruppo è GA, PRA o PAA, qualsiasi service principal al suo interno eredita tali privilegi. Questo è un vettore di escalation spesso trascurato.

Quindi, si enumerano tutti i gruppi che sono assegnabili ai ruoli e si controlla quali hanno i ruoli assegnati(Figura 12).

Ora che abbiamo un elenco di gruppi privilegiati, dobbiamo ispezionare i loro membri. Poiché la funzione Get-MgGroupMember opera sulla v1.0, non mostra le appartenenze al service principal. Per risolvere questo problema, faremo una chiamata diretta al servizio /beta in una funzione di aiuto (Figura 13).

Ora possiamo usarlo per filtrare l'appartenenza del service principal ai gruppi privilegiati(Figura 14).

Ora le cose si fanno interessanti: abbiamo scoperto potenziali presidi di servizio con ruoli privilegiati. A seconda dell'ambiente, potrebbero essercene molti altri.

Possiamo semplicemente scegliere il primo ($targetSPs[0]), ma per motivi di coerenza (e per far sì che ogni giocatore abbia lo stesso percorso senza rischiare la stabilità dell'inquilino), ci concentreremo sull'elemento Identity Management Portal, come Figura 15 mostra. Questo fa parte dello script di configurazione e non romperà nulla in caso di modifica della funzionalità (incrociando le dita).

A questo punto, abbiamo tracciato l'intera catena di attacco. Ecco come ci muoveremo dall'attuale utente con privilegi bassi fino a Global Admin:

1. Aggiungiamo noi stessi al IT Application Managers per ereditare il gruppo Application Administrator ruolo.
2. Usare questo ruolo per aggiungere un segreto del cliente al file Identity Management Portal principale del servizio.
3. Autenticarsi come mandante del servizio.
4. Utilizzare i privilegi PAA ereditati per reimpostare la password dell'amministratore globale.
5. Accedere come amministratore globale con la nuova password.
6. Recuperare la bandiera per dimostrare il compromesso.

Passo 4: esecuzione del percorso di attacco

Per prima cosa, ci aggiungiamo come membri al gruppo IT Application Managers gruppo, come Figura 16 spettacoli.

Poiché i token non si aggiornano automaticamente, è possibile disconnettersi e ripetere l'autenticazione per ottenere un nuovo token di accesso con il nuovo ruolo assegnato. Come discusso nello Scenario 2, questo passaggio non è obbligatorio, poiché la maggior parte degli endpoint Entra ID di solito valuta le assegnazioni di ruolo in modo dinamico.

Possiamo utilizzare il parse-JWTToken di BARK per vedere il ruolo di amministratore dell'applicazione aggiunto (il wids all'interno del token JWT che Figura 17 mostra) assegnati all'utente.

Con Application Administrator possiamo aggiungere l'accesso backdoor al sistema di Identity Management Portal (Figura 18), come abbiamo fatto in Scenario 1.

In questo modo si ottiene un accesso persistente al service principal, indipendente da qualsiasi account utente. Possiamo usarlo per autenticarci come mandante del servizio a Entra ID, come mostra la Figura 19 .

Il passo successivo consiste nel trovare l'utente GA di destinazione e reimpostare la sua password(Figura 20).

Infine, possiamo autenticarci come GA e recuperare il flag (Figura 21). Utilizzeremo Get-MSGraphTokenWithUsernamePassword per autenticarsi dalla CLI (proprio come in Scenario 2), ma si può anche impostare un TAP (come in Scenario 1) e accedere in modo interattivo dal portale Azure o dal centro di amministrazione Entra ID.

Scenario 3 completato!

Fase 5: pulizia

Non dimenticate di eseguire lo script di pulizia(Figura 22) per riportare l'ambiente del tenant allo stato originale.

Lezioni apprese

Lo scenario 3 rivela come errori di configurazione apparentemente minori nella proprietà dei gruppi possano portare a una compromissione completa del tenant. La catena di attacco (dall'utente con privilegi bassi all'amministratore globale) non ha richiesto tecniche sofisticate, ma solo la comprensione del modello di delega di Entra ID, del funzionamento dell'ereditarietà dei ruoli e del piano di controllo delle identità principali del servizio.

Il punto chiave da cui partire: La proprietà dei gruppi è una delega amministrativa sotto mentite spoglie. Quando gli utenti possiedono gruppi assegnabili a un ruolo, controllano effettivamente tutti i ruoli assegnati a tali gruppi. I presidi di servizio amplificano questo rischio perché possono essere compromessi attraverso molteplici vie oltre al tradizionale furto di credenziali: relazioni di proprietà, ruoli di gestione delle applicazioni e accesso programmatico.

Lo scenario mostra che nei moderni ambienti di identità cloud i percorsi di escalation dei privilegi sono raramente lineari. Si intrecciano con le relazioni di proprietà, le appartenenze ai gruppi e le identità dei principali servizi in modi che richiedono ai difensori di pensare sistematicamente alle relazioni di identità piuttosto che alle autorizzazioni individuali.

Lo specialista dell'assistenza IT con un basso livello di privilegio non doveva rompere nulla: il percorso di escalation era integrato nella configurazione del tenant fin dall'inizio.

Affronta la tua prossima sfida EntraGoat

GitHub - Semperis/EntraGoat
Cos'è EntraGoat? Un ambiente di simulazione Entra ID deliberatamente vulnerabile
Come iniziare con EntraGoat: violare Entra ID in modo intelligente
Scenario 1: Abuso della proprietà del service principal in Entra ID
Scenario 2: Sfruttamento dei permessi grafici solo per le app in Entra ID
Scenario 6: Sfruttamento dell'autenticazione basata su certificati per impersonare l'amministratore globale in Entra ID

Nota finale

1. https://github.com/BloodHoundAD/BARK

Esclusione di responsabilità

Questo contenuto è fornito solo a scopo educativo e informativo. Il suo scopo è quello di promuovere la consapevolezza e la correzione responsabile delle vulnerabilità di sicurezza che possono esistere sui sistemi di cui si è proprietari o che si è autorizzati a testare. È severamente vietato l'uso non autorizzato di queste informazioni per scopi malevoli, sfruttamento o accesso illegale. Semperis non approva né condona alcuna attività illegale e declina ogni responsabilità derivante dall'uso improprio del materiale. Inoltre, Semperis non garantisce l'accuratezza o la completezza dei contenuti e non si assume alcuna responsabilità per eventuali danni derivanti dal loro utilizzo.