Tomer Nahum

Questo post descrive un abuso della sincronizzazione hard matching in Entra Connect che può portare all'acquisizione dell'account Entra ID. Questi risultati si basano sulla ricerca pubblicata da Semperis in agosto, che descriveva l' abuso della corrispondenza morbida (nota anche come corrispondenza SMTP).

Questa vulnerabilità SyncJacking significa che un utente malintenzionato con determinati privilegi può abusare della sincronizzazione delle corrispondenze in Entra Connect per assumere completamente il controllo di qualsiasi account Entra ID sincronizzato, compreso l'amministratore globale attivo.

Questi risultati sono stati prontamente segnalati al Microsoft Security Response Center (MSRC), che ha aggiornato le linee guida di hardening per fornire mitigazioni più specifiche contro l'abuso di hard matching. Sebbene l'MSRC abbia risposto rapidamente e aggiornato le linee guida di hardening, ulteriori test dimostrano che l'attacco può avere successo anche dopo l'implementazione di queste mitigazioni. Pertanto, consigliamo vivamente di adottare ulteriori misure di mitigazione per contrastare l'abuso e il potenziale rilevamento dell'account Entra ID.

Entra Connect e abbinamento rigido

Come spiegato in "Abuso di corrispondenza SMTP in Azure AD", Entra Connect è un'applicazione Microsoft che supporta l'identità ibrida sincronizzando gli oggetti AD on-prem con gli oggetti Entra ID. Le caratteristiche di Entra Connect includono la sincronizzazione dell'hash delle password, l'autenticazione pass-through, l'integrazione della federazione (con ADFS) e la sincronizzazione (con Entra Connect Sync). L'acquisizione di account Entra ID hard-matching qui discussa sfrutta la sincronizzazione dell'hash della password e le funzioni generali di sincronizzazione di Entra Connect.

Per ottenere l'integrità tra l'ambiente on-prem e i tenant Entra ID nelle implementazioni di identità ibride, Entra Connect abbina gli oggetti utente tra AD ed Entra ID. Un attributo di ancoraggio della fonte, scelto durante la configurazione e la sincronizzazione iniziale di Entra Connect, identifica in modo univoco ciascuno di questi oggetti utente tra AD ed Entra ID. Entra Connect utilizza questo attributo per abbinare gli oggetti utente tra Entra ID e AD utilizzando una delle due tecniche:

  • Corrispondenza difficile
  • Corrispondenza morbida (SMTP)

Corrispondenza difficile

Se si lascia che Azure gestisca l'ancora di origine, Entra Connect cerca uno dei due possibili attributi sourceAnchor:

  • Entra Connect versione 1.1.486.0 o precedente cerca l'oggettoGUID
  • Entra Connect versione 1.1.524.0 o più recente cerca il mS-DS-ConsistencyGuid

Se l'attributo mS-DS-ConsistencyGuid non è popolato, Entra Connect scrive l'objectGUID dell'utente in tale attributo. Il valore corrispondente sull'oggetto Entra ID è ImmutableID (l'objectGUID codificato in base64). La Figura 1 mostra un esempio di hard matching: ottenere l'ImmutableID di un oggetto Entra ID dall'objectGUID dell'utente di AD on-prem.

ImmutableID e hard matching - syncjacking
Figura 1

Questo meccanismo è l'oggetto dell'abuso discusso in questo post.

Sincronizzazione dell'hash della password

La sincronizzazione dell'hash della password, un metodo di autenticazione abilitato per impostazione predefinita negli ambienti di identità ibrida Entra ID, sincronizza l'hash della password dell'utente in AD on-premise con Entra ID ogni due minuti. Questa sincronizzazione consente di utilizzare la stessa password per accedere sia ad AD che a Entra ID. (Per una spiegazione dettagliata della sincronizzazione dell'hash della password, vedere "Informazioni sulla sincronizzazione dell'hash della password di Azure AD").

