Blog post 15 novembre 2019, di Tom Tervoort, Senior Security Specialist di Bureau Veritas Cybersecurity
Prendere il controllo dei sistemi Windows con un attacco Netlogon Man-in-the-Middle (CVE-2019-1424)
Sfondo
Il Netlogon Remote Procotol è un protocollo Remote Procedure Call (RPC) che esegue varie funzioni sulle reti Windows relative all'autenticazione Active Directory. Può essere utilizzato, ad esempio, per resettare le password delle macchine o per eseguire il backup del database utenti del controller di dominio. L'applicazione più comune, tuttavia, è quella di facilitare i login remoti tramite il protocollo NTLM.
Lo scopo del protocollo NTLM è quello di consentire agli utenti del dominio di accedere a sistemi remoti all'interno della rete, come i server che forniscono condivisioni di file o siti web intranet. Sebbene questo protocollo sia stato sostituito da Kerberos dall'introduzione di Windows 2000, è ancora ampiamente utilizzato e supportato. Quasi tutti i servizi Windows che supportano l'autenticazione Kerberos consentono per impostazione predefinita anche ai clienti di accedere utilizzando NTLM.
Quando qualcuno si autentica con successo in un dominio Windows, viene calcolato un hash MD4 (chiamato anche "hash NTLM") della sua password.1 Il controller di dominio memorizza anche gli hash MD4 delle password di tutti gli utenti. Quando poi il cliente desidera autenticarsi a un servizio che utilizza NTLM, il servizio trasmette una sfida casuale al cliente. Per dimostrare l'identità dell'utente, il client risponderà con un MAC (Message Authentication Code) crittografico, calcolato sulla sfida utilizzando l'hash della password dell'utente come chiave segreta.
Quando il servizio in questione non è in esecuzione sul controller di dominio stesso, non ha effettivamente accesso all'hash della password e quindi non può convalidare se il MAC è corretto. In questo caso, il sistema che esegue il servizio stabilirà una connessione con il controller di dominio e gli invierà la sfida insieme alla risposta ricevuta dal client. Il controller di dominio verificherà il MAC e informerà il servizio se è valido o meno. In caso contrario, potrebbe significare che l'utente ha inserito una password sbagliata. Se l'autenticazione riesce, tuttavia, il controller di dominio informerà anche il servizio sui gruppi a cui appartiene l'utente e gli fornirà una chiave di sessione segreta.2 Questo scambio di informazioni tra la macchina che esegue il servizio e il controller di dominio utilizza il protocollo Netlogon Remote Protocol.
Illustrazione 1: Funzionamento normale del protocollo di autenticazione NTLM (flusso felice). La connessione tra il server e il DC utilizza il protocollo Netlogon.
Il protocollo
Il protocollo Netlogon Remote è costruito sulla base di MSRPC (Microsoft Remote Procedure Call) e le sue specifiche sono disponibili pubblicamente. Quando un client desidera stabilire una connessione Netlogon con il controller di dominio, si connette prima al servizio EPM (Endpoint Mapper) sulla porta TCP 135. Il controller di dominio informa il client su quale porta TCP è disponibile un servizio Netlogon. Il controller di dominio informerà quindi il cliente su quale porta TCP è disponibile un servizio Netlogon. Se il client non riesce a raggiungere il servizio EPM o la porta indicata (forse perché un firewall la blocca), eseguirà una connessione Netlogon tramite il protocollo SMB sulla porta 445. Ciò significa che le chiamate Netlogon vengono trasmesse utilizzando MSRPC-over-TCP o MSRPC-over-SMB-over-TCP.
Poiché l'integrità e la riservatezza delle informazioni scambiate tramite il protocollo sono critiche, vengono utilizzati controlli crittografici per proteggere le chiamate di procedura remota e le loro risposte. È interessante notare che Netlogon non utilizza la crittografia MSRPC standard, ma un protocollo alternativo. All'inizio di una connessione, il client e il server si scambiano valori casuali e poi ricavano una chiave di sessione da una combinazione della password della macchina del client e di questi due valori. Il client si autentica poi dimostrando il possesso di questa chiave di sessione. Tutti i pacchetti successivi vengono crittografati e autenticati utilizzando la chiave di sessione. Questo processo è identico indipendentemente dall'utilizzo del tunnel SMB.
La vulnerabilità
Poiché il protocollo crittografico utilizzato per Netlogon è piuttosto poco ortodosso e non è stato sottoposto a molti controlli, a mia conoscenza, ho deciso di indagare sulle possibili vulnerabilità del protocollo o della sua implementazione. Mentre testavo una configurazione di laboratorio in cui sarei stato in grado di eseguire attacchi man-in-the-middle contro il protocollo, ho improvvisamente notato qualcosa di strano nella mia acquisizione di rete: Chiamate Netlogon che non venivano crittografate.
Dopo alcuni esperimenti, ho scoperto che ciò era dovuto al fatto che avevo accidentalmente bloccato il traffico sia verso EPM che verso la porta Netlogon dinamica, causando un fallback a SMB. Normalmente, questo non sarebbe un problema: se EPM non è disponibile, il client esegue l'handshake di autenticazione normalmente e inizia a crittografare i messaggi successivamente. In questo caso, tuttavia, ho bloccato il traffico verso queste porte dopo che era già stata stabilita una sessione crittografata.
Per qualche motivo, quando avviene un fallback a SMB mentre è già stata stabilita una sessione, i pacchetti Netlogon successivi non vengono crittografati e la loro integrità non è protetta. I messaggi del server e del client conterrebbero comunque gli "autenticatori", che sono campi obbligatori del messaggio generati con la chiave di sessione. Questi valori, tuttavia, non dipendono dal contenuto del resto del messaggio, quindi un aggressore potrebbe apportare qualsiasi modifica arbitraria ai messaggi, purché lasci semplicemente l'autenticatore originale al suo posto.
Un aggressore con una posizione man-in-the-middle tra la macchina e il controller di dominio potrebbe quindi forzare la disabilitazione della crittografia attivando il fallback SMB subito dopo che la macchina ha eseguito l'handshake di autenticazione. Questo potrebbe essere realizzato iniettando pacchetti TCP RST quando il client tenta di connettersi alla porta 135 o alla porta dinamica Netlogon.
Un aggressore in grado di falsificare le risposte Netlogon dal controller di dominio a un computer sarebbe quindi in grado di utilizzare questo attacco per sostituire una risposta "login fallito" con un messaggio "login riuscito". Questo messaggio verrebbe ignorato dalla macchina, pensando che il DC abbia autenticato con successo l'utente. Sarebbero anche in grado di determinare a quali gruppi appartiene l'utente che cerca di accedere.
Illustrazione 2: Attacco Man-in-the-middle: l'aggressore annulla la crittografia e falsifica una risposta Netlogon per ottenere l'accesso come amministratore all'obiettivo.
Impatto
Non sarebbe necessario attendere che qualche altro utente tenti di accedere. Invece, l'aggressore può accedere da solo, fingendo di supportare solo NTLM e fornendo una password non valida. Il servizio a cui si accede inoltrerà l'handshake NTLM al controller di dominio, che risponderà con una risposta negativa. Questo messaggio potrebbe poi essere sostituito da una risposta di spoofing (contenente anche una chiave di sessione ricalcolata) che indica che la password era corretta e, tra l'altro, l'utente che sta cercando di accedere è un membro del gruppo admin del dominio (il che significa che ha anche privilegi amministrativi sul computer di destinazione).
Quando si ottiene una posizione man-in-the-middle tra un sistema X e il controller di dominio, un aggressore sarà in grado di utilizzare questo attacco per accedere come amministratore a qualsiasi servizio su X che supporti l'autenticazione NTLM. Attraverso vari tipi di servizi, come SMB, WMI o DCOM, la possibilità di accedere come amministratore può portare all'esecuzione di codice remoto con quel ruolo, il che significa che il sistema mirato può essere compromesso completamente.
Gli obiettivi contro i quali questo attacco ha probabilmente successo sono le stazioni di lavoro delle persone, che spesso consentono connessioni SMB in entrata. Inoltre, ci sono molte tecniche che un aggressore può utilizzare per effettuare attacchi man-in-the-middle contro questi sistemi: come lo spoofing ARP/NDP, lo spoofing delle risposte DHCP, la creazione di un punto di accesso Wi-Fi dannoso o l'inserimento di un dispositivo di intercettazione in un socket di rete.
Questa vulnerabilità può essere particolarmente pericolosa quando un aggressore ha un punto d'appoggio in una rete interna, perché consente sia l'elevazione dei privilegi (fino all'amministratore locale) sia il movimento laterale (ottenendo RCE su altre macchine della rete).
Dopo aver rivelato questa vulnerabilità e una catena di exploit Proof-of-Concept funzionante a Microsoft, quest'ultima ha risposto rapidamente e il 12 novembre 2019 è stata rilasciata una correzione. Si consiglia vivamente di applicare questa patch (almeno ai controller di dominio) il prima possibile, in quanto mitigherà completamente questa vulnerabilità.
__________________________________
Quando esegue l'autenticazione senza password con smartcard o Windows Hello, il controller di dominio fornirà invece al client un hash MD4 di una lunga password generata in modo casuale. Questo attenua un difetto importante del protocollo NTLM, che i pentester e gli aggressori amano sfruttare: la sua vulnerabilità agli attacchi di indovinare la password offline.
Questa chiave è derivata dalla password e può essere calcolata in modo indipendente dal client. Diversi protocolli, tra cui SMBv3, utilizzano questo segreto condiviso per autenticare e crittografare il traffico tra il client e il server.