L’introduzione, circa un anno e mezzo fa, dell’opzione “–l” in PsExec (programma che fa parte di PsTools di Sysinternals, acquisita recentemente da Microsoft) ha consentito di eseguire processi su Windows XP con diritti utente standard, a partire da un account amministrativo.
Un processo eseguito con questo tipo di contesto di sicurezza ha i privilegi e gli accessi di un account utente standard, che gli impedisce di modificare i files di sistema e le chiavi di Registro o di esercitare privilegi, come caricare un device driver, che solo l’amministratore può effettuare.
C’è soltanto un ostacolo alla sandbox virtuale che questo restricted token crea: i processi che sono eseguiti nella sandbox appartengono all’account utente che li ha avviati, e pertanto possono leggere e scrivere qualunque file, chiave di Registro, ed anche eseguire altri processi a cui l’account ha accesso.
Questo particolare crea importanti varchi nel muro della sandbox, ed il codice maligno scritto tenuto conto dell’ambiente di sicurezza ristretta potrebbe trarre vantaggio da essi per sfuggire e diventare amministratore a tutti gli effetti. Ad esempio il malware potrebbe usare OpenProcess per avere accesso ad uno dei processi di cui l’account è Owner e che girano al di fuori della sandbox, ed iniettare in esso il codice da eseguire.
Poiché questi altri processi girano sotto l’account di partenza, e poiché il modello di sicurezza di Windows crea permessi di default che garantiscono a tale account un accesso completo ai processi che appartengono ad esso, un processo eseguito nella sandbox sarà in grado di aprirli.
Un'altra possibilità è data dal fatto di poter inviare window messages dal processo in sandbox ad un processo standard, come Explorer, e guidare tale processo tramite input simulato da mouse e tastiera, in modo che esso esegua il codice sotto il controllo del malware.
Data la presenza di queste falle, perché è consigliabile usare l’opzione di PsExec per eseguire processi con diritti limitati su Windows XP se si sta utilizzando un account di amministrazione invece di un account utente standard ? Sulla base del fatto che tale sandbox non è molto usata, e gli autori di malware non si preoccupano di scrivere il codice necessario a sfuggire alla restrizione e quindi i processi continuano ad essere eseguiti nella sandbox.
Windows Vista ha cambiato tutto ciò, perché usa una modalità evoluta di sandbox nello User Account Control (UAC) e nella Modalità Protetta di Internet Explorer (Protected Mode IE). Ora vediamo come funziona la versione della sandbox di Vista, come consente di eseguire programmi all’interno di essa, ed esploriamo le implicazioni collegate con la sicurezza.
UAC crea un modello alternativo dove tutti gli utenti, inclusi gli amministratori, hanno diritti utente standard. Gli eseguibili che necessitano dei diritti amministrativi, includono una chiave requestedExecutionLevel nel loro manifesto – XML incorporato nell’eseguibile – che specifica “requireAdministrator”. Quando un amministratore esegue tale programma, nella sua configurazione UAC di default viene visualizzata una finestra di Consenso che richiede il permesso affinché l’eseguibile giri con diritti amministrativi.
Gli utenti standard vedono una finestra di dialogo simile, ma devono inserire le credenziali dell’account amministrativo per sbloccare i diritti di amministrazione.
L'atto di conferire diritti amministrativi ad un eseguibile è chiamato “elevation” nell’UAC. Sia che ci sia una elevation da un account utente standard (cosiddetta OTS – Over The Shoulder elevation) oppure da un account amministrativo (AAM – Admin Approval Mode elevation), vengono comunque creati processi che hanno diritti amministrativi sullo stesso desktop in cui si trovano i processi che hanno diritti di utente standard.
I processi elevati da un account utente standard girano sotto un account differente da quelli che utilizzano i diritti utente standard, per cui il modello di sicurezza di Windows definisce un perimetro attorno al processo “elevato” che impedisce ai processi non-elevati di scrivere codice in esso. In ogni caso, il modello di sicurezza standard di Windows non impedisce ai processi non-elevati di inviare input fasullo ai processi elevati, né crea una sandbox attorno ai processi non-elevati degli utenti amministrativi per impedire ad essi di compromettere i processi “elevati”. Windows Vista introduce quindi il meccanismo di Windows Integrity, che fornisce un ulteriore schermo alla sandbox che circonda i processi con minori privilegi.
Nel modello di integrità di Vista, ogni processo gira ad un determinato livello di integrità (IL – Integrity Level) ed ogni oggetto ha un livello di integrità. I livelli di integrità principali sono basso, medio (default), alto (per i processi “elevati”) e system. Il sistema rispetta i livelli di integrità per impedire che i processi a basso IL inviino window messages alle windows possedute dai processi ad alto IL, chiamando tale protezione UIPI User Interface Privilege Isolation. Il modello di sicurezza inoltre cambia in Vista per consentire ad un processo di aprire un oggetto con accesso in scrittura solo se l’IL del processo è uguale o più alto di quello dell’oggetto. Inoltre, per impedire l’accesso a dati riservati presenti in memoria, i processi non possono aprire in lettura processi con IL più alto.
Se si aggiunge la colonna di Integrity Level al display di Process Explorer, come mostrato in figura, si può vedere che i processi di sistema, inclusi i processi dei servizi di Window, girano con IL System. Molti processi della sessione di logon girano con IL Medium, qualunque processo “elevato” gira con IL High, mentre Internet Explorer gira con IL Low quando Protected Mode è abilitato. Si può usare l’utility icacls.exe di Windows per vedere e modificare gli IL dei files e delle directory, mentre AccessChk (di Sysinternals) mostra gli IL dei files, delle directory, delle chiavi di registro e dei processi. Gli oggetti hanno un IL di default impostato a Medium, ma l’opzione AccessChk –e consente di trovare gli oggetti che hanno un IL esplicito.
La nuova versione di PsExec si avvantaggia della sandbox avanzata di Vista quando si specifica l’opzione “‑l”, eseguendo il programma specificato con un token dell’utente standard a basso IL. La sandbox che PsExec crea è pressoché identica a quella che circonda il Protected Mode IE e si possono verificare i limiti di tale protezione lanciando il prompt dei comandi oppure Regedit a basso IL e constatando cosa è possibile modificare. Per esempio, ho lanciato il prompt dei comandi come visibile in basso con basso IL con il comando : psexec –l –d cmd.exe
Man mano che si sperimenta si troverà che le azioni ammesse sono limitate, ma ci sono alcune limitazioni di progetto di cui occorre essere al corrente. Innanzitutto, ad eccezione di processi e threads, la protezione non blocca le letture. Questo significa che il vostro prompt dei comandi con IL basso o Protected Mode IE può leggere oggetti consentiti al vostro account (la versione utente standard, qualora siate membri del gruppo di amministrazione). Ciò include in teoria i documenti di un utente e le sue chiavi di registro.
Non è neppure impedita la capacità di un processo a basso IL di manipolare oggetti a più alto IL. Poiché i processi che lavorano a differenti integrità condividono lo stesso desktop, essi condividono la stessa “sessione”. Ogni logon utente dà luogo ad una nuova sessione in cui vengono eseguiti i processi di quell’utente. La sessione inoltre definisce uno spazio dei nomi (namespace) locale attraverso cui i processi dell'utente possono comunicare usando oggetti condivisi (shared objects), come ad esempio gli oggetti di sincronizzazione e la memoria condivisa. Questo significa che un processo con un IL basso potrebbe creare un oggetto in memoria condivisa (denominata una sezione o file mappato in memoria), il quale (oggetto) sarà utilizzato da un processo ad IL maggiore, e memorizzare dati in memoria che determino l’esecuzione di codice arbitrario da parte del processo “elevato”, se il processo “elevato” non effettua una validazione dei dati. Questa metodologia, denominata “squatting attack”, è sofisticata, richiede che l’utente avvii processi in un determinato ordine e necessita la conoscenza dell’operazione interna di un’applicazione che sia manipolabile mediante oggetti condivisi.
Tuttavia, al di là della difficoltà dell’attacco, la sola possibilità teorica di una tale falla nella sandbox implica che gli IL di per se stessi non definiscono dei contesti di sicurezza. Cosa è un contesto di sicurezza? Si tratta di un filtro attraverso cui i dati ed il codice non possono passare senza l’autorizzazione di una Security Policy. Ad esempio, gli account utente che girano in sessioni separate sono tenuti distinti dal contesto di sicurezza di Windows. Un utente non dovrebbe essere in grado di leggere o modificare i dati di un altro utente, né di consentire l’esecuzione di codice senza l’autorizzazione dell’altro utente. Se per qualche ragione fosse possibile bypassare le Security Policy, significherebbe che ci troviamo di fronte ad un bug di sicurezza in Windows ( o del software di terze parti che lo ha consentito).
Dovrebbe quindi essere chiaro che né l’elevazione UAC né il Protected Mode IE definiscono nuovi vincoli di sicurezza. Inoltre, Vista implementa un compromesso fra sicurezza ed usabilità, e sia UAC che il Protected Mode IE contengono scelte di progetto che necessitano di aperture nel modello IL affinché ci sia una compatibilità fra le applicazioni e una buona facilità d’uso.
Ad esempio, consentire ai processi “elevati” AAM di essere eseguiti con lo stesso account degli altri processi non-elevati, è conveniente affinché i processi “elevati” possano avere accesso ai dati ed al codice di quell’account utente, ma allo stesso tempo consente ai processi non-elevati di modificare quegli stessi dati e codice, con la possibilità di causare l’esecuzione di codice arbitrario da parte di un processo “elevato”.
Poiché l’elevazione dei permessi e gli IL non definiscono un contesto di sicurezza, l’eventuale verificarsi di un attacco – al di là della facilità e dell’ampiezza – non costituisce un bug di sicurezza. Quindi, se non c’è garanzia che i processi “elevati” non siano soggetti a compromissione da parte di quelli che girano a più basso IL, perché Vista ha introdotto l’elevazione dei permessi e gli IL ? Per creare una ambiente in cui tutti utilizzano un account standard di default e tutto il software è scritto sulla base di tale presupposto.
Senza la convenienza dell’elevazione dei permessi avremmo continuato a lavorare nel modo in cui siamo stati abituati con le precedenti versioni di Windows: vale a dire con diritti amministrativi per tutto il tempo.
La Modalità Protetta di IE e l’opzione PsExec –l si avvantaggiano degli IL per creare una sandbox intorno al malware che riesce a superare le altre difese. Le sandbox create dall’elevazione dei permessi e dal Protected Mode IE possono essere attaccati in alcuni modi, ma sono senz’altro meglio della mancanza di una qualunque sandbox.
Se per voi la sicurezza è più rilevante dell’usabilità, potete incrementare i vincoli di sicurezza usando differenti account utente: uno standard per le attività comuni, passando poi agli account utente dedicati alla navigazione non-sicura ed alle attività amministrative.
