È stato rilasciato su GitHub un Proof-of-Concept (PoC) che sfrutta tecniche di password spraying attacks per scoprire credenziali di account in domini basati su Microsoft Azure Active Directory.
L’exploit (che sfrutta un’anomalia scoperta da ricercatori dell’azienda Secureworks) consente a chiunque di eseguire sia l’enumerazione degli account utente sia attacchi a forza bruta delle password sui server di Azure vulnerabili.
Sebbene Microsoft avesse inizialmente definito il meccanismo di Autologon una scelta di design, l’azienda sta lavorando in questi giorni ad una software remediation.
Indice degli argomenti
Bug in Azure Active Directory: excursus dell’anomalia
Alla fine di giugno 2021 i ricercatori di Secureworks hanno identificato un’anomalia nel protocollo utilizzato dalla funzionalità SSO (Single Sign-On) di Azure Active Directory. Quest’anomalia consente ad un attacker di sferrare attacchi a forza bruta a singolo fattore contro un servizio Active Directory basato su Azure, senza che vengano tracciati gli eventi di accesso nel relativo tenant.
Perché costituisce un’anomalia importante e ne stiamo parlando? Perché in tale scenario IDS e IPS (consultati dagli analisti cyber) non riceverebbero le relative tracce (ossia precisi eventi annegati in file di log, log che generalmente alimentano SIEM e SOAR) di eventuali accessi abusivi all’AD di Azure.
I ricercatori avevano segnalato il bug a Microsoft il 29 giugno scorso. Microsoft ne aveva preso ufficialmente atto il 21 luglio, ma stabilendo che trattavasi di un’anomalia “by design” e quindi senza confermare la presenza di possibili errori commessi in fase di progettazione. Di conseguenza, non era chiaro se o quando il bug sarebbe stato corretto. Nel frattempo, le organizzazioni sono vulnerabili a furtivi attacchi a forza bruta.
Lo sfruttamento di quest’anomalia non si limita solo alle organizzazioni che utilizzano l’SSO di Azure. Gli attackers potrebbero sfruttare l’endpoint autologon usernamemixed in qualsiasi organizzazione Microsoft 365, incluse le aziende che utilizzano l’autenticazione pass-through (PTA). Gli utenti senza un account sull’AD di Azure, invece, non sono coinvolti.
La vulnerabilità rimane al momento senza patch
Come dimostrato dal PoC, sfruttare la falla è relativamente facile (come il lettore noterà, trattasi di uno script in PowerShell, peraltro di lunghezza esigua), ma in questo articolo ci concentriamo sulla remediation alla minaccia, non su di una demo della PoC, rinviando il lettore che ne fosse eventualmente a digiuno, alla consultazione della documentazione ufficiale Microsoft relativamente al funzionamento e alle funzionalità dell’AD di Azure.
Microsoft ha dichiarato che la tecnica dimostrata da Secureworks non costituisce una vulnerabilità di sicurezza e che sono già in atto misure per proteggere gli utenti di Azure: “Abbiamo esaminato la problematica e stabilito che la tecnica descritta non comporta una vulnerabilità di sicurezza, e che sono state messe in atto protezioni per garantire che i clienti rimangano al sicuro”, ha dichiarato un portavoce di Microsoft.
Dopo aver esaminato il resoconto iniziale di Secureworks, Microsoft ha concluso che le protezioni contro gli attacchi di forza bruta si applicano già agli endpoint descritti, proteggendo così gli utenti da tali attacchi.
Inoltre, afferma sempre Microsoft, “i token emessi dall’endpoint WS-Trust usernamemixed non forniscono l’accesso ai dati, e devono essere presentati nuovamente ad Azure AD per ottenere i token effettivi. Tutte queste richieste di token di accesso sono protette da accesso condizionale, Multi-Factor Authentication, Identity Protection, e sono emerse nei log di accesso”.
Tuttavia, a seguito di queste dichiarazioni, Secureworks ha condiviso ulteriori approfondimenti ricevuti da Microsoft, indicando che l’azienda di Redmond sta lavorando a una soluzione.
“In primo luogo, il logon sarà tracciato nei log di accesso di Azure AD. In secondo luogo, alle organizzazioni verrà data un’opzione per abilitare o disabilitare l’endpoint in questione. Dovrebbero essere disponibili per le organizzazioni nelle prossime due settimane”, ha detto Nestori Syynimaa, Senior Principal Security Researcher at Secureworks.
In che modo proteggersi
Un primo consiglio, quando sarà possibile grazie agli aggiornamenti di Microsoft, è quello di disabilitare l’autologon dell’usernamemixed endpoint.
Nel frattempo (ma anche in futuro) un altro suggerimento è quello di fare tuning su “Smart Lockout”, una funzionalità di Azure pensata per bloccare automaticamente per un determinato periodo di tempo account oggetto di bruteforcing, se vengono appunto rilevati “troppi” tentativi (in base ad un pattern) di accesso.
Quando un account viene posto in stato “Locked”, tuttavia, il messaggio di errore sarà sempre “bloccato”, indipendentemente dal fatto che la password sia o meno corretta ed effettivamente inserita dal vero utente o servizio proprietario dell’account.
In quanto tale, la funzione sembra effettivamente bloccare un attacco a forza bruta, tuttavia è doveroso segnalare al lettore che a fronte di attacchi basati su password spraying in cui più account sono presi di mira con poche password, occorrerà customizzare il modulo di detection per non avere brutte sorprese (Smart Lockout potrebbe non intervenire tempestivamente a lungo termine, ossia, l’attacker potrebbe riuscire ad ingannare il default pattern configurato sulla piattaforma).
Un consiglio è quello di regolare il numero di autenticazioni non riuscite prima che Smart Lockout si attivi e blocchi gli account. Ad esempio, impostare la soglia (threshold) di logon fallite su di un valore basso è indubbiamente prudenziale, ma può anche bloccare gli account troppo facilmente durante il normale utilizzo quotidiano.
La regolazione del tempo di lockout è un’altra opzione interessante.
Altro consiglio, per quelle organizzazioni o aziende che (alle soglie del 2022) ancora non avessero imposto l’utilizzo di MFA (multi-factor authentication) per l’autenticazione in SSO dei propri utenti e servizi su Azure AD, questo può essere il momento giusto per farlo (chi ci garantisce che in futuro non spunteranno analoghe anomalie di tracciamento che si sarebbero potute “mitigare preventivamente” con una buona policy di autenticazione basata su 2FA/MFA?).
Il consiglio è quello di approfittarne subito prima che lo facciano i distributori e produttori di ransomware accedendo in maniera silente alla rete e iniettando software malevolo a nostra insaputa e a quella dei nostri clienti.
