Azure AD Mailbag: scoprire e bloccare l’autenticazione legacy

Molte volte ci troviamo nella situazione in cui dobbiamo aiutare i nostri clienti ad evitare attacchi alle loro password e la legacy authentication è un componente chiave dell’argomento. Questo perchè questi protocolli e client sono comunemente utilizzati per effettuare attacchi di tipo brute-force o password spray.
In questo post, andremo a vedere quali sono le sfide dell’autenticazione legacy e come utilizzare Azure AD e Microsoft Exchange Online per avere un miglior controllo dell’accesso.
Affronteremo questi argomenti con un approccio di tipo domanda e risposta.

 

1. Cos’è l’autenticazione legacy e quali sono i problemi che si riscontrano?

 

Parlando in linea generica l’autenticazione legacy si riferisce ai protocolli che utilizzano un’autenticazione base (Basic Auth).
Si tratta cioè di quei protocolli che richiedono un singolo fattore di autenticazione di username e password e tipicamente non possono applicare un secondo fattore quale componente del flusso di autenticazione.
Al lato opposto, troviamo la modern authentication (Modern Auth) che può invece richiedere un secondo fattore di autenticazione. In questo caso, solitamente l’app o il servizio in questione mostrano un frame del browser che permette all’utente di fornire quanto richiesto come secondo fattore.
Può trattarsi di un codice temporaneo, l’approvazione di una notifica push sul telefono o la risposta ad una chiamata in arrivo.

Altra differenza fondamentale è che in un percorso di autenticazione legacy, l’app client o servizio raccoglie le credenziali ed in seguito le convalida.
Essenzialmente, l’app o servizio “ottiene la fiducia” per gestire le credenziali in maniera sicura.
Nella modern authentication, le credenziali sono sempre es solo fornite ad un’autorità di fiducia (ad esempio un redirect ad Azure AD o AD Federation Services) e, dopo l’autenticazione, viene rilasciato un token per l’applicazione o un servizio che agisce per conto dell’utente.

Esempi di protocollo che usano l’autenticazione legacy sono POP3, IMAP4, e SMTP.
Ci sono altri protocolli che utilizzano Basic Auth e Modern Auth quali MAPI e EWS.

Quindi, dove sta il problema?

La single factor authentication oggigiorno non è sufficiente per rimanere al sicuro!
Le password sono deboli perchè semplici da indovinare, le persone non impiegano molto sforzo nella scelta di combinazioni più complicate e tendono a fornirle agli hacker attraverso gli attacchi (ad esempio il phishing). Una delle cose più semplici da fare per proteggerci dalle minacce alle password è implementare la multi-factor authentication (MFA).
In questo modo, anche se un aggressore dovesse impossessarsi della password di un utente, questa da sola non basterà per autenticarsi con successo ed avere accesso a dati e risorse.

I protocolli che utilizzano la legacy authentication, in particolare quelli utilizzati per recuperare email quali POP3, IMAP e EWS sono modi molto semplici per attuare attacchi di tipo brute-force e password spray perchè se una delle combinazioni di username e password tentate è corretta, l’aggressore avrà accesso alle email dell’utente.

 

2. Quindi cosa facciamo con questi protocolli?

 

La raccomandazione è di bloccare l’autenticazione legacy, o se avete dei casi particolari in azienda per cui dovete permetterne l’utilizzo, applicate alcuni controlli che ne permettano per specifici utenti e location.
Prima di farlo, cercate di capire quale sia il loro utilizzo nell’organizzazione.

Lo scorso anno, Microsoft ha fatto alcuni miglioramenti ai log di sign-in in Azure AD: ora ricevete le attività più velocemente e recuperate maggiori informazioni per ognievent.
Parte di questa informazione è la Client App property, dove venite informati sul procotollo/app utilizzati per effettuare il sign-in.

Azure Active Directory

La prima cosa che dovete fare è impegnare del tempo ad analizzare i log per comprendere l’utilizzo di questi client e dei protocolli in tutta l’azienda.
Per farlo, potreste scaricare i log per suddividerli ed analizzarli con Microsoft Excel o, ancora meglio, inserirli all’interno del vostro sistema di security information and event management (SIEM) che vi fornisce sicuramente funzionalità di analisi dati e alert più potenti.
Per capire come immettere i log nel SIEM, date un’occhiata a questo post: Azure AD Mailbag: Return Of The Mailbag with Azure AD Logs.
Una volta compreso chi sta usando cosa, potreste aver bisogno di aggiornare i client alle versioni che supportano la Modern Auth o convincere gli utenti a smettere di utilizzare protocolli come IMAP4 ed aggiornarsi a tecnologie più attuali.

 

