• Cloud, Guide, Microsoft 365, Sicurezza
• 28 Giugno 2023

Microsoft ha di recente rilasciato in preview la Token Protection per le sessioni di Sign-in in Azure AD Conditional Access. Questa funzionalità ha lo scopo di proteggere le aziende dal furto dei token di autenticazione di Azure AD. Da quando è stata disabilitata la Basic Authentication e sono diminuiti gli attacchi di password spray, il Microsoft Detection and Response Team (DART) ha registrato un aumento degli  adversary-in-the-middle phishing attacks, che consistono nel tentativo di catturare le credenziali degli utenti e i token utilizzati dalle applicazioni per accedere a risorse come i siti di SharePoint Online oppure le caselle di posta di Exchange Online.

Quando Azure AD rilascia un token, questo contiene informazioni (claims) come lo username, l’indirizzo da cui è originata l’autenticazione, la MFA, i privilegi che ha l’utente in Azure AD, i gruppi a cui appartiene ed altro.

L’obiettivo della Token protection è quello di assicurarsi che il token sia utilizzabile solo dal dispositivo a cui è stato rilasciato (token binding). Infatti, i malintenzionati cercano di recuperare il token e di impersonare la vittima fino a quando il token non scade o viene revocato.

Figura 1: Funzionamento dei token di autenticazione in Azure AD

La Token Protection crea un legame crittografato tra il token ed il dispositivo (client secret) a cui è stato rilasciato. Senza il client secret il token è inutilizzabile.

Quando viene registrato o aggiunto un dispositivo ad Azure AD, come ben sapete al dispositivo viene associata ad un’identità primaria. Ciò significa che una policy può garantire che solo i token di accesso (o di aggiornamento) associati vengano usati dalle applicazioni quando si richiede l’accesso a una risorsa. Questi token sono i Primary Refresh Tokens (PRTs).

Un Primary Refresh Token viene protetto mediante l’associazione al dispositivo in cui l’utente ha effettuato l’accesso. Azure AD e Windows 10 o versione successiva abilitano la protezione PRT tramite i metodi seguenti:

• Durante il primo accesso: durante il primo accesso, viene rilasciato un token di aggiornamento primario firmando le richieste usando la chiave del dispositivo generata crittograficamente durante la registrazione del dispositivo. In un dispositivo con un TPM valido e funzionante, la chiave del dispositivo è protetta dal TPM che impedisce l’accesso da parte di utenti malintenzionati. Un token di aggiornamento primario non viene emesso se la firma della chiave del dispositivo corrispondente non può essere convalidata.
• Durante le richieste e il rinnovo di token: quando viene rilasciato un token di aggiornamento primario, Azure AD rilascia anche una chiave della sessione crittografata per il dispositivo. Viene crittografato con la chiave del trasporto pubblico (tkpub) generata e inviata ad Azure AD come parte della registrazione del dispositivo. Questa chiave della sessione può essere decrittografata solo tramite la chiave di trasporto privata (tkpriv) protetta dal TPM. La chiave della sessione è la chiave di dimostrazione del possesso (PoP, Proof-of-Possession) per tutte le richieste inviate ad Azure AD. Anche la chiave della sessione è protetta dal TPM e nessun altro componente del sistema operativo può accedervi. Le richieste di rinnovo del token o le richieste di rinnovo PRT vengono firmate in modo sicuro da questa chiave di sessione tramite il TPM e quindi non possono essere manomessi. Azure AD invalida le richieste dal dispositivo che non sono firmate dalla chiave di sessione corrispondente.

Attualmente questa funzionalità è in PREVIEW e ha i seguenti prerequisiti e limitazioni:

• È necessario utilizzare Windows 10 o versioni successive nei dispositivi che sono Azure AD joined, hybrid Azure AD joined oppure Azure AD registered.
• sincronizzazione OneDrive versione client 22.217 o successiva
• Client nativo di Teams versione 1.6.00.1331 o successiva
• I client Perpetui di Office non sono supportati
• Gli External Users (Azure AD B2B) non sono supportati e non devono essere inclusi nei criteri di accesso condizionale.
• I dispositivi client Windows seguenti non sono supportati:
  • Windows Server
  • Surface Hub
  • Sistemi di Microsoft Teams Rooms basati su Windows (MTR)

