Zerologon: la nuova falla al Netlogon (CVE-2020-1472)
Ad agosto, Microsoft ha rilasciato un patch per diverse versioni di Windows (gratuite per Windows 10 o Windows 2012 in su) per correggere una vulnerabilità che consentirebbe ad un utente malintenzionato di diventare essenzialmente amministratore di dominio facilmente. L’unica cosa che gli serve è un collegamento diretto ad un domain controller, ossia il server che nelle reti di server Windows svolgere il ruolo di gestire gli accessi centralizzati.
La vulnerabilità è possibile grazie ad un errore in uno schema di autenticazione crittografica utilizzato dal Netlogon Remote Protocol, che tra le altre cose può essere utilizzato per aggiornare le password dei computer.
Questo problema consente agli aggressori di impersonare qualsiasi computer, incluso il domain controller (DC) stesso, ed eseguire chiamate di procedura remota (RPC) per conto di un altro computer.
Già l’anno scorso si era scoperta una vulnerabilità al componente Netlogon meno grave ma ora questa seconda vulnerabilità è molto più grave (punteggio CVSS: 10.0). Creando un token di autenticazione per una specifica funzionalità di Netlogon, è stato in grado di utilizzare una funzione per modificare la password di un computer sul domain controller su un valore noto. Dopodiché, l’aggressore può utilizzare questa nuova password per assumere il controllo del domain controller e rubare le credenziali di un amministratore di dominio.
La patch rilasciata ad agosto predispone l’insieme di server all’arrivo di una nuova patch che sarà rilasciata a febbrario 2021.
Questo è stato necessario perchè una volta installata la patch di febbraio i vecchi domain controller Windows 2003 e 2008 per i quali non verrà rilasciata nessuna patch non potranno più comunicare con domain controller patchati.
Linux è affetto?
Ora veniamo a Linux, i tool di configurazione di Samba supportano canali sicuri tra i membri del dominio e i domain controller.
Tuttavia, il comportamento predefinito per il server schannel (secure channel) prima di Samba 4.8 era di negoziare automaticamente il canale sicuro solo se un client lo supportava.
Dalla versione 4.8, il comportamento predefinito di Samba è stato quello di preferire un canale sicuro per tutti i client (come se ci fosse “server schannel = yes” nel file smb.conf), il che è una soluzione sufficiente contro gli exploit noti che sfruttano la vulnerabilità CVE-2020-1472.
La richiesta di un canale sicuro potrebbe rendere inutilizzabili alcune vecchie applicazioni scrite per vecchie versioni di Active Directory (domini NT4).
Per questo motivo, la mitigazione di Microsoft per CVE-2020-1472 non disabilita immediatamente l’accesso non autenticato al servizio di netlogon.
Red Hat non è a conoscenza di applicazioni specifiche che richiedono l’uso di un canale non autenticato per il servizio di netlogon.
Tutti i componenti Samba in tutte le versioni di Red Hat Enterprise Linux (RHEL) supportano il funzionamento con schannel e continueranno a funzionare quando i futuri aggiornamenti di Microsoft disabiliteranno del tutto il supporto del canale non autenticato.
In Red Hat Enterprise Linux 6 le configurazioni predefinite dei pacchetti samba e samba4 forniti con il sistema sono vulnerabili in quanto non impongono la creazione di canali sicuri per tutte le connessioni client al servizio netlogon. La vulnerabilità può essere mitigata mettendo “server schannel = yes” nella sezione [global] del file smb.conf e riavvia Samba su tutti i DC.
Tuttavia , si può usare testparm per verificare che la configurazione di Samba sia in esecuzione in modalità domain controller oppure standalone (ossia membro di dominio) e quale impostazione “server schannel” viene utilizzata.
testparm -v -s | grep schannel
Se nell’output del comando compare “Server role: ROLE_DOMAIN_PDC” oppure “Server role: ROLE_DOMAIN_BDC” il server agisce come domain controller.
Nelle righe successive dell’output è riportato se è attivato o meno il secure channel (schannel).
Anche SuSE Linux è affetta dalla problematica per le versioni di Samba precedenti alla 4.8, anche qui il suggerimento per mitigare la falla è quello di inserire lo stesso parametro visto per RHEL: “server schannel = yes” nel file smb.conf e riavviare il servizio con un “sudo service smb restart”. Il supporto di SUSE riporta sono state correzioni e aggiornamenti a tutte le versioni supportate e interessate al problema.