3. Ok, siamo pronti ad imporre maggior controllo. Come facciamo?

 

Fino all’anno scorso, vi erano due modi di bloccare l’autenticazione legacy in Azure AD.

In ambienti federate (che utilizzano ad esempio AD FS), potreste utilizzare regole specifiche che permettano determinati protocolli e neghino l’accesso ai rimanenti.
Il tutto si complica quando dovete iniziare ad aggiungere condizioni ed eccezioni.

Implementare la MFA per utente, costringerà gli utenti ad utilizzare le password delle app per i protocolli di legacy authentication. In ogni caso, se non ne permettete l’utilizzo, bloccate
in toto questi protocolli. La cattiva notizia qui è che non potete applicare soltanto alcune condizioni: o tutte o nessuna. Inoltre, applicare la MFA per utente, non è il metodo migliore da utilizzare al giorno d’oggi: il conditional access vi dà maggiore flessibilità.
Lo scorso anno, Microsoft ha aggiunto la possibilità di bloccare l’autenticazione legacy nel conditional access e per questo vi raccomandiamo di iniziare da qui.
Con il conditional access, guadagnerete la flessibilità necessaria a supportare gli utenti o le app che hanno ancora bisogno di utilizzare i protocolli con la legacy authentication e bloccarne gli altri.

Ad esempio, se avete un’app che supporta un processo di business che utilizza l’IMAP per recuperare le email da una casella di posta di Exchange Online, potete utilizzare il conditional access per permettere quel flow soltanto per quello specifico utente se la sorgente IP è uno dei vostri IP e bloccare qualsiasi altro tentativo.
Vi rimandiamo all’articolo Block legacy authentication to Azure AD with conditional access per saperne di più.

Azure Active Directory

Quello che ha creato un po’ di confusione è stato che le policy di conditional access non includono la legacy authentication dei client di default.
Questo significa che se avete una policy di conditional access che applica l’MFA per tutti gli utenti e le app cloud, non verrà bloccata l’autenticazione legacy dei client (o di “Other clients” considerato che la CA UI si riferisce a quelli). La legacy authentication dei client può ancora operare l’autenticazione soltanto con username e password. Per bloccare, create semplicemente una nuova policy.

Un altro modo per bloccare l’autenticazione legacy è impedendola dal lato service-side o resource-side (vs piattaforma di autentificazione).
Raccomandiamo quest’approccio se combinato con le policy di Azure AD Conditional Access. Ad esempio, in MS Exchange Online, potete disabilitare il POP3 o l’IMAP per l’utente. Il problema di questa disabilitazione è che non volete bloccare i protocolli che possono effettuare sia la legacy che la modern authentication (come EWS, MAPI) perchè vi servono.
Per risolvere l’inghippo, Exchange Online ha rilasciato una nuova funzionalità chiamata authentication policies che può essere utilizzata per bloccare le autenticazioni legacy per protocollo dello specifico utente o per l’intera organizzazione.
Ci piace questa caratteristica perchè, con questo approccio, state bloccando i tentativi di utilizzo del protocollo a monte, il che significa che gli aggressori non tenteranno nemmeno di indovinare le password. La connessione al protocollo è negata ancor prima del controllo delle credenziali su Azure AD o gli AD Federation Services quindi l’esecuzione viene fatta pre-autenticazione.
Le policy di conditional access sono invece valutate dopo che l’utente (o l’aggressore) ha effettuato l’autenticazione quindi l’enforcement è eseguito post-autenticazione.

Per maggiori informazioni: Disable Basic authentication in Exchange Online.

 

 

Le informazioni presenti in questo post, sono prese dall’articolo: Azure AD Mailbag: Discovering and blocking legacy authentication.

 

Contattaci

La tua crescita parte da qui
Per maggiori informazioni

Contattaci

    Iscriviti alla newsletter

      Tematiche d'interesse