Una notizia [1] pubblicata qualche giorno fa su SecuriTeam [2] ha riproposto un problema piuttosto grave che interessa l'applicazione degli oggetti GPO in Active Directory. Non vi sto certamente parlando di una novità, la sicurezza degli Oggetti Group Policy è stata già messa in discussione più volte ed il fatto che esistano alcune tecniche di programmazione che permettano di aggirarne l'applicazione è un fatto ormai assodato da qualche anno.
Perché quindi preoccuparsene proprio ora?
Forse non tutti hanno avuto modo di venire a conoscenza del fatto che in questi giorni è stato reso pubblico un nuovo strumento [3] pronto ad aiutare gli utenti a bypassare le Group Policy, per questo motivo credo che ora più di prima gli amministratori debbano essere informati sui rischi che potrebbero incombere sulla loro rete.
Premessa
Come ogni altra tecnologia particolarmente complessa anche gli oggetti Group Policy hanno rivelato in questi anni alcune problematiche legate alla loro implementazione, da un punto di vista strettamente legato all'ambito della sicurezza non è certamente impensabile il fatto che, poiché essi agiscono sul lato client dell'infrastruttura di rete, la loro effettiva applicazione possa essere facilmente aggirata dall'utente.
In realtà già nel 2004 era apparso in rete un tutorial [4] nel quale veniva spiegato un metodo che rendeva possibile agli sviluppatori di intercettare alcune funzioni di Windows utilizzando la liberaria detours [5], come esempio vennero prese in esame proprio le impostazioni Group Policy.
Qualche tempo dopo, nel 2005, Mark Russinovich [6] pubblicò sul suo blog Sysinternals la segnalazione di un suo articolo [7] che fu accompagnata da uno strumento denominato GPDisable [8] che mirava a dimostrare come fosse possibile bypassare le Software Restriction Policies configurate tramite oggetti Group Policy. Dopo l'acquisizione di Sysinternals [9] da parte di Microsoft tale segnalazione sembra però essere stata eliminata.
Russinovich riprese poi l'argomento nel 2006 [10] affermando che gran parte delle configurazioni disponibili nella sezione Componenti di Windows / Modelli Amministrativi, presente nell'Editor degli Oggetti Group Policy, possono essere facilmente aggirate se viene concessa all'utente la facoltà di eseguire arbitrariamente qualsiasi tipo di applicazione (come appunto il programma GPDisable [8] da lui realizzato). Questa possibilità di aggirare i GPO non deriva però da un bug del sistema operativo, Windows è stato coscientemente disegnato per permetterlo, si tratta semplicemente di una problematica derivante da scelte che sono state fatte in sede di design della sua architettura.
Ma torniamo al presente... pochi giorni fa Eric Rachner [11] ha deciso di rendere pubblico GPcul8r [3], uno strumento che, utilizzando lo stesso identico approccio del suddetto GPDisable [8], permette ad un utente limitato di aggirare alcune configurazioni Group Policy imposte dal Dominio Active Directory.
La versione precompilata di GPcul8r è poco più di un Proof Of Concept, le sue funzionalità non sono molte e non è nemmeno configurabile, però è possibile reperirne il codice sorgente [3] e personalizzarlo a proprio piacimento... per questo motivo penso che sia molto importante conoscere il problema, ed è proprio questo ciò che ora andrò a descrivervi.
Dimostrazione tecnica
Precisato inanzitutto che buona parte delle Group Policy sono rappresentate da valori di registro, potremmo dire che l'approccio utilizzato per aggirarle è molto simile a quello impiegato dai rootkit [12]: il tutto ruota attorno alla possibilità di iniettare una libreria arbitraria all'interno di un processo avviato dall'utente, tale libreria si occuperà poi di intercettare e modificare le chiamate che questo processo farà al registro di sistema modifcandone così anche il comportamento.
Come mai un utente limitato ha la possibilità di iniettare librerie arbitrarie in un processo?
La risposta è semplice: in Windows, come dimostra il seguente screenshot, il proprietario di un processo ha pieni diritti su di esso
[13]Qui sotto potete vedere il risultato dell'applicazione di una Software Restriction Policy che previene l'utilizzo di notepad.exe
[14]L'utente non è autorizzato ad eseguire notepad.exe, ma cosa succederebbe se provassimo ad eseguirlo tramite lo strumento GPDisable [8] che Russinovich ha scritto nel 2005? Il blocco note verrà eseguito senza problemi.
[15]Grazie a Process Explorer [16] possiamo verificare quanto è accaduto
[17]GPDisable [8] ha iniettato gpdisable.dll all'interno del processo notepad.exe, questa dll si occupa di intercettare tutte le chiamate che il sistema farà all'API NtQueryValueKey; tale API è infatti utilizzata dal sistema Software Restriction Policies di Microsoft ed in questo caso verrà utilizzata all'avvio di notepad per controllare il valore di registro
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers\TransparentEnabled
Questo controllo ha lo scopo di verificare se siano in vigore delle regole di restrizione software.
Il comportamento appena descritto può essere facilmente dimostrato utilizzando Regmon [18]
[19]L'utente limitato non ha il diritto di modificare queste chiavi di registro ma ciò non costituisce un problema poiché la chiamata presa in esame verrà intercettata da GPDisable [8] e la reale risposta non raggiungerà mai il kernel.
Questo metodo non è però applicabile soltanto alle politiche di restrizione software, infatti grazie al più recente Gpcul8r possiamo facilmente dimostrare anche come sia possibile aggirare altre configurazioni Group Policy, ad esempio quelle relative al proxy utilizzato da Internet Explorer oppure la disabilitazione del TaskManager.
Ecco come compaiono nel registro di sistema le suddette GPO, la prima si occupa appunto di forzare il proxy su Internet Explorer e la seconda di disabilitare il TaskManager
[20]
[21]Se provassimo quindi ad eseguire il TaskManager, il sistema ci avvertirebbe che esso è stato disabilitato dall'amministratore
[22]Il risultato cambia però radicalmente se proviamo ad aprire TaskManager utilizzando Gpcul8r
[23]Ed ecco l'ultima dimostrazione, l'utente non può disabilitare, nelle impostazioni di Internet Explorer, l'opzione che lo obbliga a connettersi attraverso un server proxy
[24]Ed ecco invece il risultato ottenuto utilizzando GPCul8r
[25]
[26]L'autore di Gpcul8r nel readme allegato ci informa del fatto che se l'utente avesse diritti amministrativi sul sistema potrebbe anche aggiungere la libreria Gpcul8r.dll alla seguente chiave
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs
questa operazione farebbe in modo che l'intercettazione delle API di sistema avvenga in maniera predefinita per qualsiasi applicazione avviata.
Non va comunque dimenticato il fatto che qualora l'utente avesse diritti amministrativi permanenti sul sistema avrebbe la facoltà di disabilitare qualsiasi policy attraverso la modifica manuale del registro di sistema, qualcuno ha anche già pubblicato un breve whitepaper a riguardo [27].
Autore
Mirko Iodice
mirko -at- notageek (.dot) it