Conditional Access è una delle funzioni di sicurezza più potenti di Microsoft e il motore centrale dell'architettura Zero Trust. A nostro avviso, dovrebbe essere il fondamento di qualsiasi strategia di Fiducia Zero per le organizzazioni basate su cloud. Tuttavia, se non si comprende il funzionamento dell'accesso condizionato, si potrebbe avere un falso senso di sicurezza. In questo blog post vi mostreremo perché è importante comprendere il processo di valutazione dei criteri di accesso condizionato e come trovare e sfruttare le falle nella progettazione della strategia.
Informazioni sull'accesso condizionato
L'accesso condizionato è una caratteristica di Azure AD Premium ed è disattivato per impostazione predefinita. Esiste una funzione chiamata Predefiniti di sicurezza che entra in gioco se non è configurato alcun criterio, ma non rientra nell'ambito di questo articolo. Le impostazioni predefinite di sicurezza sono sempre disattivate anche quando sono presenti uno o più criteri di accesso condizionato.
Nell'accesso condizionato, tutto è consentito per impostazione predefinita. E anche se si creano uno, due o tre criteri, tutto ciò che non viene esplicitamente bloccato è consentito.
In quasi tutti i tenant che vediamo, ci sono delle falle nella progettazione dell'accesso condizionato perché gli amministratori si concentrano troppo sui casi d'uso che vogliono consentire e non su quelli che dovrebbero essere bloccati. I criteri di accesso condizionato sono spesso progettati al contrario, lasciando il tenant vulnerabile agli attacchi.
Password e accesso condizionato
È importante capire che i criteri di accesso condizionato in Azure AD vengono valutati dopo l'approvazione del primo fattore, la password dell'utente. In questo articolo non mi soffermerò sulle tecniche di furto della password e tutto ciò che spiegherò qui avviene dopo che la password è stata verificata con successo da Azure AD (o daAD in loco con PTA o ADFS). È dopo il primo fattore che vengono valutate le politiche di accesso condizionato e all'utente viene concesso o negato l'accesso in base ai requisiti delle politiche mirate.
Funzionamento di diverse strategie di accesso condizionato
Nell'accesso condizionato, tutte le strategie vengono valutate a ogni connessione. Questo vale anche quando sono soddisfatti i requisiti di ciascuna politica. La somma di tutti i requisiti di tutti i criteri di corrispondenza è ciò che l'utente e il dispositivo devono soddisfare per ottenere l'accesso. Ad esempio, una politica di corrispondenza può richiedere l'autenticazione a più fattori e un'altra può richiedere che il dispositivo sia conforme a Intune. Poiché le due politiche coincidono, entrambi i requisiti devono essere soddisfatti.
L'unica priorità tra le politiche è che le politiche di blocco vincono sempre. Ciò significa che se uno o più criteri di blocco coincidono durante una connessione, il tentativo di autenticazione viene bloccato, anche se altri criteri consentono l'accesso nello stesso momento.
Alcuni punti deboli comuni
Naturalmente, il modo migliore per affrontare l'accesso condizionato è non attivarlo mai, per evitarlo. In quasi tutte le organizzazioni esistono punti deboli comuni che possono essere abusati.
Abuso del gruppo di esclusione
Si consiglia di escludere sempre un gruppo di sicurezza da tutti i criteri di accesso condizionato. Questo gruppo dovrebbe contenere due "Conti di rottura del vetro" da utilizzare in caso di emergenza. Questo gruppo non dovrebbe includere altri conti, ma in realtà lo fa quasi sempre. Gli amministratori si fanno prendere la mano e aggiungono a questo gruppo se stessi, gli account di servizio o gli utenti che si lamentano. Rubando la password di uno di questi account, possiamo ignorare l'accesso condizionato.
Strategie di blocco mancanti
Gli amministratori tendono a creare criteri per imporre l'autenticazione a più fattori per alcune o tutte le applicazioni di un cliente. Ma spesso includono condizioni in queste politiche, come le piattaforme o i luoghi consentiti. Quello che non capiscono è che se non blocchiamo gli scenari indesiderati con un criterio di blocco corrispondente, un aggressore può semplicemente fare uno spoofing della posizione o della piattaforma per aggirare il criterio e connettersi direttamente. Questo è in gran parte ciò che verrà trattato nel resto di questa guida.
Questo è il messaggio di errore generale che un utente riceve quando l'accesso è negato da un criterio di blocco. Si noti che il messaggio di errore di blocco può variare a seconda delle condizioni della strategia di blocco. Questo serve per aiutare l'utente a capire cosa è andato storto (vedere le singole condizioni di seguito).
Utilizzare la sezione Altre informazioni per vedere se ci sono indizi sulla condizione che ha innescato il blocco, come la posizione dell'indirizzo IP, lo stato di gestione del dispositivo o l'applicazione interessata.
Abuso di condizione
Le condizioni vengono utilizzate per determinare se una politica debba essere applicata o meno. Se tutte le condizioni sono soddisfatte al momento dell'accesso, vengono applicati i controlli di accesso per quel criterio, come la richiesta di un'autenticazione a più fattori o la richiesta di un dispositivo conforme. Di seguito sono riportati alcuni esempi di come ogni tipo di condizione può essere ingannata.
Rischio per l'utente / Rischio per la connessione
Il rischio utente e il rischio di accesso fanno parte di Azure AD Identity Protection (Azure AD Premium P2). Ciò significa che la maggior parte dei client di Microsoft 365 non lo ha abilitato e non sarà un problema per un aggressore. Tuttavia, se è abilitata, l'attaccante deve cercare di comportarsi come l'utente che possiede l'account rubato usato nell'attacco. Azure AD La protezione dell'identità rileva le connessioni da nuovi Paesi, gli indirizzi IP anonimi, le credenziali trapelate contrassegnate in nero, ecc. Un aggressore dovrebbe ricercare l'utente, quindi utilizzare VPN e altre tecniche per far apparire la connessione il più legittima possibile.
Questo è ciò che si vede se una strategia di blocco viene attivata da questa condizione:
Piattaforme di dispositivi
La piattaforma del dispositivo è facile da falsificare. Si basa sulla stringa dell'agente utente delle applicazioni client. Se un criterio include la condizione di piattaforma che richiede Windows, iOS o Android, si può semplicemente sostituire la stringa dell'agente utente con qualsiasi altra cosa, come un dispositivo Mac, un dispositivo Linux o una stazione spaziale. Si tratta semplicemente di una stringa di testo che l'Accesso condizionato interpreta per cercare il sistema operativo. Si consiglia di adottare una politica di blocco che blocchi tutte le piattaforme indesiderate.
Ecco come modificare la stringa dell'agente utente con gli strumenti per gli sviluppatori di Microsoft Edge:
Questo è ciò che si vede se una strategia di blocco viene attivata da questa condizione:
Luoghi
La condizione di localizzazione si basa sull'indirizzo IP. Queste sono chiamate località denominate in Azure AD e possono essere impostate su determinati intervalli di indirizzi IP o Paesi. Se esiste una politica che blocca determinati Paesi, un aggressore può facilmente aggirarla con un servizio VPN che termina nello stesso Paese dell'organizzazione. Se esiste una politica che consente solo indirizzi IP particolari, come l'indirizzo IP pubblico dell'azienda, la questione diventa un po' più complicata. Se l'aggressore ha già un punto d'appoggio nella rete interna, questo gli permetterebbe di aggirare il problema. Dato che oggi la maggior parte degli attacchi proviene dall'On-Premise, questo è molto probabile.
Questo è ciò che si vede se una strategia di blocco viene attivata da questa condizione:
Applicazioni client
Le applicazioni client significano protocolli. Quale protocollo utilizza il client quando si autentica aAzure AD . Molte organizzazioni stanno iniziando a bloccare i protocolli legacy come POP3, IMAP e SMTP bloccando Other e ActiveSync con Conditional Access. Ma ci sono quasi sempre dei punti deboli, come account esclusi, "Break Glass Account", ruoli di amministratore esclusi, ecc. Testate diversi protocolli per vedere se il tentativo viene bloccato. Questo può aiutare a capire cosa è consentito nella progettazione del criterio.
L'autenticazione moderna può essere bloccata da dispositivi non gestiti e in questo caso si può tentare di accedere a un dispositivo aziendale (se il sito è stato compromesso) oppure si può provare con uno strumento come AAD Internals che include la possibilità di aggiungere un falso dispositivo conforme a Azure AD e, se necessario, concedere il client di destinazione. Potreste essere fortunati se riusciste a sferrare un attacco di questo tipo.
L'accesso al browser non viene quasi mai bloccato da nessuno, quindi i portali del browser sono probabilmente la vostra strada.
Questo è ciò che si vede se una strategia di blocco viene attivata da questa condizione:
Stato del dispositivo
La condizione di stato del dispositivo non è applicabile in quanto esclude e include sempre e solo i dispositivi.
Abuso del controllo degli accessi
Se siete fortunati, siete riusciti a bypassare tutte le condizioni implementate sopra. In questo caso, l'utente ha già effettuato l'accesso e non ha bisogno di leggere oltre. Ma se ci sono politiche ostinate che ostacolano il percorso, il passo successivo sarebbe quello di abusare dei controlli di accesso. È più difficile e richiede un po' più di lavoro.
Quando tutte le condizioni di un criterio corrispondono, devono essere soddisfatti i requisiti in Controlli di accesso di quel criterio, altrimenti il tentativo di autenticazione viene bloccato. Un criterio può avere uno o più requisiti e il criterio può essere impostato in modo da richiedere il rispetto di uno o tutti i requisiti. Come accennato in precedenza, più polizze possono essere abbinate contemporaneamente e richiedere controlli diversi. In questo caso, devono essere soddisfatti tutti i diversi requisiti delle strategie.
Richiedere l'autenticazione a più fattori
È il controllo di accesso di gran lunga più utilizzato. Richiede all'utente di verificare la propria identità con l'autenticazione a più fattori. Esistono molti attacchi noti a MFA , come il furto di token MFA, l'abuso di telecomunicazioni (trasferimento di SMS OTP) e varie tecniche di phishing per ingannare l'utente e indurlo ad approvare il sistema. MFA. Un aggressore dovrebbe riuscire a eseguire una di queste tecniche di attacco per ottenere l'accesso. Si noti che il controllo di accesso MFA si attiva sempre quando viene attivato, anche se uno degli altri controlli di accesso si applica ma non funziona. Questi messaggi di errore vengono visualizzati dopo il controllo di MFA. Questo per proteggere l'inquilino da attacchi di fuzzing ad accesso condizionato.
Quando si vede questo, si sa di essere bersaglio di questo controllo degli accessi:
Richiedere un dispositivo ibrido collegato a Azure AD
Questa condizione richiede un tenant ibrido con dispositivi sincronizzati in loco. Quando si visualizza questo messaggio, si sa che il client è ibrido. Per aggirare questo requisito, è possibile eseguire l'attacco in loco. Un dispositivo on-premises è probabilmente già collegato a Azure AD hybrid. Si noti che questo messaggio di errore di controllo degli accessi appare sempre prima del messaggio di errore di conformità Intune se entrambi sono abilitati.
Quando si vede questo, si sa di essere bersaglio di questo controllo degli accessi:
Richiedere che l'apparecchio sia contrassegnato come conforme
Se il dispositivo deve essere conforme ai criteri Intune, ci sono due modi per farlo. Si può utilizzare un dispositivo aziendale compromesso registrato conIntune ed eseguire l'attacco da lì, oppure si può provare a registrare un dispositivo falso con uno strumento come AAD Internals per accedervi. Si noti che se si ottiene questo messaggio di errore quando si tenta di connettersi da un dispositivo non gestito, non esiste alcun criterio che richieda la giunzione ibrida Azure AD .
Quando si vede questo, si sa di essere bersaglio di questo controllo degli accessi:
Richiedono una domanda approvata dal cliente
Questo controllo degli accessi è solo per iOS e Android e non funziona con altre piattaforme. Assicura che l'utente effettui l'accesso con un'applicazione Microsoft approvata dall'App Store. Per ovviare a questo problema, utilizzare Windows o Linux.
Richiedere una strategia di protezione delle applicazioni
Ciò richiede la protezione dell'applicazione Intune. Questo può essere applicato solo ad Android e iOS, per cui un attaccante può semplicemente utilizzare Windows o Linux.