Quanto sono sicure le Group Policy? – How secure is Group Policy?

Una notizia pubblicata qualche giorno fa su SecuriTeam 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 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.

unlock2.jpg

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 nel quale veniva spiegato un metodo che rendeva possibile agli sviluppatori di intercettare alcune funzioni di Windows utilizzando la liberaria detours, come esempio vennero prese in esame proprio le impostazioni Group Policy.

Qualche tempo dopo, nel 2005, Mark Russinovich pubblicò sul suo blog Sysinternals la segnalazione di un suo articolo che fu accompagnata da uno strumento denominato GPDisable che mirava a dimostrare come fosse possibile bypassare le Software Restriction Policies configurate tramite oggetti Group Policy. Dopo l'acquisizione di Sysinternals da parte di Microsoft tale segnalazione sembra però essere stata eliminata.

Russinovich riprese poi l'argomento nel 2006 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 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 ha deciso di rendere pubblico GPcul8r, uno strumento che, utilizzando lo stesso identico approccio del suddetto GPDisable, 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 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: 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

gpbypass1.PNG


Qui sotto potete vedere il risultato dell'applicazione di una Software Restriction Policy che previene l'utilizzo di notepad.exe

gpbypass2.PNG


L'utente non è autorizzato ad eseguire notepad.exe, ma cosa succederebbe se provassimo ad eseguirlo tramite lo strumento GPDisable che Russinovich ha scritto nel 2005? Il blocco note verrà eseguito senza problemi.

gpbypass3.PNG


Grazie a Process Explorer possiamo verificare quanto è accaduto

gpbypass4.PNG


GPDisable 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

gpbypass5.PNG


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 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

gpbypass6.PNG
gpbypass7.PNG


Se provassimo quindi ad eseguire il TaskManager, il sistema ci avvertirebbe che esso è stato disabilitato dall'amministratore

gpbypass8.PNG


Il risultato cambia però radicalmente se proviamo ad aprire TaskManager utilizzando Gpcul8r

gpbypass9.PNG


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

gpbypass10.PNG


Ed ecco invece il risultato ottenuto utilizzando GPCul8r

gpbypass11.PNG
gpbypass12.PNG


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.

Autore

Mirko Iodice
mirko -at- notageek (.dot) it

Print This Email this Twit This! Add to del.icio.us Share on Facebook Digg This! Stumble It! AddThis! Share on Segnalo Alice Share on OKNotizie

Post Metadata

Data
12 dicembre 2007

Autore
Mirko

Categorie

2 commenti a “Quanto sono sicure le Group Policy? – How secure is Group Policy?”




  1. ..Brividi..
    Nella mia rete aziendale (sono un sysadmin)
    ho notato che qualche furbetto riesce occasionalemnte ad aggirare le gpo:
    il dubbio è che in fase di avvio della macchina scolleghino il cavo di rete..Il fine è quello della navigazione senza freni...:)
    Anche se succede raramente, questo mi disturba un pò.
    Domanda:
    Nella nuova versione di Windows Server 2008 per le gpo verrà usato lo stesso approcio? ci sono dei cambiamenti a livello di funzionamento?

    Grazie in anticipo

    Rispondi



  2. Ciao,
    non ho ancora avuto modo di utilizzare Windows Server 2008 percui non ti so dire se il funzionamento delle GPO abbia subìto drastici cambiamenti.
    Sono in attesa di poter leggere qualche documentazione ufficiale a riguardo (sperando che sia esaustiva) ma in ogni caso, al fine di risolvere questo tipo di problematiche, credo che l'approccio dovrebbe cambiare non tanto sul lato server ma quanto su quello client (Windows Vista, Windows 7)... alla fine è il sistema operativo client che si occupa di interpretare e applicare le politiche di gruppo.

    In merito alla tua problematica specifica mi piacerebbe darti una idea: potresti avviare il servizio telnet sulle macchine incriminate e, attraverso quest'ultimo, eseguire un "gpupdate /force" per forzare l'applicazione istantanea degli oggetti GPO.
    Nel caso in cui avessi la necessità di eseguire tale operazione su tanti computer psexec può sicuramente esserti d'aiuto.

    Rispondi


2 Trackbacks/Pingbacks

  1. Quanto sicure sono le GPO? | il blog di Massi 08 09 08
  2. GPO - sono bypassabili ? | hilpers 17 01 09

Lascia un commento