La scelta di misure di sicurezza per la protezione del sistema operativo non passa soltanto attraverso l’utilizzo di specifici software quali, ad esempio, antivirus e firewall, ma anche indirettamente tramite la scelta del browser con il quale poter navigare.
Dando uno sguardo ai dati relativi alla diffusione negli ultimi due anni dei cinque principali browser si evince chiaramente il successo che Google Chrome ha ottenuto dal 2008, anno del suo rilascio, ad oggi e che lo porta ad essere attualmente il browser maggiormente utilizzato.
Browser share
Negli ultimi anni i browser si sono trasformati sempre più da semplici parser HTML ad applicativi multifunzione sempre più complessi, costretti ad interagire con svariate tecnologie di terze parti, plugin vari necessari per poter riprodurre i diversi formati presenti ad oggi nel web – Adobe Flash, Microsoft Silverlight, Oracle Java sono solo alcuni esempi.
La sicurezza di un browser non è quindi data soltanto dalla stabilità del proprio codice – sebbene questa ricopra un ruolo di primaria importanza – ma anche da quella dei plugin installati. Una falla nel plugin di Abode Flash, ad esempio, potrebbe compromettere la sicurezza dell’intero sistema, a meno che il browser non sia pronto a gestire tale eventualità. Eventualità, questa, tutt’altro che remota ma che è, anzi, predominante negli attacchi da remoto che ogni giorno vengono scoperti online.
Nel corso degli anni sono state applicate dagli sviluppatori dei maggiori browser differenti tecnologie di sicurezza atte a rendere il lavoro dei pirati informatici sempre più arduo. Ad oggi, una delle tecnologie più utilizzate all’interno della maggior parte dei browser è la sandbox.
Come però i maggiori browser implementino tale tecnologia sarà oggetto di analisi nel corso dell’articolo. Sebbene questo fattore non possa essere utilizzato come unica discriminante nella valutazione di un browser, esso rappresenta sicuramente una caratteristica di cui dover tenere conto.
Al fine di poter confrontare i diversi browser nelle rispettive implementazioni, è utile capire a grandi linee quali sono gli elementi che permettono la realizzazione di una sandbox.
L’obiettivo di una sandbox è quello di isolare dal punto di vista comportamentale e logico una porzione di codice.
L’esecuzione di ogni tab del browser sotto forma di singolo processo è un buon punto di partenza e presenta due vantaggi fondamentali: il primo è dato da una gestione locale delle caratteristiche di sicurezza (magari assegnando limitazioni più o meno restrittive a differenti tab), il secondo è dato dall’evitare che un crash avvenuto all’interno di una tab possa portare alla chiusura dell’intero browser. Chiaramente per poter implementare tale tecnologia è necessario dover cambiare completamente l’architettura del browser, rendendola quindi estremamente modulare.
Limitazioni vere e proprie possono essere gestite tramite altri meccanismi messi a disposizione dal sistema operativo (nello specifico Windows), tra i quali:
Access Token
Il token associato ad un processo contiene, tra le varie informazioni, i privilegi associati al processo e il suo livello di integrità.
Livelli di integrità
Implementati a partire da Windows Vista, i livelli di integrità permettono di assegnare diritti diversi a processi appartenenti allo stresso user account. A differenza di Windows XP in cui i diritti di accesso a una risorsa erano di default uguali per ogni processo creato dallo stesso utente ed erano stabiliti soltanto dalle ACL (Access List), da Windows Vista in poi grazie all’introduzione dei livelli di integrità è stato possibile effettuare una suddivisione più raffinata. In ordine crescente di limitazioni, abbiamo livello integrità Sistema, Alto, Medio, Basso e Non attendibile. Se non diversamente specificato le applicazione utente del sistema sono create con livello Medio. Vale la regola generale secondo la quale un oggetto con un dato livello di integrità non può mai accedere ad un oggetto con un livello di integrità superiore. Si noti che i livelli di integrità non vengono utilizzati solo a livello di processi ma anche a livello di scambio di messaggi tra elementi grafici (UIPI).
Job object
Un job è un oggetto che in ambiente Windows permette di trattare un insieme di processi come un’unica entità. Impostando le caratteristiche del job si può agire indirettamente sulle regole comportamentali dei processi ad esso associati, permettendo di aggiungere ulteriori limitazioni rispetto a quelle già presenti nell’access token del processo.
Gli elementi sopra elencati rappresentano soltanto alcuni degli strumenti sfruttati dai browser per implementare tecniche di sandboxing e che nello specifico fanno riferimento a funzionalità e oggetti messi a disposizione direttamente dal sistema operativo. Tuttavia è possibile, come nel caso di Chrome, ricorrere a tecniche più avanzate (come l’hooking della API di sistema) per tenere sotto controllo il comportamento di ogni singolo processo.
Analizzata a grandi linee come una sandbox è realizzata, è utile comprendere il perché questa sia così importante e soprattutto da cosa ci protegge. Sarà utile dunque porsi nell’ottica di un attaccante e cercare di capire perché è fondamentale far sì che un processo non possa eseguire, o possa farlo con dei limiti, determinate operazioni.
Nel caso specifico di un browser, il primo passo effettuato da un attaccante è quello di sfruttare un bug presente nel codice del software di navigazione tramite un exploit. Questo potrebbe occorrere anche visitando semplicemente una pagina web creata ad hoc che sfrutti un bug del motore di rendering HTML del browser o di uno dei vari plugin installati, presenti solitamente sottoforma di libreria DLL caricata nello spazio di indirizzamento del processo del browser stesso.
Anche utilizzando le tecniche di sicurezza introdotte in Windows Vista e 7 precedentemente descritte, sono comunque presenti scenari di attacco di cui i browser dovrebbero tenere conto.
Immaginiamo che l’avversario abbia ottenuto il controllo del flusso di esecuzione di un processo con privilegi limitati. A questo punto potrebbe tentare di elevarli (attacco privilege escalation) avviando un nuovo processo familiare all’utente, come il blocco note (notepad.exe), e iniettando al suo interno il codice nocivo. In questo modo è molto più probabile che l’utente, fìdandosi del processo, approvi eventuali richieste di azioni sospette (social engineering).
L’attaccante avrebbe avuto vita più facile qualora il processo del browser fosse stato avviato con livelli di integrità di default (medio)i. Per questo motivo una buona regola sarebbe quella di far eseguire, nei limiti del possibile, il processo del browser con un basso livello di integrità. Come vedremo in seguito non tutti i browser adottano questa misura di sicurezza.
Supponiamo ora che l’utente abbia acconsentito al processo notepad.exe di effettuare liberamente le operazioni richieste. A questo punto il codice malevolo potrebbe tentare di leggere informazioni confidenziali sul disco o di scrivere un nuovo eseguibile per poterlo avviare al successivo riavvio del sistema inserendo un’opportuna chiave nel registro di sistema, mantenendo quindi il controllo della macchina infetta.
Un modo alternativo che hanno a disposizione i processi per comunicare è quello dello scambio di messaggi IPC, utilizzati anche per la comunicazione fra gli elementi dell’interfaccia grafica (window). Altri tipi di attacco possono sfruttare questo scambio di informazioni per aggirare i controlli precedentemente descritti (un esempio di abuso di tale tecnologia è lo shatter attack). E’ buona regola quindi isolare i processi il più possible anche da questo punto di vista tramite l’utilizzo di desktop alternativi a quello principale e limitando i privilegi di acesso alle sole finestre che riguardano l’applicazione.
Altre informazioni confidenziali possono essere ricavate dalla lettura della clipboard, una particolare area di memoria condivisa fra i processi – che spesso viene sottovalutata – in cui vengono salvate le informazioni del classico meccanismo di copia-incolla.
La seguente tabella riporta come i tre browser maggiormente diffusi gestiscono gli aspetti critici precedentemente descritti.
Browser security features
Uno degli aspetti che più saltano all’occhio è la totale assenza di una qualsiasi misura di sandboxing da parte di Firefox. Dietro questa mancanza di interesse da parte del team di Mozilla, culminata con l’abbandono (?) del progetto Electrolysis, si nasconde forse una scelta progettuale ben precisa, basata sulla (eccessiva?) fiducia del proprio codice e dei gestori di plugin di terze parti.
È il caso di Flash e Silverlight, che come possiamo vedere vengono gestiti da un processo totalmente separato e indipendente dal processo Firefox:
Flash plugin in Firefox
Non è un caso che gli utenti Firefox ricorrano spesso all’uso di add-on quali NoScript. C’è da chiedersi però fino a che punto questa possa essere ritenuta una scelta ottimale in termini di sicurezza e non una forzatura per sopperire alla mancanza di tutela da parte degli sviluppatori.
Un altro aspetto non di poco conto è con quale livello di integrità i processi del browser vengono eseguiti:
Integrity levels
Come detto in precedenza, almeno dal punto di vista della sicurezza, è sempre preferibile eseguire processi potenzialmente vulnerabili ad un livello di integrità il più basso possibile per limitarli nel caso di un’eventuale infezione.
Nel caso specifico, Firefox viene sempre eseguito con livello di integrità medio e può quindi avere accesso ad ogni altra applicazione utente.
A differenza del browser di Mozilla, Internet Explorer implementa una propria sandbox utilizzando esclusivamente le funzionalità messe a disposizione dal sistema operativo stesso.
Le varie tab aperte dall’utente sono gestite come processi indipendenti incapsulati all’interno di job object con livello di integrità basso. Questa soluzione non permette ai processi del browser di accedere in scrittura alla maggior parte delle risorse di sistema: gli accessi in scrittura sul registro sono limitati alla chiave
HKEY_CURRENT_USERSoftwareAppDataLow
mentre sul disco si può scrivere esclusivamente nella directory
%USER PROFILE%AppDataLocalLow
ne permette comunque l’accesso completo in lettura.
Un attaccante che, potenzialmente, prende possesso del processo associato alla pagina web ha inoltre la possibilità di scrittura su tutti i processi, file su disco o di inviare messaggi IPC che condividono il livello di integrità basso, possiblità che potrebbe risultare rischiosa (ricordiamo la privilege escalation tramite social engineering) ma che in generale non comporta scenari di immediato pericolo.
Oltre a questa limitazione di sicurezza Internet Explorer non aggiunge al job restrizioni che riguardino clipboard e la creazione di processi, lasciando quindi la possibilità di accesso completo a questa zona di memoria condivisa e di generazione di nuovi processi figlio (che comunque erediteranno il livello di integrità basso).
Il principale difetto che si può facilmente notare nella sandbox di Internet Explorer è il fatto che è completamente inutilizzabile in Windows XP: dato che questo sistema operativo non prevede la suddivisione in livelli di integrità i processi del browser rimangono totalmente esposti agli attacchi.
A differenza dei suoi due maggiori concorrenti, Google Chrome pone molta più attenzione all’aspetto della sicurezza imponendo notevoli restrizioni tramite il job assegnato ad ogni processo tab creato.
Job security restrictions
La limitazione nella scrittura della clipboard (precedentemente avevamo accennato al problema nella lettura) è molto importante in quanto permette di evitare a un processo infetto di usare questo “ponte di comunicazione” per passare ad esempio dei comandi ad altri processi.
La comunicazione tra processi è tenuta ancora più sotto controllo limitando lo scambio di messaggi tra gli elementi dell’interfaccia grafica del browser. Questo è possibile grazie alla creazione da parte di Chrome di un oggetto desktop dedicato ai singoli elementi del browser.
Ogni tab viene inoltre eseguita come un processo separato al quale viene associato il livello di integrità “Non attendibile”. Così facendo i processi non hanno accesso né in lettura né in scrittura alle informazioni provenienti da qualsiasi risorsa (registoro di sistema, processi, disco, …) di livelli di integrità superiore. Così facendo si limita l’infezione ai processi aventi lo stesso livello di integrità.
ACL differences
Ulteriori limitazioni sono state introdotte da Chrome grazie alla notevole riduzione dei diritti associati all’access token. In questo modo il browser può realizzare almeno in parte la sua sandbox anche in sistemi operativi in cui non sono previsti livelli di integrità.
A differenza di Firefox e Internet Explorer, Chrome sfrutta anche la tecnica dell’hooking per controllare quale API di sistema vengono invocate dal browser, bloccando tentativi di accesso
alla memoria di altri processi esterni e l’esecuzione di funzioni potenzialmente pericolose se usate impropriamente tra le quali: NtCreateFile, NtOpenFile, NtOpneProcess, NtOpenThread.
Vale la pena sottolineare come le funzionalità della sandbox di Chrome non si basino soltanto sull’uso dei livelli di integrità, che anzi possono essere considerati come un elemento aggiuntivo a quella che abbiamo visto essere un’architettura solida e in grado di sfruttare diverse tecniche di sandboxing.
Questo rappresenta sicuramente un grosso punto a favore di Chrome, che allo stato attuale delle cose resta di fatto uno dei pochi browser in grado di mantenere un buon livello di sicurezza anche se eseguito su sistemi operativi più datati come Windows XP.
A maggior ragione se si pensa alla recentissima collaborazione tra Google e Adobe che ha portato all’integrazione del Flash Player all’interno della sandbox nativa di Chrome, che ad oggi rimane l’unico browser in grado di garantire una versione sotto sandbox del plugin su Windows XP.
Benedetto Voltattorni
Marco Bizzarri
Sandboxes are Overrated
http://hackademix.net/2012/02/16/sandboxes-are-overrated-told-you-4-years-ago/
Sandboxes are not overrated: the biggest percentual of worldwide infections, as of today, are drive-by exploits coming from browsers, so, if you want to keep your local system (which is still critical, we can’t just say that nobody is interested in the data stored locally) safe while you’re surfing the web, a browser which is supposed to be secure should isolate as much as possible its code from other system resources.
Forse 10 anni fa. Con il progredire del web le cose stanno cambiando l’attività delle persone si svolge prevalentemente sul web, e le vulnerabilità delle web app stanno diventando una maggiore minaccia per gli utenti. E voi che conoscete bene il “cloud” dovreste saperlo
Proprio qualche giorno fa sono stati pubblicati questi dati:
http://blogs.msdn.com/b/ie/archive/2012/09/10/xss-trends-and-internet-explorer.aspx
in cui si evince: “A more recent study by Veracode using data from the Web Hacking Incident Database shows that XSS is the most prevalent vulnerability in Web applications and the second most likely to be leveraged in real-world attacks.”
Contro queste vulnerabilità le sandbox possono fare poco o niente, anzi sftruttando una Universal XSS è stato possibile bucare proprio la sandbox di Chrome e di ChromeOS
Se poi vorliamo parlare di integrità del sistema locale, voglio fare notare che i drive-by exploits sfruttano principalmete 0day di plugin, come ad esempio JAVA, che non girano sotto la supervisione della sandbox, lasciando così l’utente infetto.
Bisogna fare chiarezza tra le falle relative alle web application e l’integrità del sistema, sono due cose completamente diverse.
Confermo che XSS, SQL Injection e altre tipologie di attacco lato web siano attacchi altamente diffuse, ma si tratta di un altro argomento che a poco rientra nel quì presente articolo – senza considerare che sono tipologie di attacco dove l’utente finale può spesso fare ben poco.
Confermo inoltre che attacchi di tipo XSS siano, nella classifica totale delle vulnerabilità (non divise per categorie) la seconda tipologia di attacchi più diffusi. Infatti la prima tipologia di attacchi più diffusi è l’esecuzione di codice da remoto, per l’appunto ciò di cui si parla in questo articolo.
“Almost a quarter of vulnerabilities (24,2%) allowed hackers to compromise a system by executing arbitrary code on the victim`s computer, 21% led to Cross-Site Scripting”
http://www.ptsecurity.com/download/Vulnerability-Statistics-for-2011.pdf
Per quanto riguarda i drive-by epxloit, sì, esattamente, utilizzano principalmente (ma non esclusivamente!) falle di plugin aggiuntivi al browser, come specificato già nell’articolo. Ma come Java (che è purtroppo molto difficile da filtrare a livello di sandbox), ci sono altri plugin molto diffusi quali ad esempio Flash – che è al top della classifica degli attacchi 0day da remoto – così come c’è Quicktime (anch’esso stato utilizzato spesso come vettore di attacchi). Plugin ampiamente filtrati dalle sandbox
Giusto per parlare di Flash, è stato il plugin con maggiori 0day (3) nel corso del 2011, statistiche alla mano.
Un altro vettore di attacchi, ad esempio, sono attacchi 0day ad Adobe Acrobat Reader. Qui Google Chrome ha addirittura implementato il proprio lettore .pdf, che viene eseguito all’interno della propria sandbox, al fine di mitigare questa tipologia di attacchi da remoto.
Per quanto riguarda Java, una caratteristica alquanto utile di Chrome è la disattivazione automatica del plugin Java in caso vengano rilasciati aggiornamenti, ritenendolo obsoleto e a rischio di possibili attacchi. Non previene totalmente attacchi 0day tramite Java perché lascia la decisione finale all’utente se attivarlo sebbene sia obsoleto o meno, ma perlomeno tenta di fare qualcosa.
Non bisogna quindi sottovalutare le tipologie di attacco alle web application, ma non bisogna neanche sminuire l’importanza per un browser di poter garantire (o tentare di garantire) l’integrità del sistema dove viene eseguito.
Dire che la sandbox in un browser è obsoleta ed inutile significa lasciare aperto un vettore di attacchi spaventosamente ampio e diffuso – vedasi la proliferazione nel mondo underground di kit automatizzati per l’esecuzione di codice da remoto quali BlackHole, Elenoire e moltissimi altri.
Se non fosse un argomento così importante nel 2012, il SANS non rilascerebbe ancora whitepaper su come mitigare gli attacchi al sistema tramite browser
http://www.sans.org/reading_room/whitepapers/warfare/mitigating-browser-based-exploits-behavior-based-defenses-hardware-virtualization_33804
Il flashplayer prima dell’introduzione di PPAPI era filtrato solo parzialmente, tramite un IL low e un token USER_INTERACTIVE, evidentemente non sufficienti dato che è stato bucato da VUPEN.
Java non è filtrato, ed è attualmente tra gli 0 day più sfruttati, anche da BlackHole.
Quicktime non è filtrato.
Direi quindi Plugin ampiamente NON filtrati dalle sandbox.
La blacklist per i plugin vulnerabili è presente anche in altri browser privi di sandbox.
Per i PDF anche altri browser privi di sandbox hanno implementato un lettore interno con un approccio diverso.
Sempre riguardo l’integrità del sistema una sandbox non può niente contro attacchi di ingegneria sociale che convincono l’utente ad eseguire volontariamente del codice.
La sandbox non è obsoleta è il concetto di salvaguardare l’integrità del sistema attraverso la sandbox del browser che è da anni ’90. Non è il browser che deve garantire o tentare di garantire l’integrità del sistema. E’ il sistema che deve garantire l’integrità e l’isolamento di tutte le APP.
Si veda la strada intrapresa con Win8 Metro/WinRT, GoogleOS, nei prossimi anni, con questi nuovi OS con i loro account nel cloud, le Web App rivesterano un ruolo centrale, e il concetto di sandbox e isolamento sarà implementato su tutti i livelli, per evitare di avere il sistema compromesso.
Confermo che è un argomento importante, ma quel paper di SANS fa molto anni ’90 🙂
ottimo articolo che offre molti elementi di crescita, quantomeno per me.
Grazie
la presenza dell’elemento
BUILTINAdministrators con flag impostata su DENY è indice del fatto che gli screenshot sono stati presi da un account amministratore sebbene in AAM, mi sbaglio?
Ciao NV 25.
Innanzitutto grazie per i commenti positivi e per il tuo contributo.
Come giustamente hai notato, la presenza di BUILTINAdministrators con flag DENY stà ad indicare l’utilizzo di un account di tipo Protected Administrator.
La cosa ancora più interessante è notare tuttavia come Chrome ed Internet Explorer gestiscano differentemente l’avvio del browser in modalità amministratore.
Mentre Internet Explorer assegna i privilegi di Elevated Administrator sia al processo broker che ai processi delle singole tab, Chrome continua a garantire la sicurezza assegnando tali privilegi solo al broker, lasciando inalterati quelli dei processi tab.
Benedetto
…non che cambi nulla della vostra analisi, è pura curiosità.
Ciao e grazie 🙂
@Manzo:
scusa se continuo qui, ma non mi viene permesso di aggiungere ulteriori sotto-risposte al tuo ultimo commento per questioni di numero di commenti nidificati.
1) Non importa se la sandbox di Flash in Chrome era fatta bene, meno bene o male, almeno un tentativo era stato fatto. Quello che importa è che comunque era stata fatta e prima di VUPEN nel 2012 nessun altro era riuscito a bypassare tale sandbox (che era comunque molto inferiore rispetto alla sandbox originale utilizzata da Chrome). Poi è stata migliorata, giustamente, dopo che sono state scoperte delle falle. Sicuramente un approccio più orientato alla sicurezza di chi neanche se n’è curato di fare una cosa del genere, o chi ha iniziato un progetto anni fa e non l’ha mai completato;
2) Sì, ci sono browser che hanno implementato PDF reader interni al browser, senza sandbox per l’appunto. Se succede qualcosa o si scopre una falla, non c’è nessun altro meccanismo di difesa, un approccio multi-layer a difesa del sistema. In altre parole, l’utente si attacca, e risiamo daccapo al discorso;
3) Sarà anche un approccio che fa molto anni ’90, ma non è che perché suona anni ’90 bisogna chiudere gli occhi di fronte ad un problema reale, vero, che permette numerosi attacchi ogni giorno. Non sarà il browser che si deve occupare di tale cosa bensì il sistema operativo, ok, la teoria è giusta. E nel frattempo che il sistema operativo non se ne cura? Lasciamo tutto scoperto? Non è girandosi dall’altra parte e dicendo “non sono io che me ne devo occupare, è un altro” che si può arrivare intanto ad una soluzione, almeno temporanea, del problema 🙂
Ciao e grazie per gli interventi 🙂
http://imageshack.us/photo/my-images/696/immaginetsp.jpg/
Complimenti per l’articolo e la nuova società.
Sarebbe interessante un approfondimento in tema IL.
Con ICACLS ho abbassato l’IL di Sumatrapdf e VLC a livello “low”.
Non hanno problemi che mi impediscono il loro uso.
Tentando di emulare Chrome ho usato il tool di Minasi(come si vede nell’immagine sopra) per raggiungere il livello untrusted.
Ma i sw non si avviano.
Mi chiedo perchè Chrome sì ed altri no ?
p.s. Salutatemi Eraser,visto che non frequento più HW Upgrade gli mando i miei saluti quì.