Panoramica

Recentemente, Varonis ricercatore Eric Saraga pubblicato un post sul blog che annuncia un nuovo attacco contro Azure Active Directory (Azure AD), che può consentire a un utente malintenzionato di accedere come qualsiasi utente sincronizzato. Il metodo di attacco sfrutta una falla nel metodo di verifica della password Pass-Through Authentication (PTA) che consente agli utenti di utilizzare le proprie credenziali Active Directory locali per accedere ad Azure e Office 365.

PTA è un meccanismo disponibile per le organizzazioni per consentire agli utenti di utilizzare la propria Active Directory locale (noto anche come Active Directory Directory Services, o “AD DS” e da non confondere con Azure AD, che è il servizio di directory basato su cloud di Microsoft-chiaro come mud?)

PTA passa semplicemente il nome utente e la password dell’utente e lo trasmette in modo sicuro all’AD DS locale dell’organizzazione per la verifica. Gli altri due metodi disponibili sono:

  • Sincronizzazione hash password: questo metodo sincronizza gli hash delle password dall’ANNUNCIO locale in Azure AD (per inciso, questo metodo non è raccomandato da Assura).
  • Federazione tramite Active Directory Federation Services (ADFS): Questo metodo si basa sulla funzione SAML (Security Assertion Markup Language) di Microsoft disponibile in Microsoft Windows Server.

PTA è facilitato tramite Microsoft Azure AD Connect che facilita un sacco di servizi, tra cui la sincronizzazione di utenti e gruppi da on-prem AD in Azure AD/Office 365. Ovviamente, con un solo server on-prem che facilita il PTA, questo presenta alle organizzazioni un singolo punto di errore che, se offline, impedirebbe agli utenti di accedere ai servizi Azure e Office 365. Quindi, per risolvere questo problema, Microsoft ha sviluppato un agente standalone che può essere eseguito su un server diverso e creare un meccanismo di autenticazione ad alta disponibilità per PTA.

Per essere chiari, l’attacco non sfrutta una debolezza nella PTA stessa, sfrutta una debolezza nel modo in cui l’agente fa le sue cose. Tuttavia, e per essere chiari, il server che esegue l’agente deve essere compromesso prima per l’attacco contro l’agente può avere successo. Pertanto, un utente malintenzionato deve accedere alla rete locale o deve sfruttare una macchina locale in remoto e pivot all’agente tramite l’host compromesso. L’attaccante deve anche ottenere privilegi amministrativi per il server che ospita l’agente.

Dopo che un utente malintenzionato compromette con successo un server che esegue Azure agent, manipola il flusso di autenticazione agganciando la funzione API LogonUserW. Dopo che l’attaccante si aggancia correttamente alla funzione API, può compromettere le password degli utenti sincronizzati che si connettono ad Azure AD / Office 365. Varonis ha fatto un ulteriore passo avanti e automatizzato la raccolta di credenziali tramite l’iniezione di una DLL personalizzata (Dynamic Link Library) nel flusso di processo che ancora autenticare l’utente, ma in aggiunta, scrive il nome utente e la password dell’individuo in un file di testo specificato. Mentre questo dà all’attaccante molti modi per autenticarsi, ma non fornisce la “chiave di scheletro.”Per raggiungere questo obiettivo abbiamo bisogno di più.

La modifica del valore restituito nella funzione API, LogonUserW, per accettare qualsiasi password come corretta per qualsiasi utente è la chiave per trasformare questo attacco in un attacco chiave scheletro. LogonUserW è una funzione booleana che richiede la popolazione del token dell’utente. Se quel token restituisce un valore true, l’autenticazione ha esito positivo. Il processo utilizzato dall’agente Azure per autenticare gli utenti ha il proprio token e la funzione API LogonUserW viene chiamata all’interno di tale processo, quindi i ricercatori di Varonis si sono chiesti: “Perché non utilizzare il token del processo agent?”E voilà, è stata creata la chiave di scheletro di Azure AD: il token del processo consentirà a un utente malintenzionato di accedere come utente, incluso un account amministratore globale.

I dettagli cruenti possono essere trovati nel post di Saraga qui: https://blogvaronis2.wpengine.com/azure-skeleton-key/

Punta di cappello al nostro amico Steven Rennard a Varonis per averci avvisato di questa ricerca.

Assura’s Take

Mentre questo è certamente un attacco ad alto impatto sembra dalla comunicazione di Varonis con Microsoft che non ci sono piani per correggere questa vulnerabilità in qualunque momento presto. Pertanto, diventa ancora più importante garantire che l’ambiente e gli utenti siano completamente protetti attraverso pratiche di configurazione sicure e moderne tecnologie di sicurezza.

Rilevare un utente malintenzionato che entra nella rete tramite una tecnologia IDS/IPS o SIEM, limitare la capacità dell’utente malintenzionato di aumentare i privilegi o pivot tramite uno strumento di rilevamento e risposta degli endpoint e prevenire questo attacco a chiave scheletrica tramite l’implementazione della tecnologia MFA (Multi-Factor Authentication) sono tutte opzioni praticabili e pratiche per mitigare questa minaccia.

Se sei un SIEM gestito da Assura, Managed Endpoint Protection o Managed Multi-Factor Authentication client, stiamo attivamente adottando misure per proteggerti da questi attacchi. Se sei un cliente Assura esistente, contatta il tuo Virtual ISO o Assura POC per ulteriori indicazioni.

Rimani sicuro, rimani in salute e, come sempre, sentiti libero di inviare qualsiasi domanda tu possa avere su questa o qualsiasi altra questione di sicurezza informatica attraverso il nostro sito web o per [email protected]

Sinceramente,

Il team di Assura

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.