Nel suo intervento al TROOPERS19 ("I'm in your cloud ... reading everyone's email"), Dirk-jan Mollema ha discusso di un problema da lui scoperto che consentiva l'uso della corrispondenza SMTP (detta anche soft matching) per sincronizzare gli utenti di Active Directory (AD) su Azure AD, con l'obiettivo di dirottare gli account non sincronizzati. Jan ha dichiarato che Microsoft ha bloccato la possibilità di sincronizzare gli account on-prem che avevano assegnazioni attive a ruoli amministrativi in Azure AD.
Abbiamo indagato su questa dichiarazione. Brutte notizie: La nostra ricerca mostra che chiunque abbia i privilegi di creazione di un account in un ambiente AD può modificare la password di un utente Azure AD e, con alcuni prerequisiti, ottenere un accesso privilegiato tramite l'assegnazione di ruoli idonei.
Cosa porta a questa vulnerabilità di Azure AD?
La maggior parte delle organizzazioni utilizza Active Directory per gestire le autorizzazioni e l'accesso alle risorse di rete. Molte di queste organizzazioni stanno iniziando a utilizzare anche Azure AD, un servizio di gestione delle identità e degli accessi basato sul cloud, per gestire le identità degli utenti e i privilegi di accesso a risorse come il portale Azure e Office 365.
Nelle implementazioni di identità ibride, gli oggetti sono sincronizzati tra gli ambienti AD on-premises e i tenant di Azure AD. In questi ambienti, gli utenti possono utilizzare la stessa identità sia per l'AD on-premise che per Azure AD.
Azure AD Connect
Azure AD Connect è un'applicazione Microsoft progettata per ottenere un'identità ibrida sincronizzando gli oggetti AD on-prem con gli oggetti Azure AD. Azure AD Connect comprende molte funzionalità, le più importanti delle quali sono la sincronizzazione dell'hash della password, l'autenticazione pass-through, l'integrazione della federazione (con ADFS) e la sincronizzazione (con Azure AD Connect Sync). La sincronizzazione dell'hash della password e la sincronizzazione generale sono le più importanti per questa discussione.
Durante l'installazione di Azure AD Connect Express, vengono creati nuovi account per supportare la sincronizzazione.
- Account del connettore AD DS:
- Utilizzato per leggere e scrivere su AD
- Sono state concesse le autorizzazioni Replicate Directory Changes e Replicate Directory Changes All per l'utilizzo di Password Hash Sync.
- Prefisso con MSOL_########
- Account del servizio ADSync: Utilizzato per la sincronizzazione e per l'accesso al database SQL.
- Account Azure AD Connector:
- Utilizzato per scrivere informazioni su Azure AD
- Il ruolo speciale Directory Synchronization Accounts, che ha le autorizzazioni solo per eseguire le attività di sincronizzazione della directory, è stato assegnato.
- Prefisso con Sync_*
In un'implementazione di identità ibrida, è importante l'integrità tra gli ambienti on-prem e i tenant di Azure AD. Per raggiungere questo obiettivo, Azure AD Connect abbina gli oggetti utente tra Azure AD e AD.
Durante la configurazione e la sincronizzazione iniziale di Azure AD Connect, viene scelto un attributo di ancoraggio dell'origine. Questo attributo identifica in modo univoco un oggetto utente tra AD e Azure AD. Azure AD Connect esegue la corrispondenza guardando a questo attributo e abbina gli oggetti utente tra Azure AD e AD utilizzando una delle due tecniche:
- Corrispondenza difficile
- Corrispondenza morbida (SMTP)
Corrispondenza difficile
Se si lascia che Azure gestisca l'ancora di origine, Azure AD Connect cerca uno dei due possibili attributi sourceAnchor:
- Azure AD Connect versione 1.1.486.0 e precedenti utilizzano objectGUID.
- Azure AD Connect versione 1.1.524.0 e successive utilizza mS-DS-ConsistencyGuid.
Quando l'attributo mS-DS-ConsistencyGuid non è popolato, Azure AD Connect scrive l'objectGUID dell'utente in tale attributo. ImmutableID è il valore corrispondente sull'oggetto Azure AD, in sostanza l'objectGUID codificato in base64. La Figura 1 mostra un esempio di ottenimento dell'ImmutableID di un oggetto Azure AD dall'objectGUID dell'utente on-prem AD.
Corrispondenza morbida (SMTP)
La corrispondenza soft (SMTP) utilizza due attributi che esistono sia in AD che in Azure AD:
- NomePrincipaleUtente
- proxyAddress
La corrispondenza morbida ha successo quando gli oggetti utente vengono abbinati, a condizione che si verifichino due condizioni:
- L'attributo userPrincipalName in Azure AD corrisponde a quello di AD.
- L'attributo proxyAddress primario in AD corrisponde al proxyAddress in Azure AD.
Quando una corrispondenza rigida o morbida ha successo, l'oggetto utente corrispondente viene aggiornato. Se non esiste alcuna corrispondenza, nel tenant Azure AD viene creato un oggetto utente che corrisponde all'oggetto utente di AD on-prem, utilizzando gli attributi dell'account.
Sincronizzazione dell'hash della password
La sincronizzazione dell'hash della password è un metodo di autenticazione implementato negli ambienti di identità ibrida Azure AD. Questo metodo, che è abilitato per impostazione predefinita, sincronizza l'hash della password dell'utente su AD on-prem ad Azure AD ogni due minuti. La sincronizzazione dell'hash della password consente agli utenti di utilizzare la stessa password per accedere sia ad AD che ad Azure AD. (Per una spiegazione più dettagliata della sincronizzazione dell'hash della password, vedere Semperis - Capire la sincronizzazione dell'hash della password di Azure AD).
Ruoli attivi e ruoli idonei
Agli utenti di Azure AD possono essere assegnati ruoli che concedono autorizzazioni per gestire varie risorse di Azure AD. I ruoli possono essere assegnati in modo attivo o ammissibile.
Le assegnazioni ammissibili richiedono l'attivazione del ruolo da parte dell'utente. A tal fine, l'utente deve eseguire un'azione MFA, fornire una giustificazione aziendale o richiedere l'approvazione degli approvatori designati. I ruoli idonei possono essere assegnati in modo permanente o per un periodo specifico(Figura 2). Non esiste un limite di tempo per l'attivazione di un ruolo idoneo assegnato in modo permanente.
Le assegnazioni attive non richiedono alcuna azione da parte dell'utente per l'utilizzo del ruolo. Gli utenti hanno i privilegi associati a un ruolo per tutto il tempo in cui rimangono assegnati a quel ruolo(Figura 3).
Come la corrispondenza SMTP diventa una vulnerabilità di Azure AD
Un oggetto in Azure AD può essere gestito in Azure AD o in on-prem AD. Ogni oggetto ha un flag che indica se l'account è stato sincronizzato con un account on-prem. L'esempio seguente mostra questo flag nel pannello Utenti Azure. L'utente Lee Gu è sincronizzato(Figura 4), mentre l'utente Lynne Robbins non lo è(Figura 5).
Figura 5Questeimpostazioni sono visibili anche nel pannello Utenti attivi di Office 365, nella colonna Stato della sincronizzazione(Figura 6 e Figura 7).
Figura 7
A volte è possibile trasferire l'origine dell'autorità di un account utente gestito nel cloud. Ad esempio, supponiamo che un account utente sia stato creato direttamente da Office 365, il che rende l'utente gestito nel cloud. Ma si desidera gestire l'utente tramite AD on-prem, come gli altri utenti.
A tal fine, è possibile utilizzare la sincronizzazione della directory. Questo metodo utilizza la corrispondenza SMTP per sincronizzare l'account utente di Office 365 con un account utente on-prem, in base all'attributo proxyAddress.
Per sincronizzare gli account utilizzando la corrispondenza SMTP, sono necessari due passaggi:
- Creare un account AD con lo stesso userPrincipalName dell'account Azure AD.
- Configurare l'attributo proxyAddress in modo che corrisponda al proxyAddress dell'utente di Azure AD.
La Figura 8 mostra le proprietà dell'utente Lee Gu in AD on-prem. Qui si crea l'utente e gli si assegnano gli stessi proxyAddress e userPrincipalName dell'utente Lee Gu gestito nel cloud.
La Figura 9 mostra le proprietà dell'utente Lee Gu su Azure AD.
Se Azure AD Connect trova un oggetto in Azure AD con gli attributi userPrincipalName e proxyAddress corrispondenti, si verifica la corrispondenza SMTP. Se la sincronizzazione dell'hash della password è configurata, come di default, questo processo sovrascrive la password esistente per l'account Azure AD con la password dell'account on-prem.
Note importanti sul processo di abbinamento SMTP:
- L'utente AD deve essere nuovamente sincronizzato.
- Dirk-jan ha scoperto che se l'utente Azure AD è un utente attivo con privilegi elevati, la sincronizzazione non funziona. Ad esempio, non è possibile sincronizzare un utente on-premise con un utente Azure AD amministratore globale attivo. (Questo problema è stato risolto dopo che Dirk-jan lo ha scoperto).
- Se l'userPrincipalName dell'utente on-prem non corrisponde all'utente nel cloud, viene creato un nuovo utente nel cloud. Questo utente è sincronizzato con l'utente on-prem e ha un indirizzo e-mail Office 365 valido, determinato dall'attributo userPrincipalName anziché dal proxyAddress.
Ad esempio, se si tenta di sincronizzare l'utente Megan Bowen utilizzando l'attributo proxyAddress ma un userPrincipalName diverso, il risultato è un nuovo utente Azure AD, anche se non si dispone di alcun accesso o autorizzazione su Azure AD(Figura 10).
Se si crea un nuovo utente on-premise con lo stesso attributo proxyAddress ma con un userPrincipalName diverso(Figura 11), si ottengono due oggetti utente denominati Megan Bowen, ciascuno con un userPrincipalName diverso. L'oggetto più recente è sincronizzato e l'oggetto originale è gestito nel cloud da Azure AD(Figura 12).
Figura 12
È possibile accedere con il nuovo account utente cloud e la password on-premise e configurare l'MFA (Figura 13).
Come la corrispondenza SMTP può portare ad abusi
Il team di ricerca Semperis ha scoperto che è possibile utilizzare la corrispondenza SMTP per sincronizzare gli utenti on-premise con gli utenti di Azure AD idonei per i ruoli amministrativi. Gli aggressori che hanno ottenuto l'accesso on-prem possono utilizzare questo approccio per compromettere Azure AD.
Il processo di abbinamento SMTP funziona per gli utenti con privilegi elevati che sono idonei per un privilegio che non è stato attivato. L'abuso è possibile sia che il ruolo amministrativo sia stato reso idoneo direttamente all'utente, sia che sia stato attivato da un gruppo Azure.
Per abusare del matching SMTP, l'MFA deve essere inutilizzato oppure l'attivazione del ruolo non deve richiedere una verifica MFA. Abbiamo creato un elenco di tutti i ruoli ad alto privilegio che non richiedono la verifica MFA per l'attivazione del ruolo(Tabella 1).
Tabella 1. Ruoli ad alto privilegio e requisiti di verifica MFA
| Richiedere l'AMF | Non richiede l'MFA |
| Amministratore della protezione delle informazioni di Azure Amministratore di fatturazione Amministratore di applicazioni cloud Amministratore della conformità Amministratore accesso condizionato Approvare l'accesso alla LockBox del cliente Scrittori di directory Amministratore Dynamics 365 Amministratore di Exchange Amministratore globale Amministratore Intune Assistenza partner di livello 1 Assistenza partner di livello 2 Amministratore Power BI Amministratore di ruoli privilegiati Amministratore della sicurezza Amministratore SharePoint Amministratore di Skype for Business Amministratore utente |
Utente ospite Utente ospite limitato Invitatore ospite Amministratore Helpdesk Amministratore del servizio di assistenza Utente Lettori della directory Utenti del dispositivo Azure AD Dispositivo unito Amministratore locale Adesione al dispositivo Adesione al dispositivo del luogo di lavoro Account di sincronizzazione della directory Gestori di dispositivi Amministratore dell'applicazione Sviluppatore di applicazioni Lettore di sicurezza Lettore di rapporti Lettore del centro messaggi Amministratore Desktop Analytics Amministratore di licenze Amministratore dispositivi cloud Amministratore dell'autenticazione Amministratore di autenticazione privilegiata Amministratore comunicazioni Teams Ingegnere di supporto per le comunicazioni di Teams Specialista dell'assistenza per le comunicazioni di team Amministratore di team Amministratore Insights Lettore della privacy del centro messaggi Amministratore del flusso di utenti con ID esterno Amministratore del flusso di utenti con ID esterno Amministratore Keyset B2C IEF Amministratore dei criteri IEF B2C Amministratore di Identity Provider esterni Amministratore dei dati di conformità Operatore della sicurezza Amministratore Kaizala Lettore globale Amministratore di ricerca Editor di ricerca Amministratore password Amministratore della stampante Tecnico della stampante Amministratore dei criteri di autenticazione Amministratore gruppi Amministratore di Power Platform Amministratore DevOps Azure Amministratore di identità ibride Amministratore di Office Apps Amministratore di rete Leader aziendale Insights Amministratore di dispositivi di team Amministratore di simulazione di attacco Autore di payload di attacco Rapporti di riepilogo sull'uso Lettore Amministratore della conoscenza Gestore delle conoscenze Amministratore del nome di dominio Amministratore definizione attributi Amministratore dell'assegnazione degli attributi Lettore della definizione di attributo Lettore dell'assegnazione degli attributi Amministratore destinatario di Exchange Amministratore della governance dell'identità Amministratore sicurezza app cloud Amministratore distribuzione Windows Update Amministratore Windows 365 Amministratore Edge Amministratore visite virtuali Analista di approfondimenti |
Ad esempio, supponiamo che l'utente gestito dal cloud Lidia Holloway sia idoneo al ruolo di Amministratore globale(Figura 14).
Si utilizza la corrispondenza SMTP per sincronizzare questo utente con un nuovo utente on-premise(Figura 15).
Dopo aver utilizzato la password on-premise di Lidia per accedere ad Azure AD, è possibile attivare il ruolo di amministratore globale(Figura 16). Per farlo, è necessario utilizzare l'MFA ("Verifica aggiuntiva richiesta"). Se l'utente cloud originale non richiedeva l'MFA, è sufficiente configurarlo e poi attivare il ruolo (Figura 17).
Figura 17
È possibile attivare un ruolo che non richiede la verifica aggiuntiva MFA ma che può essere elevato ad Amministratore globale, ad esempio Amministratore di applicazioni. Come descritto da Dirk-jan, questo ruolo può essere elevato direttamente al ruolo di Amministratore globale.
Utilizzo di Semperis DSP per rilevare questa vulnerabilità di Azure AD
Semperis Directory Services Protector ( DSP) raccoglie i dati di modifica di Azure AD. Per rilevare un tentativo di sfruttare questa vulnerabilità, DSP cerca lo schema di attacco specifico, che comprende la sincronizzazione di un utente AD con un utente Azure AD idoneo per un ruolo ad alto privilegio, seguita dall'attivazione di tale ruolo. DSP security indicator (SI) "Azure AD Role activation after synchronization" identifica questo schema. DSP identifica anche l'indicatore di sicurezza "Utente AAD idoneo per un ruolo ad alto privilegio non sincronizzato con AD", che indica gli utenti Azure AD idonei per un ruolo ad alto privilegio e dotati dell'attributo proxyAddress, ma non sincronizzati con un account on-premises, rendendoli vulnerabili a questo attacco.
Altri rilevamenti di abusi di corrispondenza SMTP
Un'altra opzione è quella di utilizzare i registri di audit di Azure per cercare qualsiasi sincronizzazione e attivazione di ruoli nel vostro ambiente(Figura 18).
In questo esempio, si può notare che il nome del client dell'azione è "DirectorySync" e che il vecchio valore per LastDirSyncTime è vuoto. Queste informazioni indicano che è la prima volta che l'utente si sincronizza con AD on-prem.
Il seguente log mostra l'attivazione del ruolo(Figura 19). Utilizzando l'attributo RoleDefinitionOriginId, è possibile cercare il ruolo attivato.
Correzione dell'abuso di corrispondenza SMTP
Per evitare questo exploit, Microsoft consiglia di richiedere l'MFA per tutti gli utenti ("Harden your Azure AD Connect server"). La mitigazione si ottiene assicurandosi che gli utenti abbiano l'MFA configurato prima di concedere loro un ruolo idoneo. È inoltre possibile disattivare l'opzione di utilizzo della corrispondenza morbida per la sincronizzazione.
Divulgazione
Questo problema è stato segnalato tramite il Microsoft Security Response Center (MSRC) il 10 giugno 2022. Microsoft ha risposto il 13 luglio: "[In base alla nostra valutazione, esistono controlli mitigativi che un utente può utilizzare per evitare questa vulnerabilità". Abbiamo stabilito che il comportamento è stato progettato".
Per saperne di più
Per saperne di più sulla protezione dell'organizzazione dalle vulnerabilità di AD e Azure AD, consultare le seguenti risorse:
