The Power in Power Users

Pubblicato per la prima volta su TechNet a maggio 01, 2006

Posizionare gli account utente di Windows nel gruppo Power Users Security è un approccio comune che le organizzazioni IT adottano per ottenere gli utenti in un ambiente con privilegi minimi evitando i molti problemi di correre veramente come utente limitato. Il gruppo Power Users è in grado di installare il software, gestire le impostazioni di potenza e fuso orario e installare i controlli ActiveX, azioni che gli utenti limitati vengono negati.
Ciò che molti amministratori non riescono a capire, tuttavia, è che questo potere ha il prezzo di una vera sicurezza per utenti limitati. Molti articoli, tra cui questo articolo della Microsoft Knowledge Base e questo post sul blog di Microsoft security specialist Jesper Johansen, che un utente che appartiene al gruppo Power Users può facilmente elevarsi completamente privilegiato gli amministratori, ma non sono riuscito a trovare una descrizione dettagliata dei meccanismi di elevazione di riferimento. Ho quindi deciso di indagare.
Prima di poter iniziare l’indagine, ho dovuto definire il problema. In assenza di una falla di sicurezza come un buffer overflow, l’escalation dei privilegi è possibile solo se un account può configurare codice arbitrario da eseguire nel contesto di un account con più privilegi. Gli account predefiniti che dispongono di più privilegi rispetto agli utenti esperti includono gli amministratori e l’account di sistema locale, in cui vengono eseguiti diversi processi di servizio Windows. Pertanto, se un membro di Power Users può modificare un file eseguito da uno di questi account, configurare uno dei loro eseguibili per caricare una DLL arbitraria o aggiungere un avvio automatico eseguibile a questi account, può ottenere privilegi amministrativi completi.
Il mio primo passo è stato vedere quali file e directory a cui il gruppo Power Users ha accesso in scrittura, ma che gli utenti limitati non lo fanno. I sistemi che ho considerato erano di serie Windows 2000 Professional SP4, Windows XP SP2 e Windows Vista. Non mi preoccuperò di guardare i sistemi server perché lo scenario di utenti esperti più comune è su una workstation.
Il metodo della forza bruta per vedere quali oggetti del file system gli utenti esperti possono modificare richiede di visitare ogni file e directory ed esaminare i suoi permessi, qualcosa che non è chiaramente pratico. L’utilità Cacls della riga di comando che Windows include scarica i descrittori di sicurezza, ma non mi sono mai preoccupato di imparare il linguaggio di descrizione del descrittore di sicurezza (SDDL) e l’analisi dell’output richiederebbe la scrittura di uno script. L’utilità AccessEnum che Bryce ha scritto sembrava promettente e può anche guardare alla sicurezza del Registro, ma ha lo scopo di mostrare potenziali debolezze delle autorizzazioni, non gli accessi disponibili a determinati account. Inoltre, sapevo che avrei anche bisogno di esaminare la sicurezza applicata ai servizi di Windows.

