Zerologon CVE-2020-1472 Applicazione Active Directory: perché manca ancora in tanti DC

Zerologon CVE-2020-1472 Applicazione Active Directory: cosa significa

Le lacune di Zerologon CVE-2020-1472 Applicazione Active Directory sono la parte della remediation di questa vulnerabilità che continua a essere trascurata, anche se la vulnerabilità in sé non è più una novità. Zerologon è una falla critica (CVSS 10.0) di elevazione dei privilegi nel Netlogon Remote Protocol (MS-NRPC), il meccanismo che le macchine unite al dominio usano per stabilire un canale sicuro con un controller di dominio. È stata scoperta e divulgata responsabilmente da Tom Tervoort di Secura, che ha pubblicato il whitepaper tecnico nel settembre 2020 (Secura). L'advisory di Microsoft la classifica come una vulnerabilità di elevazione dei privilegi di Netlogon (MSRC CVE-2020-1472).

Il motivo per cui vale ancora la pena parlarne a più di tre anni dalla divulgazione non è l'exploit in sé, ma la fase di applicazione (enforcement). Microsoft ha rilasciato le correzioni di Zerologon in due fasi, ed è nella seconda fase che la maggior parte degli ambienti si blocca silenziosamente: patchati, ma mai confermati come effettivamente in modalità di applicazione. Questo conta perché «Zerologon» ha una notorietà tale che molti team lo trattano come un problema risolto e storico invece che come qualcosa da riverificare durante un audit di routine — e continua a comparire insieme alle configurazioni errate di Active Directory più comuni che gli audit trovano ogni anno.

Come funziona Zerologon

La causa principale è un errore di implementazione crittografica in ComputeNetlogonCredential, la funzione che MS-NRPC usa per derivare una chiave di sessione durante NetrServerAuthenticate3. Netlogon usa AES-CFB8 per questo scambio, ma l'implementazione di Microsoft fissava il vettore di inizializzazione (IV) a un valore fisso di 16 byte a zero invece che a un valore casuale — una violazione di come dovrebbe essere usato AES-CFB8 (whitepaper Secura, via Pwnie Awards).

Questa falla ha una conseguenza sfruttabile precisa: per circa 1 chiave possibile su 256, cifrare un plaintext interamente a zero con AES-CFB8 e un IV a zero produce un ciphertext interamente a zero.

La sequenza dell'attacco

Un attaccante non autenticato sulla rete può:

1. Impersonare un account macchina (incluso l'account dello stesso controller di dominio) nell'handshake Netlogon.
2. Inviare una client challenge composta da 8 byte a zero.
3. Ripetere l'handshake — in media circa 256 tentativi — finché il server non accetta la credenziale interamente a zero.
4. Una volta autenticato, chiamare NetrServerPasswordSet2 per reimpostare la password dell'account macchina di un obiettivo, incluso lo stesso DC, a un valore noto.

Da lì, un attaccante che ha reimpostato la password dell'account macchina di un controller di dominio può autenticarsi come quel DC ed eseguire un DCSync per estrarre tutti gli hash delle password del dominio — compromissione completa del dominio, senza autenticazione, in pochi minuti. Nessuna credenziale, nessun phishing, nessun malware sull'endpoint — solo la raggiungibilità di rete verso il servizio Netlogon di un controller di dominio. Il nostro approfondimento su abuso di ACL e DCSync descrive come appare questo abuso di replica una volta che un attaccante ha i diritti per innescarlo.

Sfruttamento confermato nel mondo reale

CISA ha aggiunto il CVE-2020-1472 al proprio catalogo delle vulnerabilità sfruttate note (Known Exploited Vulnerabilities) e ha emesso la Direttiva di Emergenza 20-04, ordinando a tutte le agenzie federali statunitensi di patchare o disconnettere i controller di dominio interessati entro le 23:59 EDT del 21 settembre 2020 (CISA ED 20-04). CISA ha successivamente confermato lo sfruttamento attivo della falla da parte di attori state-sponsored (alert CISA, ottobre 2020), ed è stata da allora osservata in intrusioni ransomware mirate a controller di dominio non patchati. La combinazione di un punteggio CVSS massimo, nessun requisito di autenticazione e una proof-of-concept pubblica è esattamente il motivo per cui questa classe di vulnerabilità merita una riverifica periodica e non una patch-and-forget una tantum.

Perché l'applicazione è un problema distinto dal patching

Microsoft ha rilasciato la correzione in due fasi, e proprio questo scaglionamento è il motivo per cui le lacune di applicazione persistono anni dopo che tutti credono che la questione sia chiusa.

Fase 1 — Aggiornamento dell'11 agosto 2020

Questa patch ha cambiato il modo in cui i DC gestiscono le connessioni Netlogon vulnerabili e ha introdotto l'impostazione di registro FullSecureChannelProtection sotto HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters, ma l'applicazione era opzionale. I DC entravano in una «fase di deployment iniziale» in cui i dispositivi non conformi venivano registrati nei log, non bloccati, a meno che un amministratore non impostasse esplicitamente il valore di registro o distribuisse la GPO di applicazione (Supporto Microsoft: gestione delle modifiche alle connessioni di canale sicuro Netlogon).

Fase 2 — Aggiornamento del 9 febbraio 2021

Questo aggiornamento ha reso la modalità di applicazione il comportamento predefinito per tutti i controller di dominio Windows, indipendentemente dal valore di registro o dall'impostazione di Group Policy (Tenable: Microsoft finalizza l'applicazione predefinita di Zerologon).

