LegacyHive scuote Windows: una falla nel registro può portare ai privilegi SYSTEM

Come già accaduto subito dopo i Patch Tuesday Microsoft degli ultimi mesi, il ricercatore conosciuto con l’appellativo di Nightmare Eclipse ha reso nota la scoperta di una nuova vulnerabilità in Windows. Battezzata LegacyHive, la falla di sicurezza in questione dimostra la presenza di una falla che interessa la gestione della struttura del registro di sistema e che può portare al caricamento di codice arbitrario.

Il registro di Windows non è un unico database monolitico: il sistema lo costruisce caricando diversi file, chiamati hive, che contengono porzioni distinte della configurazione.

Per ciascun utente, Windows usa soprattutto NTUSER.DAT e UsrClass.dat: il primo conserva gran parte delle impostazioni personali, il secondo contiene associazioni di file, registrazioni COM e altre informazioni legate alle classi software.

Manipolare il caricamento di questi file non equivale automaticamente a ottenere privilegi amministrativi. Tuttavia, se un utente senza privilegi riesce a far montare un hive “personalizzato”, può alterare il modo in cui applicazioni e componenti di sistema risolvono impostazioni, oggetti COM e percorsi di esecuzione. Proprio su questo piano, LegacyHive diventa molto interessante.

Come Windows carica i profili utente usando gli hive del registro di sistema

Quando un utente accede a Windows, il servizio User Profile Service prepara l’ambiente di lavoro: individua la cartella del profilo, applica le relative autorizzazioni e carica nel registro di sistema i file che contengono le impostazioni personali.

NTUSER.DAT contiene gran parte della configurazione dell’account ed è caricato sotto HKEY_USERS in una chiave identificata dal SID (Security Identifier) dell’utente, cioé dal codice univoco con cui Windows riconosce quell’account. UsrClass.dat viene invece montato in una chiave separata, sempre sotto HKEY_USERS, il cui nome termina normalmente con _Classes.

Il ruolo di UsrClass.dat è importante perché una parte del suo contenuto diventa visibile alle applicazioni attraverso HKEY_CURRENT_USER\Software\Classes: qui Windows conserva numerose impostazioni specifiche dell’utente come associazioni tra estensioni e programmi, registrazioni COM, configurazioni della shell e indicazioni su come aprire determinati tipi di file.

Il contenuto del ramo HKEY_CLASSES_ROOT, nel registro di Windows, non è quindi un archivio indipendente: è una vista costruita al momento dal sistema operativo Microsoft, che unisce due insiemi di dati ovvero le impostazioni valide per l’intero computer, presenti sotto HKEY_LOCAL_MACHINE\Software\Classes e quelle del singolo utente, presenti sotto HKEY_CURRENT_USER\Software\Classes. In diversi casi, le registrazioni dell’utente possono prevalere su quelle globali.

Il rischio intrinseco che discende dalla struttura del registro di Windows

Un esempio aiuta a capire il rischio. Un programma può chiedere a Windows quale componente usare per aprire un file o attivare un oggetto COM: il sistema consulta le chiavi Classes e restituisce il percorso registrato. Se un aggressore riesce a far comparire in quella posizione un hive preparato o appartenente a un altro account, puo’ influenzare la risposta fornita al programma.

Durante l’accesso e la disconnessione, User Profile Service deve quindi associare ogni file UsrClass.dat al profilo corretto, caricarlo nella chiave prevista e rimuoverlo quando non serve più. Errori in questa procedura possono causare problemi noti, come il mancato caricamento delle classi del registro segnalato dall’evento 1542. La situazione diventa molto seria quando il servizio accetta un file, un percorso o un’identità utente diversi da quelli che dovrebbe gestire.

Come funziona l’attacco LegacyHive

La versione pubblica del PoC (proof-of-concept) condiviso da Nightmare Eclipse richiede le credenziali di un secondo utente standard e il nome di un terzo account, che può anche appartenere al gruppo Administrators. Se l’operazione riesce, l’hive UsrClass.dat dell’account indicato finisce montato nella radice Classes dell’utente.

Il ricercatore afferma di aver deliberatamente ridotto il “raggio d’azione” del PoC per evitare che la sua scoperta possa essere sfruttata per fare danni: la variante originale non richiederebbe alcune credenziale aggiuntiva e sarebbe in grado di caricare hive diversi da UsrClass.dat.

In pratica, il codice pubblico sembra rappresentare una dimostrazione limitata di una primitiva più generale ed efficace.

Un hive non contiene codice eseguibile nel senso tradizionale, ma può controllare molte decisioni prese da Windows e dalle applicazioni. Le registrazioni COM, per esempio, associano un identificatore CLSID a un server in-process, spesso una libreria DLL, oppure a un processo esterno.

Un attacco COM hijacking può verificarsi quando un programma eseguito con privilegi elevati legge dal registro di Windows una configurazione predisposta dall’aggressore e carica il componente indicato, come una DLL o un eseguibile.

Come ridurre l’esposizione in attesa di una risposta Microsoft

Non essendoci ancora una patch specifica, la mitigazione passa soprattutto dalla riduzione dei prerequisiti che portano all’eventuale attacco.

Gli amministratori dovrebbero limitare gli account locali non necessari, rimuovere profili obsoleti e impedire agli utenti standard di accedere a credenziali amministrative o di servizio. Ogni account aggiuntivo amplia le combinazioni che un exploit come LegacyHive può tentare.

Conviene controllare le appartenenze ai gruppi Administrators locali, disabilitare gli account inutilizzati e utilizzare password uniche. Separare gli account quotidiani da quelli amministrativi resta una misura essenziale: un amministratore non dovrebbe usare abitualmente la stessa sessione per navigazione, posta elettronica e attività privilegiate.

LegacyHive evidenzia una debolezza potenzialmente seria nella separazione tra profili utente: la possibilità che un servizio eseguito come SYSTEM carichi un hive scelto o associato all’account sbagliato rappresenta una comportamento pericoloso, soprattutto se un attaccante può combinarla con registrazioni COM, operazioni privilegiate o sostituzioni temporizzate di file.

La versione pubblica di LegacyHive, come osservato in precedenza, presenta vincoli significativi e non documenta una catena completa fino all’esecuzione come amministratore o SYSTEM. Descriverla come una compromissione remota o come un exploit immediato utilizzabile su tutte le macchine Windows sarebbe fuorviante: si tratta di un’elevazione locale. L’aggressore deve già poter eseguire codice sul sistema e soddisfare ulteriori condizioni.

La situazione può tuttavia cambiare rapidamente. Il codice è pubblico, altri ricercatori possono analizzarlo e la variante ridotta potrebbe offrire indizi sufficienti per ricostruire la tecnica più potente citata dall’autore. Da parte sua, Microsoft dovrà chiarire se il comportamento rientra in un confine di sicurezza riconosciuto, quali build risultano coinvolte e se occorre modificare il servizio profili.