Ho concluso che dovevo scrivere una nuova utility per il lavoro, quindi ho creato AccessChk . Si passa AccessChk un nome di account o gruppo e un percorso del file system, chiave di registro, o il nome del servizio di Windows, e segnala gli accessi effettivi l’account o il gruppo ha per l’oggetto, tenendo conto di appartenenza al gruppo dell’account. Ad esempio, se l’account Mark aveva accesso a un file, ma Mark appartiene al gruppo di sviluppatori a cui è esplicitamente negato l’accesso, AccessChk mostrerebbe Mark come senza accesso.
Per rendere l’output facile da leggere AccessChk stampa ‘W’ accanto al nome dell’oggetto se un account dispone di autorizzazioni che gli consentirebbero di modificare un oggetto e ‘R’ se un account può leggere i dati o lo stato dell’oggetto. Vari switch fanno sì che AccessChk ricorra in sottodirectory o sottochiavi del Registro e l’interruttore –v segnala gli accessi specifici disponibili per l’account. Un interruttore che ho aggiunto specificamente per cercare oggetti per i quali un account ha accesso in scrittura è –w.
Armato di questo nuovo strumento Ero pronto per iniziare a indagare. Il mio primo obiettivo era un’installazione VMware di Windows XP SP2 che non ha applicazioni installate diverse dagli strumenti VMware. Il primo comando che ho eseguito è stato:
accesschk –ws “power users” c:\windows
Mostra tutti i file e le directory nella directory \Windows che il gruppo Power Users può modificare. Naturalmente, molti dei file in \ Windows fanno parte del sistema operativo o dei servizi Windows e quindi vengono eseguiti nell’account di sistema locale. AccessChk ha riferito che gli utenti esperti possono modificare la maggior parte delle directory in \Windows, che consente agli utenti membri di creare file in tali directory. Pertanto, un membro del gruppo Power Users può creare file nella directory \Windows e\Windows \ System32, che è un requisito comune per le applicazioni legacy scritte male. Inoltre, gli utenti esperti devono essere in grado di creare file nella directory \Windows\Downloaded Program Files in modo che possano installare i controlli ActiveX, poiché Internet Explorer li salva in quella directory. Tuttavia, la semplice creazione di un file in queste directory non è un percorso per l’elevazione dei privilegi.
Nonostante gli utenti esperti possano creare file sotto \Windows e la maggior parte delle sue sottodirectory, Windows configura le autorizzazioni di sicurezza predefinite sulla maggior parte dei file contenuti in queste directory in modo che solo i membri del gruppo Administrators e l’account di sistema locale abbiano accesso in scrittura. Le eccezioni includono i file di font (.fon), molti file di registro di sistema (.log), alcuni file di aiuto (.chm), immagini e clip audio (.jpg, .gif, e .wmv) e file di installazione (.inf), ma nessuno di questi file può essere modificato o sostituito per ottenere privilegi amministrativi. I driver di periferica in\Windows\System32 \ Drivers consentirebbero una facile escalation, ma gli utenti esperti non hanno accesso in scrittura a nessuno di essi.

Ho visto un numero di .exe e .dll è nella lista, però, così li ho esaminati per possibili exploit. La maggior parte degli eseguibili per i quali Power Users ha accesso in scrittura sono utilità interattive o eseguite con privilegi ridotti. A meno che non si possa ingannare un amministratore nell’accedere al sistema in modo interattivo, questi non possono essere utilizzati per elevare. Ma c’è un’eccezione lampante: ntoskrnl.exe:

Proprio così, gli utenti esperti possono sostituire o modificare il file del sistema operativo di base di Windows. Cinque secondi dopo la modifica del file, tuttavia, Windows File Protection (WFP) lo sostituirà con una copia di backup che recupera, nella maggior parte dei casi, da \Windows\System32\Dllcache. Gli utenti esperti non hanno accesso in scrittura ai file in Dllcache, quindi non possono sovvertire la copia di backup. Ma i membri del gruppo Power Users possono aggirare il WFP scrivendo un semplice programma che sostituisce il file, svuota i dati modificati su disco, quindi riavvia il sistema prima che il WFP agisca.
Ho verificato che questo approccio funziona, ma la domanda è rimasta su come questa vulnerabilità può essere utilizzata per elevare i privilegi. La risposta è semplice come usare un disassemblatore per trovare la funzione utilizzata da Windows per i controlli dei privilegi, SeSinglePrivilegeCheck e applicare le patch al suo punto di ingresso nell’immagine su disco in modo che restituisca sempre TRUE, che è il codice risultato che indica che un utente ha il privilegio controllato. Una volta che un utente è in esecuzione su un kernel modificato in questo modo sembreranno avere tutti i privilegi, tra cui Caricare Driver, prendere la proprietà e creare Token, per citarne solo alcuni dei privilegi che possono facilmente sfruttare per assumere il pieno controllo amministrativo di un sistema. Sebbene Windows XP a 64 bit impedisca la manomissione del kernel con PatchGuard, poche aziende sono in esecuzione su Windows a 64 bit.
Sostituzione Ntoksrnl.tuttavia, exe non è l’unico modo per accedere ai privilegi amministrativi tramite la directory \Windows. Almeno una delle DLL per le quali le autorizzazioni predefinite consentono la modifica da parte dell’utente esperto, Schedsvc.dll, viene eseguito come servizio Windows nell’account di sistema locale. Schedsvc.dll è la DLL che implementa il servizio di pianificazione delle attività di Windows. Windows può funzionare correttamente senza il servizio in modo che gli utenti esperti possano sostituire la DLL con una DLL arbitraria, ad esempio una che aggiunge semplicemente il proprio account al gruppo Amministratori locali. Naturalmente, il WFP protegge anche questo file, quindi la sua sostituzione richiede l’uso della tecnica di bypass del WFP che ho descritto.