In che modo gli aggressori possono utilizzare la corrispondenza difficile per facilitare l'acquisizione dell'account Entra ID

Per eseguire questo attacco, un aggressore ha bisogno solo di due autorizzazioni:

  • Write-all-Properties o GenericWrite su un account AD on-prem non sincronizzato
  • Eliminazione su un account AD on-prem sincronizzato

L'esempio seguente illustra questo attacco a un account con un ruolo di amministratore globale attivo assegnato in Entra ID. Si noti che questo attacco funziona su qualsiasi account sincronizzato.

Nutshell è un amministratore globale attivo sincronizzato in Entra ID con l'UPN nutshell@xd6z7.onmicrosoft.com (Figura 2, Figura 3).

Acquisizione sincronizzata dell'account Azure AD
Figura 2
ruolo di nutshell
Figura 3

Poiché nutshell è un utente sincronizzato, è presente nell'ambiente AD on-prem. L'aggressore dispone dell'autorizzazione Write-All-Properties su un account AliceIC di AD on-prem non sincronizzato. L'aggressore ha anche l'autorizzazione a cancellare sull'account nutshell di AD on-prem sincronizzato. Inoltre, l'aggressore possiede la password dell'account AliceIC.

Ecco come l'utente malintenzionato può utilizzare l'utente on-premise AliceIC per dirottare l'account nutshell Entra ID.

Innanzitutto, l'attaccante copia l'UPN del nutshell Entra ID nell'attributo userPrincipalName di AliceIC on-prem AD ( Figura 4).

Copiato UPN
Figura 4

La Figura 5 mostra la popolazione dell'attributo mS-DS-ConsistencyGuid di nutshell on-prem AD.

Popolazione di mS-DS-ConsistencyGuid in loco
Figura 5

Successivamente, l'attaccante copia il valore dell'attributo nutshell mS-DS-ConsistencyGuid nell'attributo AliceIC mS-DS-ConsistencyGuid (Figura 6).

Copiare il valore dell'attributo nutshell nell'attributo AliceIC
Figura 6

Infine, l'attaccante elimina l'account nutshell on-prem e attende la sincronizzazione (Figura 7).

Active Directory - Eliminazione dell'account nutshell on-prem
Figura 7

Ora, l'account AliceIC di AD on-prem è sincronizzato con l'account Entra ID nutshell. Poiché Entra Connect utilizza la sincronizzazione dell'hash della password per impostazione predefinita, anche la password di AliceIC e l'attributo DisplayName vengono sincronizzati con l'account nutshell Entra ID.

AliceIC è ora un amministratore globale attivo e agisce per conto di nutshell (Figura 8). Come già detto, non si troverà traccia di queste modifiche nei registri on-prem e solo una traccia minima nei registri Entra ID.

Acquisizione del conto raggiunta
Figura 8

È importante notare perché gli aggressori potrebbero sfruttare questo metodo:

  • L'uso dell'hard matching per facilitare l'acquisizione dell'account Entra ID non lascia alcuna traccia nei registri AD on-prem e solo una traccia minima nei registri Entra ID.
  • L'attacco richiede solo due autorizzazioni sugli account di destinazione per prendere completamente il controllo di qualsiasi account sincronizzato con qualsiasi ruolo.
  • Un utente malintenzionato che dispone di autorizzazioni relativamente elevate in AD può assumere il controllo di Entra ID rilevando qualsiasi account sincronizzato con un'assegnazione Active/Eligible.

Potenziali abusi

Delega dell'utente. Se a un utente o a un gruppo è stato delegato il controllo della gestione degli utenti in una o più unità organizzative (UO) con utenti sincronizzati e non sincronizzati, l'utente o il gruppo in questione ha il pieno controllo di questi oggetti e può dirottarne uno qualsiasi, diventando teoricamente anche un Amministratore globale.

Operatori account. Qualsiasi utente del gruppo Operatori account può gestire tutti gli account e ha privilegi di creazione di account. Pertanto, qualsiasi Operatore account può dirottare gli utenti sincronizzati.