La lacuna della lista di eccezioni GPO

La lacuna che la maggior parte degli audit trova oggi non è «Zerologon non patchato» — sono ambienti in cui dispositivi legacy o di terze parti (NAS, server di stampa, vecchi client Netlogon non Windows) si sono rotti sotto l'applicazione nel 2021, e un amministratore li ha aggiunti alla lista di eccezioni della Group Policy «Controller di dominio: consenti connessioni di canale sicuro Netlogon vulnerabili» per fermare il disservizio. Quella lista di eccezioni è esattamente la lacuna di applicazione: è ancora lì, mai rivista, anni dopo, e permette silenziosamente lo stesso handshake vulnerabile che Zerologon sfrutta — limitata agli account che sono stati esentati. Un controller di dominio può essere completamente patchato e avere comunque questa falla aperta per policy, motivo per cui il solo livello di patch non è prova sufficiente di applicazione.

Rilevamento

Netlogon registra ID evento specifici per l'attività di canale sicuro vulnerabile su ogni controller di dominio. Monitorateli su tutti i DC, non solo su uno:

(Supporto Microsoft: gestione delle modifiche alle connessioni di canale sicuro Netlogon)

Estrarre gli eventi

Concretamente, su ogni controller di dominio:

# Estrai gli eventi recenti di canale Netlogon vulnerabile dal log Sistema
Get-WinEvent -LogName System -FilterXPath "*[System[(EventID=5827 or EventID=5828 or EventID=5829 or EventID=5830 or EventID=5831)]]" -MaxEvents 200 |
    Select-Object TimeCreated, Id, Message |
    Format-Table -AutoSize

# Conferma direttamente lo stato di applicazione nel registro (informativo sui DC patchati
# da febbraio 2021 in poi, dove l'applicazione è predefinita indipendentemente da questo valore)
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" -Name FullSecureChannelProtection -ErrorAction SilentlyContinue

Qualsiasi evento 5829, 5830 o 5831 merita un'indagine — identifica esattamente quale dispositivo dipende ancora dall'handshake vulnerabile e perché, dandovi un elenco concreto su cui lavorare invece di un'ipotesi di policy. Abbinate il monitoraggio degli eventi Netlogon all'insieme più ampio degli ID evento di sicurezza di Active Directory che dovrebbero già essere nel vostro SIEM, e a una revisione più ampia delle priorità di hardening affinché correzioni a livello di protocollo come questa non vengano trattate come progetti una tantum che escono dal perimetro nel tempo.

Remediation

1. Confermate il livello di patch su ogni DC, non su un campione. Verificate che ogni controller di dominio abbia almeno l'aggiornamento dell'11 agosto 2020, e idealmente l'aggiornamento cumulativo del 9 febbraio 2021 o successivo, che rende l'applicazione predefinita. I DC dimenticati (inclusi i DC in sola lettura e i DC in domini/foreste meno visibili) sono la lacuna più comune.
2. Verificate la GPO «Controller di dominio: consenti connessioni di canale sicuro Netlogon vulnerabili». Rivedete ogni voce della lista di eccezioni. Per ogni dispositivo esentato, confermate che esiste ancora, che ha ancora bisogno dell'eccezione, e che non è disponibile un aggiornamento firmware/software del fornitore che aggiunga un supporto RPC sicuro adeguato. Rimuovete le voci obsolete.
3. Monitorate continuamente gli eventi 5829/5830/5831, non solo durante una finestra di deployment una tantum. Qualsiasi nuova occorrenza significa che un dispositivo dipende oggi dal percorso vulnerabile.
4. Impostate (o verificate) FullSecureChannelProtection = 1 su ogni DC che non ha ancora ricevuto l'aggiornamento di febbraio 2021 o successivo, come controllo provvisorio mentre il patching si completa.
5. Riverificate dopo ogni cambiamento infrastrutturale. Nuovi controller di dominio, promozioni di DC da template/immagini, e cambiamenti di trust tra foreste/domini possono tutti reintrodurre uno stato non applicato o non patchato — integrate questo nella revisione standard delle GPO e dei build dei DC, non solo nel rollout iniziale 2020/2021.
6. Trattate l'esposizione a DCSync come il rischio a valle. L'impatto reale di Zerologon è che dà a un attaccante la capacità di reimpostare la password dell'account proprio di un DC ed estrarre gli hash delle password del dominio. Rivedere chi e cosa possiede già diritti di replica legittimi compatibili con DCSync chiude la seconda metà di questo percorso di attacco — vedete la nostra guida su abuso di ACL e DCSync.

Come EtcSec rileva questo

Il controllo ZEROLOGON_PATCH_ENFORCEMENT di EtcSec segnala i controller di dominio dove l'applicazione di Zerologon non può essere confermata — che si tratti di una patch mancante, di un'impostazione FullSecureChannelProtection disabilitata su un DC precedente a febbraio 2021, o di una GPO di eccezione Netlogon attiva — così da non essere silenziosamente assunta come «risolta nel 2020». È abbinato a DCSYNC_CAPABLE, che segnala account e oggetti computer con diritti di replica che una compromissione in stile Zerologon permetterebbe a un attaccante di sfruttare per un'estrazione completa delle credenziali. Insieme, i due controlli coprono l'intero percorso di attacco: il punto d'appoggio iniziale non autenticato e i diritti di replica privilegiati che lo trasformano in una violazione dell'intero dominio.