Avevo già identificato diversi vettori di elevazione, ma ho continuato la mia indagine esaminando l’accesso degli utenti esperti alla directory \Program Files in cui ho trovato autorizzazioni predefinite simili a quelle nella directory \Windows. Gli utenti esperti possono creare sottodirectory in \ Program Files, ma non possono modificare la maggior parte dei componenti di Windows preinstallati. Ancora una volta, le eccezioni, come Windows Messenger (\Program Files \ Messenger \ Msmgs.exe) e Windows Media Player (\Programmi \ Windows Media Player \ Wmplayer.exe) eseguire in modo interattivo.
Ciò non significa che \Program Files non abbia potenziali buchi. Quando ho esaminato l’output più recente ho visto che gli utenti esperti possono modificare qualsiasi file o directory creata in \Program Files successivi a quelli creati durante l’installazione di Windows di base. Sul mio sistema di test \ Program Files \ Vmware \ Vmware Tools \ Vmwareservice.exe, il file immagine per il servizio Vmware Windows che viene eseguito nell’account di sistema locale, era un file di questo tipo. Un altro esempio un po ‘ ironico è Microsoft Windows Defender Beta 2, che installa il suo servizio eseguibile in \Program Files\Windows Defender con le impostazioni di sicurezza predefinite. La sostituzione di questi file di immagine del servizio è un percorso rapido per privilegi di amministratore ed è ancora più facile che sostituire i file nella directory \Windows perché WFP non si immischia con le sostituzioni.
Successivamente ho rivolto la mia attenzione al Registro eseguendo questo comando:
accesschk-swk” power users ” hklm
L’elenco di output era enorme perché Power Users ha accesso in scrittura alla stragrande maggioranza della chiave HKLM \ Software. La prima area che ho studiato per possibili elevazioni è stata la chiave HKLM\System, perché l’accesso in scrittura a molte impostazioni sottostanti, come il servizio di Windows e le chiavi di configurazione del driver in HKLM\System\CurrentControlSet\Services, consentirebbe la sovversione banale dell’account di sistema locale. L’analisi ha rivelato che gli utenti esperti non hanno accesso in scrittura a nulla di significativo sotto quella chiave.
La maggior parte degli utenti esperti-aree scrivibili sotto l’altro ramo importante di HKLM, Software, relativi a Internet Explorer, Explorer e le sue associazioni di file, e la configurazione di gestione dell’alimentazione. Power Users ha anche accesso in scrittura a HKLM \ Software \ Microsoft \ Windows \ CurrentVersion \ Run, consentendo loro di configurare eseguibili arbitrari da eseguire ogni volta che qualcuno accede in modo interattivo, ma sfruttando questo richiede un utente con privilegio amministrativo per accedere al sistema in modo interattivo (che, a seconda del sistema, potrebbe non accadere mai, o accadere di rado). E proprio come per la directory \Program Files, Power Users ha accesso in scrittura predefinito a sottochiavi non Windows di HKLM\Software, il che significa che le applicazioni di terze parti che configurano percorsi di codice eseguibili nelle loro chiavi di registro a livello di sistema potrebbero aprire falle di sicurezza. VMware, l’unica applicazione installata sul sistema, non l’ha fatto.

