Questo post é stato letto 60 volte!
Legacyhive scuote windows: la falla nel registro può portare ai privilegi system
Una nuova vulnerabilità, denominata LegacyHive, sta destando preoccupazione nel panorama della sicurezza informatica, evidenziando una potenziale falla nel sistema operativo Windows.
Questa vulnerabilità permette, anche su sistemi Windows aggiornati con le ultime patch di luglio 2026, l’ottenimento di privilegi system, rappresentando un rischio significativo per l’integrità dei dati e la stabilità del sistema.
La scoperta, attribuita al ricercatore conosciuto come Nightmare Eclipse, mette in luce come una gestione difettosa della struttura del registro di sistema possa aprire la strada al caricamento di codice arbitrario, compromettendo la sicurezza.
Come il registro di windows gestisce i profili utente
Il registro di Windows non è un database unico e monolitico, ma si compone di diversi file, chiamati hive, che contengono specifiche porzioni della configurazione del sistema.
Per ogni utente, Windows utilizza principalmente NTUSER.DAT e UsrClass.dat.
Il primo file conserva la maggior parte delle impostazioni personali, mentre il secondo gestisce le associazioni di file, le registrazioni COM e altre informazioni relative alle classi software.
La manipolazione del caricamento di questi file, sebbene non garantisca automaticamente privilegi amministrativi, può alterare il funzionamento di applicazioni e componenti di sistema, influenzando il modo in cui vengono risolte impostazioni, oggetti COM e percorsi di esecuzione. È proprio in questo contesto che LegacyHive si rivela particolarmente pericoloso.
Il caricamento degli hive e il ruolo di usrclass.dat
Quando un utente accede a Windows, il servizio User Profile Service prepara l’ambiente di lavoro, individuando la cartella del profilo, applicando le autorizzazioni necessarie e caricando nel registro di sistema i file contenenti le impostazioni personali.
NTUSER.DAT, che racchiude gran parte della configurazione dell’account, viene caricato sotto HKEYUSERS, identificato dal SID (Security Identifier) dell’utente.
UsrClass.dat, invece, viene montato in una chiave separata, sempre sotto HKEYUSERS, solitamente con un nome che termina con Classes.
Il ruolo di UsrClass.dat è cruciale, poiché parte del suo contenuto diventa visibile alle applicazioni tramite HKEYCURRENTUSER\Software\Classes, dove Windows conserva impostazioni utente specifiche come associazioni tra estensioni e programmi, registrazioni COM e configurazioni della shell.
Il ramo HKEYCLASSESROOT, nel registro di Windows, non è un archivio indipendente, ma una vista dinamica che unisce le impostazioni valide per l’intero computer (HKEYLOCALMACHINE\Software\Classes) con quelle del singolo utente (HKEYCURRENT_USER\Software\Classes), con le registrazioni utente che spesso prevalgono su quelle globali.
La vulnerabilità di legacyhive e i rischi associati
La struttura del registro di Windows presenta un rischio intrinseco.
Un programma, ad esempio, potrebbe chiedere a Windows quale componente utilizzare per aprire un file o attivare un oggetto COM.
Se un aggressore riesce a far comparire in quella posizione un hive “personalizzato” o appartenente a un altro account, può influenzare la risposta fornita al programma.
Durante l’accesso e la disconnessione, User Profile Service deve associare ogni file UsrClass.dat al profilo corretto, caricarlo nella chiave prevista e rimuoverlo quando non più necessario.
Errori in questa procedura possono causare problemi, come il mancato caricamento delle classi del registro, indicato dall’evento 1542.
La situazione diventa critica 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 proof-of-concept (PoC) di LegacyHive, condivisa 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 ha successo, l’hive UsrClass.dat dell’account specificato viene montato nella radice Classes dell’utente.
Il ricercatore ha limitato il “raggio d’azione” del PoC per prevenire abusi, ma la variante originale non richiederebbe credenziali aggiuntive e sarebbe in grado di caricare hive diversi da UsrClass.dat.
Sebbene un hive non contenga codice eseguibile nel senso tradizionale, può controllare molte decisioni prese da Windows e dalle applicazioni.
Le registrazioni COM, ad esempio, associano un identificatore CLSID a un server in-process (spesso una libreria DLL) o a un processo esterno.
Un attacco COM hijacking può verificarsi quando un programma con privilegi elevati legge dal registro una configurazione predisposta dall’aggressore e carica il componente indicato, come una DLL o un eseguibile malevolo.
Misure di mitigazione e prospettive future
In assenza di una patch specifica, la mitigazione della vulnerabilità LegacyHive si basa principalmente sulla riduzione dei prerequisiti che potrebbero portare a un 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, infatti, amplia le combinazioni che un exploit come LegacyHive può tentare. È consigliabile controllare l’appartenenza ai gruppi Administrators locali, disabilitare gli account inutilizzati e utilizzare password uniche.
Separare gli account quotidiani da quelli amministrativi rimane una misura essenziale: un amministratore non dovrebbe usare abitualmente la stessa sessione per navigazione, posta elettronica e attività privilegiate.
LegacyHive evidenzia una debolezza potenzialmente grave nella separazione tra profili utente.
La possibilità che un servizio eseguito come SYSTEM carichi un hive scelto o associato all’account sbagliato rappresenta un comportamento pericoloso, specialmente se un attaccante può combinarlo con registrazioni COM, operazioni privilegiate o sostituzioni temporizzate di file.
La versione pubblica di LegacyHive, sebbene con vincoli significativi, fornisce indizi sufficienti per ricostruire tecniche più potenti.
Microsoft dovrà chiarire se il comportamento rientra in un confine di sicurezza riconosciuto, quali build sono coinvolte e se è necessario modificare il servizio profili per affrontare questa elevazione di privilegi locale.
Questo post é stato letto 60 volte!