Utilizzo di Semperis DSP per rilevare questo tipo di acquisizione dell'account Entra ID

Semperis Directory Services Protector ( DSP) raccoglie le modifiche dell'ID Entra e i dati dell'AD on-prem e li utilizza per rilevare i tentativi di sfruttamento di questa vulnerabilità. Nonostante le tracce minime lasciate dall'attacco, le capacità specifiche di DSPne consentono il rilevamento.

Altri rilevamenti dell'abuso di SyncJacking

È possibile ipotizzare ragionevolmente (anche se non definitivamente) che questo attacco si sia verificato se in Entra ID si verificano due eventi di registro uno dopo l'altro: "Cambia password utente" seguito da "Aggiorna utente" con un DisplayName modificato e un obiettivo che utilizza lo stesso UPN(Figura 9, Figura 10).

"Evento "Modifica password utente
Figura 9
"Evento "Aggiorna utente
Figura 10

 

Correzione del SyncJacking

Il MSRC ha aggiornato le sue linee guida per includere la seguente raccomandazione:

Disattivare l'acquisizione hard match. L'hard match takeover consente a Entra Connect di assumere il controllo di un oggetto gestito nel cloud e di cambiare la fonte di autorità per l'oggetto in Active Directory. Una volta che l'origine dell'autorità di un oggetto viene assunta da Entra Connect, le modifiche apportate all'oggetto Active Directory collegato all'oggetto Entra ID sovrascriveranno i dati Entra ID originali, compreso l'hash della password, se la sincronizzazione dell'hash della password è abilitata. Un utente malintenzionato potrebbe utilizzare questa funzionalità per assumere il controllo degli oggetti gestiti nel cloud. Per mitigare questo rischio, disabilitare l'acquisizione delle corrispondenze.

I nostri test dimostrano che SyncJacking funziona anche dopo aver disabilitato l'hard match takeover. In ogni caso, è importante applicare questa linea guida per l'hardening.

MSRC afferma che è importante abilitare l'MFA per tutti gli utenti che hanno accesso privilegiato in Entra ID o in AD. Attualmente, l'unico modo per mitigare questo attacco è applicare l'MFA a tutti gli utenti sincronizzati. Questo non è un modo sicuro per impedire a un aggressore di accedere al vostro account in caso di abuso di SyncJacking, ma può essere utile. Assicuratevi di seguire tutte le linee guida di hardening fornite da Microsoft nel link precedente per mitigare molte superfici di attacco nel vostro ambiente di identità ibrido. Per una protezione ancora maggiore, considerate l'implementazione di DSP per Identity Threat Detection and Response (ITDR).

Tempistica di divulgazione

  • 6 ottobre: Semperis scopre un abuso e lo segnala al MSRC.
  • 12 ottobre: MSRC risponde con le linee guida per l'hardening.
  • 18 ottobre: Semperis risponde a MSRC con nuove informazioni; l'attacco funziona ancora con le mitigazioni applicate.
  • 27 ottobre: Il MSRC riapre il caso per rivedere le informazioni.
  • 4 novembre: MSRC aggiorna le linee guida per l'hardening della documentazione per mitigare in modo specifico l'abuso di hard matching e fa notare che il comportamento di hard matching qui descritto è stato progettato.
  • 7 novembre: Semperis risponde a MSRC; l'attacco funziona ancora con le linee guida di hardening applicate.
  • 11 novembre: l'MSRC sostiene che il comportamento è stato progettato.

Ringraziamenti

Un ringraziamento speciale alle seguenti persone:

  • Andrea Pierini (@decoder_it)
  • Charlie Clark (@exploitph)
  • Sapir Federovsky (@sapirxfed)

Un riconoscimento speciale al MSRC per aver riconosciuto l'esposizione e aver risposto rapidamente con linee guida aggiornate.

Per saperne di più