La restante area di esplorazione era Windows services. Le uniche autorizzazioni di servizio che AccessChk considera come accessi in scrittura sono SERVICE_CHANGE_CONFIG e WRITE_DAC. Un utente con SERVICE_CHANGE_CONFIG può configurare un eseguibile arbitrario da avviare all’avvio di un servizio e dato WRITE_DAC può modificare le autorizzazioni su un servizio per concedersi l’accesso SERVICE_CHANGE_CONFIG. AccessChk ha rivelato quanto segue sul mio magazzino sistema Windows XP SP2:

Successivamente ho eseguito PsService per vedere l’account in cui viene eseguito il servizio DcomLaunch:

Pertanto, i membri del gruppo Power Users possono semplicemente modificare il percorso dell’immagine di DComLauncher per puntare alla propria immagine, riavviare il sistema e godere dei privilegi amministrativi.
Potenzialmente possono esserci altri servizi che introducono exploit nella loro sicurezza. Le autorizzazioni predefinite impostate da Windows sui servizi creati da applicazioni di terze parti non consentono agli utenti esperti l’accesso in scrittura, ma alcune applicazioni di terze parti potrebbero configurare autorizzazioni personalizzate per consentire loro di farlo. Infatti, sulla mia produzione a 64 bit di installazione di Windows XP AccessChk rivela un buco che non solo gli utenti esperti possono utilizzare per elevare se stessi, ma che gli utenti limitati possono pure:

Avevo ora finito la fase principale della mia indagine e appena confermato quello che tutti hanno detto: un determinato membro del gruppo Power Users può abbastanza facilmente farsi amministratore completo utilizzando exploit nel sistema operativo e quelli creati da applicazioni di terze parti.
Il mio ultimo passo è stato vedere come l’approccio di Microsoft all’account Power Users si è evoluto nel tempo. Questo articolo di Microsoft Knowledge Base del 1999 documenta la famosa vulnerabilità di elevazione dello screen-saver che esisteva su Windows NT 4, ma Microsoft ha chiuso quel buco prima del rilascio di Windows 2000. L’articolo KB mostra anche che Microsoft era apparentemente inconsapevole di altre vulnerabilità che probabilmente esistevano. Windows 2000 SP4 include anche fori, ma in realtà è leggermente più sicuro rispetto alla configurazione predefinita di Windows XP SP2: gli utenti esperti non hanno accesso in scrittura a Ntoskrnl.file di immagine dell’utilità di pianificazione, ma invece di accesso in scrittura al servizio DComLauncher possono sovvertire il servizio WMI, che viene eseguito anche nell’account di sistema locale.
Windows XP SP1 ha aggiunto più punti deboli degli utenti esperti, incluso l’accesso in scrittura a file di sistema critici come Svchost.exe, il processo di hosting del servizio di Windows e servizi aggiuntivi, WMI e SSDPSRV, con autorizzazioni sfruttabili. Diversi servizi hanno anche permesso agli utenti limitati di elevare come descritto in questo articolo di Microsoft KB da marzo di quest’anno.
Il nuovo sistema operativo di Microsoft, Windows Vista, chiude tutte le vulnerabilità che ho descritto castrando gli utenti esperti in modo che si comporti in modo identico agli utenti limitati. Microsoft ha quindi chiuso la porta agli utenti esperti per costringere il personale IT a proteggere i propri sistemi spostando gli utenti in account utenti limitati o in account amministrativi in cui devono riconoscere il controllo dell’utente finale sui propri sistemi.
La linea di fondo è che mentre Microsoft potrebbe correggere le vulnerabilità che ho trovato nella mia indagine, non possono impedire alle applicazioni di terze parti di introdurne di nuove, preservando allo stesso tempo la capacità degli utenti esperti di installare applicazioni e controlli ActiveX. La lezione è che come amministratore IT non dovresti ingannare te stesso nel pensare che il gruppo Power Users sia un compromesso sicuro sulla strada per l’esecuzione come utente limitato.

Originariamente di Mark Russinovich il 5/1/2006 11: 01: 00 AM
Migrato dall’originale Sysinternals.com/Blog