Maggiori informazioni sono disponibili alla pagina Token protection in Azure AD Conditional Access – Microsoft Entra | Microsoft Learn

Creazione di una policy di accesso condizionale

La creazione di una policy di accesso condizionale è effettuata dal portale di Microsoft Entra. In questo esempio creeremo una policy per proteggere l’accesso a Exchange Online e SharePoint Online, che sono le uniche due applicazioni supportate durante la preview. Presto arriverà il supporto per Microsoft Teams e per le altre applicazioni.

Dal portale Microsoft Entra admin center selezionate Azure Active Directory > Protect & Secure > Conditional
Access e fate clic su + Create new policy.

Figura 2: Creazione di una nuova policy di accesso condizionale

Selezionate gli utenti a cui volete applicare la policy e selezionate le due applicazioni Exchange Online e SharePoint Online, le uniche attualmente supportate durante la public preview.

Figura 3: Selezione delle applicazioni a cui imporre la Token Protection

Per evitare disservizi e bloccare gli accessi legittimi dalle applicazioni web oppure anche da altri sistemi operativi non supportati (attualmente sono supportati solo i dispositivi Windows 10/11 conosciuti da Azure AD), ho deciso di aggiungere delle condizioni e di costringere l’utilizzo della token protection solo dai dispositivi Windows e dalle Applicazioni mobili e desktop, lasciando disponibile la possibilità di utilizzare il browser.

Figura 4: La token protection verrà richiesta solo se ci colleghiamo da dispositivi Windows

Figura 5: : La token protection verrà richiesta solo se utilizziamo applicazioni desktop e mobili

In Session possiamo mettere il segno di spunta su Require token protection for sign-in sessions (preview).

Figura 6: Configurazione della Token protection

È preferibile come al solito testare la policy in modalità Report-only prima di forzarla in quanto la policy richiede che il sistema operativo sia compliant e che le applicazioni possano fornire la proof-of-possession.

Figura 7: Creazione della Token Protection policy

Figura 8: Creazione della Token Protection policy completata

Test di funzionamento

Se un utente si collega ad Outlook utilizzando il suo PC aziendale joinato ad Azure AD o in Hybrid Azure AD join potrà accedere senza problemi, come mostrato nella figura sotto:

Figura 9: Accesso ad Outlook da un PC aziendale associato all’utente

Se la stessa operazione viene effettuata da un PC personale, l’utente, dopo aver inserito le credenziali in Outlook, riceverà il messaggio mostrato nella figura sotto e gli verrà chiesto di registrare il dispositivo.

Figura 10: L’accesso ad Outlook dal PC personale non è consentito se prima non si effettua l’enrollment in Azure AD

Se nella policy di accesso condizionale non avete configurato la condizione Client Apps o avete lasciato selezionato Browser, alcune applicazioni che utilizzando MSAL.js come Teams Web o OWA non funzioneranno e riceveranno il messaggio mostrato nella figura sotto:

Figura 11: Messaggio di errore quando si tenta di accedere ad applicazioni web che usano MSAL.js

Ovviamente questa informazione viene riportata nei Sign-In logs, come mostrato nelle figure sotto:

Figura 12: L’utente non è riuscito ad accedere ad Exchange Online perché è stato bloccato dalla policy di accesso condizionale

Figura 13: Policy di accesso condizionale che ha impedito l’accesso da parte dell’utente

Figura 14: Dettaglio della failure di accesso

Conclusioni

Anche se la funzionalità di Token Protection for sign-in sessions è in preview solo per i dispositivi Windows 10 e Windows 11 , Microsoft ha già annunciato che verrà aggiunto il supporto per i sistemi operativi macOS, Linux, Android e iOS. La funzionalità è decisamente interessante per arginare tutte quelle tecniche di attacco basate sul furto e riutilizzo dei token di autenticazione perché il token può essere utilizzato solo ed esclusivamente all’interno del device nel quale viene generato.