Il mese scorso Microsoft ha rilasciato un avviso per CVE-2020-1317, che descrive una vulnerabilità di escalation dei privilegi nei Criteri di gruppo. La vulnerabilità è stata ulteriormente dettagliata dallo scopritore della vulnerabilità sul sito web Cyberark. La natura di questo problema è interessante e merita di essere compresa. Per anni, i Criteri di gruppo hanno avuto questa dicotomia nel loro design. Vale a dire, la necessità di fornire criteri per utente a utenti altrimenti non privilegiati, attraverso un meccanismo che viene eseguito come processo privilegiato, vale a dire il motore dei Criteri di gruppo. Microsoft ha gestito questo problema in vari modi. Ad esempio, i criteri dei modelli amministrativi per l'utente sono stati trasmessi a un insieme di due chiavi di registro in HKEY_CURRENT_USER che, guarda caso, erano autorizzate in modo tale che un utente non potesse scrivervi, pur potendo scrivere su quasi tutte le altre chiavi di questo alveare. Nel caso di questo CVE, però, c'erano un paio di falle evidenti. La prima di queste è stata descritta nel post del blog di Cyberark. In particolare, le Preferenze GP hanno sempre avuto il concetto di file di cronologia. Questi file sono stati creati per annullare essenzialmente lo stato di alcune Preferenze GP quando tali impostazioni non erano più applicabili. Questi file di cronologia erano essenzialmente copie del file di impostazioni effettivo memorizzato in SYSVOL per la GPO che forniva le impostazioni e venivano memorizzati nel profilo dell'utente in %appdata%LocalMicrosoftGroup Policy, come si può vedere qui:
Lettura correlata
La posizione di questo file è stata la chiave di questa vulnerabilità privesc. I file stessi sono memorizzati nel profilo dell'utente, in un'area a cui un normale utente non privilegiato ha pieni diritti. Tuttavia, i file vengono scritti qui ogni volta che una nuova impostazione di GPP viene elaborata, o l'impostazione viene modificata, dal motore GP, che viene eseguito come localSystem. Quindi, abbiamo un processo localSystem che scrive dati nello spazio utente non privilegiato e qui inizia il divertimento.
Per questo particolare exploit, l'autore ha utilizzato i collegamenti simbolici di Object Manager per reindirizzare qualsiasi file XML GPP arbitrario a una posizione in c:windowsystem32, dove può essere sfruttato da un ulteriore processo per aprire essenzialmente un processo in esecuzione come localSystem. I dettagli dell'effettivo codice di escalation a localSystem non sono mostrati, ma l'uso dei collegamenti simbolici OM (e lo sfruttamento di altri tipi di collegamenti simbolici di Windows) è descritto in questo eccellente video di James Forshaw, che ha anche un esempio di codice per la creazione di questi collegamenti qui. È sufficiente dire che per sfruttarlo, un aggressore deve solo cancellare il file che GPP ha lasciato nel suo profilo utente e sostituirlo con un collegamento simbolico OM. Il GP Engine arriverà quindi, felicemente in esecuzione come sistema locale, e scriverà essenzialmente un nuovo file XML in qualsiasi destinazione specificata in c:windowssystem32. A questo punto è possibile scrivere qualsiasi contenuto si desideri in quel file e sfruttarlo da lì. Piuttosto astuto.
Percorsi di exploit alternativi e patch
Quando ho visto per la prima volta questo exploit descritto, mi sono chiesto ad alta voce se i file della cronologia GPP fossero l'unico posto in cui questo potesse essere sfruttato. Sapevo per certo che il mio buon amico, il file di archivio del registro di sistema (ntuser.pol), era un altro di questi file GPO per utente che si trovavano nel profilo dell'utente e potevano essere scritti dall'utente, ma aggiornati dal motore GP. Era quindi logico pensare che anche questo file potesse essere sfruttato allo stesso modo dei file della cronologia delle preferenze di GP. Quando ho esaminato un sistema Windows dopo aver applicato la patch per questa vulnerabilità, ho notato alcune cose interessanti. In primo luogo, il modo in cui Microsoft ha risolto il problema è stato quello di spostare i file della cronologia GPP fuori dal profilo utente e nella cartella protetta %programdata% (in particolare sotto %programdata%MicrosoftGroup PolicyUsers). Questa cartella non è scrivibile dagli utenti normali, il che consente di evitare l'uso di collegamenti simbolici nella versione precedente. Il percorso completo del file è un po' strano, come si può vedere qui:
La struttura delle cartelle è per utente (cioè il percorso della cartella SID), poi per GPO (il GUID della GPO), poi di nuovo per utente (un'altra cartella SID), il che mi sembra un po' eccessivo, ma sono sicuro che c'era un motivo 🙂
The next question I was curious about, was the ntuser.pol file I mentioned above. Sure enough, Microsoft also moved that file to a location in %programdata% as well, albeit in a different folder structure from GPP history files. Namely, under %programdata%MicrosoftGroupPolicyUsers<SID of User>. I thought it was mildly funny that they have two folder structures under the Microsoft folder, one called “Group Policy” and the other called “GroupPolicy”. Oh well. This latter path is also where the per-user Group Policy Cache files are kept. See this article for a review of the Group Policy cache.
Secondo l'autore dell'exploit, Microsoft ha impiegato quasi un anno per risolvere il problema. Posso assolutamente immaginare che sia questo il caso. Considerando che, tra tutte le aree delle Preferenze GP e tutte le aree che utilizzano ntuser.pol, tra cui Admin Templates, AppLocker, Windows Firewall, Public Key Policy e probabilmente altre che mi sfuggono, potrebbe essere stato necessario esaminare un sacco di codice per assicurarsi che lo spostamento di quei file non rompesse tutto. Non mi sorprenderebbe se, prima che tutto questo finisca, venisse fuori qualche falla in qualche angolo oscuro della policy. Tuttavia, si è trattato di un exploit interessante, reso ancora più interessante da alcuni difetti vecchi di 20 anni che GP ha portato alla festa.
Siete interessati a saperne di più sulla gestione dei Criteri di gruppo tenendo conto della sicurezza? Guardate il nostro webinar che riassume i quasi quattro anni di ricerche che ho condotto sui vari modi in cui gli aggressori sfruttano i Criteri di gruppo. Ma soprattutto, vi illustrerò i passi fondamentali che potete compiere per difendere il vostro ambiente GP, e quindi il vostro ambiente Windows, dagli abusi. Spero di vedervi lì.
