Introduzione
Abbiamo avuto il piacere di parlare con Joanna Rutkowska, una protagonista indiscussa nel settore della sicurezza digitale, fondatrice e amministratrice di Invisible Things Lab (ITL), una società di consulenza e di ricerca di alto profilo.
TH: Grazie per aver trovato un po' di tempo per parlare con noi, Joanna. Cominciamo dagli elementi fondamentali: sei riuscita a costruirti un ruolo importante nel mondo della sicurezza, grazie alla tua esperienza sugli attacchi invisibili, come i rootkit, e più recentemente scoprendo delle vulnerabilità su macchine virtuali e a livello hardware. Prima di entrare in questi dettagli, ci racconti qualcosa di più su di te?
Joanna: Sono una ricercatrice che si occupa di sicurezza a livello di sistema, come nel kernel, nell'hypervisor, nel chipset, e così via. Ricercatrice, non cacciatrice di bug o tester. Sono più interessata ai problemi fondamentali piuttosto che a bug specifici che creano problemi a software specifici. Per esempio, può il sistema operativo offrire una qualche sicurezza, anche se un'applicazione, come per esempio Adobe Reader o IE, è compromessa? Io credo nella "sicurezza tramite isolamento".
Ho pensato anche agli affari, e fondato Invisible Things Lab (ITL), una società di ricerca e consulenza. Sono molto orgogliosa della squadra che sono riuscita a creare in azienza, che include Alexander Tereshkin e Rafal Wojtczuk, due dei migliori ricercatori nel campo della sicurezza dei sistemi. Recentemente mi sono sempre più allontanata dal ruolo di "debugger", per avvicinarmi ad uno di più alto profilo, necessario per gestire il lavoro della squadra. Mi piace, in effetti, fare il dirigente.
TH: Essere il capo è una buona cosa, ma come hai cominciato a occuparti di ricerca?
Joanna: È passato così tanto tempo che nemmeno me lo ricordo!
TH: Proviamo con una domanda più facile. Qual era il tuo primo computer, e qual è il tuo primo ricordo sul tema della programmazione.
Joanna: Era un PC/AT 286, con l'incredibile velocità di 16 MHz, se ricordo bene, e aveva anche 2 MB di RAM (ma credo che fosse dopo un aggiornamento della scheda madre). Avevo undici anni quando ho cominciato a giocarci, e quasi immediatamente sono partita con GW-BASIC, e dopo un anno o giù di lì sono passata al Borland Turbo Basic, che era davvero fantastico, con una bellissima interfaccia grafica e la possibilità di creare davvero degli eseguibili.
TH: Com'è la settimana tipo nei vostri uffici?
Joanna: Siamo orgogliosi di essere un'azienda moderna, e non abbiamo uffici fisici. Ognuno lavora da casa sua, e ci scambiamo i materiali con mail protette da crittografia. Non esiste niente di simile ad un orario predefinito, tipo 09.00-05.00. Il nostro lavoro richiede molta creatività, e sarebbe stupido forzare qualcuno ad un orario.
Per me, personalmente, è particolarmente importante fare un pisolino al pomeriggio. Non sono efficiente se non ho dormito a sufficienza. Non ho mai lavorato in un ufficio.
Introduzione, continua
TH: Beh, allora puoi dirci come il vostro cliente tipico?
Joanna: I nostri servizi sono pensati per chi vende i sistemi.
TH: Quindi per esempio i produttori di BIOS e le aziende alla ricerche di ambienti sicuri?
Joanna: Io enfatizzerei la parola "venditore" in questo caso, perché noi siamo molto interessati nella possibilità di cambiare la tecnologia. Secondo me l'evoluzione naturale della ricerca è offrire critiche costruttive e proposte di cambiamento, per migliorare le tecnologie che abbiamo a disposizione oggi. Quindi vorrei lavorare sia con i venditori di hardware (CPU/Chipset) che con il software (BIOS/OS), proprio perché alcune delle migliori nuove tecnologie funzionano al meglio solo se abbinate a software sviluppato appositamente.
TH: Qual è la configurazione del tuo sistema principale?
Joanna: Il mio desktop principale è un Mac Pro a otto-core (2 Intel Xeon a 2,8 GHz) con 16 GB di RAM e un bellissimo schermo Apple da 30". È la macchina più bella che ho mai avuto, sia per quanto riguarda l'estetica che l'esperienza della GUI.
Uso anche un MacBook un po' più datato (Santa Rosa, Core 2 Duo a 2,2 GHz, 4 GB di RAM) come macchina per usi generali. Ho rinviato l'acquisto di un MacBook unibody per aspettare il supporto a più di 4GB di RAM (almeno per la versione da 15", che preferisco). L'hardware Mac, in ogni caso, ha ancora dei punti deboli importanti: la mancanza di TPM, TXT, VT-d e il sistema OS X. Cerco di aggirare i limiti con la virtualizzazione, quando è possibile.
Uso anche alcuni PC, sia portatili che desktop, e devo dire che continua a sorprendermi constatare quanto sono brutti, accanto ai Mac. Una delle poche eccezioni è il Voodoo Envy 133, e spero che lo aggiornino presto con un nuovo chipset, perché potrebbe davvero diventare un acquisto interessante.
TH: Ultima domanda introduttiva. Qual è il tuo hobby non tecnologico favorito?
Joanna: Un passatempo non tech? Hmm, immagino che non conti programmare un robot a sei gambe autonomo basato su due micro controller AVR a 8-bit.
Storia sintetica del malware
TH: La maggior parte delle tue ricerche si concentra sugli aspetti più estremi e delicati allo stesso tempo della sicurezza informatica. Vorremo offrire ai nostri utenti una breve introduzione storica, con il tuo aiuto. All'inizio i virus erano semplici parassiti che colpivano file eseguibili …
Joanna: Qui potrei protestare sul termine "semplici". Alcuni di quei file, infatti, erano decisamente molto complessi, come quelli basati sul motore Mistfall, creato da Z0mbie.
TH: Pensiamo all'epoca precedente a DarkAvenger/MtE. A cose come Friday the 13th/Jerusalem. Pensando a quel codice, i virus per il settore di avvio erano probabilmente il primo salto evolutivo del malware, seguito poi dalla generazione MtE. Probabilmente quello era il momento di riconoscere che la sicurezza "signature based" aveva delle limitazioni. Il salto generazionale successivo dovrebbe essere qualcosa come i virus Macro. Non tanto perché rifletteva la sicurezza multi-piattaforma, che già era un'idea nuova, ma perché rifletteva l'evoluzione del malware e un nuovo modo di vederlo. S'introduceva un nuovo modo di diffondere il malware, che sfruttava la nuova diffusione di massa dei computer e la condivisione dei documenti, un'attività sempre più comune. Più importante ancora, tuttavia, era il dogma secondo il quale i file di dati non potevano infettare un sistema, ma c'erano prove che invece era possibile. Si sentono, ancora oggi, affermazioni come "fino a che non apri gli allegati nella posta, sei al sicuro", oppure "se ha tutti gli aggiornamenti e le patch, sei al sicuro", o persino "se usi un Mac, sei al sicuro". Una delle nostre frasi preferite è "Non fatevi ingabbiare da un dogma, perché è come pensare con la testa degli altri", che ha detto una volta Steve Jobs.
Non sappiamo dove collocare altri punti fondamentali dell'evoluzione del malware. La capacità d'integrazione del codice di ZMist è probabilmente un salto generazionale, ma non è certo "l'inizio".
Tornando alla nostra storia, quando si eseguiva un file infetto, il virus restava nella memoria, e collocava una copia di sé stesso nel programma successivo che veniva eseguito. Se non si eseguiva mai il file pericoloso, il sistema non si sarebbe mai infettato. Per fare un nuovo passo avanti, serviva il virus per il settore di avvio, che sfruttava l'avvio del PC per caricare il virus ancora prima del sistema operativo, rendendo possibile la manipolazione di ogni tipo di dati. Questa tecnica era uno dei primi metodi "invisibili" per infettare i computer.
Joanna: Non è del tutto corretto. Ai tempi del DOS non c'era nessuna nozione di protezione della memoria, quindi non c'era bisogno di caricare il virus prima del sistema operativo per controllare quest'ultimo. Era possibile controllare il SO anche con un caricamento posteriore.
Storia sintetica del malware, continua
TH: Certo, ma se si ha un antivirus installato e attivo permanentemente, caricare il virus dopo l'antivirus lo renderebbe visibile. L'approccio da settore boot permette di prendere il controllo del sistema prima che intervengano i sistemi di protezione, giusto?
Joanna: Giusto.
TH: Bene, andiamo avanti allora. Windows ME e altri sistemi operativi basati su DOS contavano sulle capacità del BIOS per gestire l'accesso al disco, ma Windows NT ha cambiato questa consuetudine.
Joanna: Non bisogna confondere il DOS con Windows 95/98/ME. I sistemi Windows avevano una modalità protetta, e c'era la nozione di protezione della memoria. Sono anche piuttosto sicura del fatto che i sistemi Win95 non usassero i BIOS interrupt, ma piuttosto drivers per gestire PIO/MMIO, come i sistemi moderni.
TH: Credevamo che, una volta avviato Windows NT, la modalità protetta e i driver relativi potessero saltare il BIOS, fermo restando che un virus sul settore di avvio potrebbe comunque fare dei danni, come formattare il disco rigido prima dell'avvio di Windows. Con questa protezione, anche con un BIOS compromesso da un virus per il settore boot, la modalità protetta assume un'importanza maggiore e permette di superare i pericoli del BIOS?
Joanna: Non esattamente. È stato dimostrato diverse volte (per esempio dal BootRoot di Eeye) che è possibile per un malware avviato dal settore di avvio di superare le protezione del sistema operativo, e colpire l'avvio di Windows.
TH: Forse dovremmo rivedere il testo finale, e pubblicare qualcosa nel quale sembriamo più competenti. Contiamo sulla tua confidenzialità, per questo?
Joanna: Potete contarci.
TH:La maggior parte dei nostri contenuti sono prodotti all'interno della nostra redazione, ma interviste come questa ci permettono di esplorare aspetti del mondo tecnologico che altrimenti resterebbero marginali, e di imparare sempre cose nuove. Passiamo quindi velocemente ai giorni nostri: i rootkit oggi si considerano all'ordine del giorno, e sono un tipo di programma per permette di attivare funzioni a livello amministrativo. Un rookit a livello utente, invece, influenza un singolo programma, come per esempio Internet Explorer o Flash, e un'antivirus è in grado di riconoscerlo e fermarlo.
Joanna: Più precisamente, i rootkit utente sono malware che operano in Ring 3 (modalità utente). Non è limitato ad una singola applicazione, e in molti casi potrebbe colpire tutti i processi utente, come faceva il famoso Hacker Defender, e anche i processi di sistema. Un processo di sistema infatti può essere, ed è in molti casi, un processo utente, ed è quindi più vulnerabile.
BluePill, la pillola blu
TH: Il rootkit di "livello kernel" è quello che riceve più attenzioni dai media. Questo tipo di malware compromette direttamente il kernel del sistema operativo e, visto che non c'è nulla con un accesso più alto, non c'è modo di "guardare giù" e cercare il virus. Con un rootkit per kernel, quindi, un antivirus può facilmente essere eluso senza che nessuno se ne accorga.
Joanna: Esatto, il vantaggio dei rootkit a livello kernel, rispetto a quelli a livello utente, è diventato palese dopo che i vari antivirus hanno cominciato ad introdurre moduli che agisicono a livello kernel, che permettono le cosidette funzioni antirootkit.
Avere due elementi (un rootkit e un antivirus) con gli stessi privilegi (livello 0) non implica che entrambi vincano, a lungo termine. In effetti, la verità è che c'è sempre un pareggio, a lungo termine: per il malware è sufficiente sopravvivere qualche settimana, o anche solo qualche giorno, per raggiungere i suoi obiettivi.
TH: Si credeva che il rootkit per kernel fosse il metodo di attacco con il maggior potenziale di invisibilità e danneggiamenti …
Joanna: No, non lo è mai stato. Sin dai primi tempi in cui questi rootkit sono comparsi gli utenti hanno trovato risposte adeguate, vale a dire programmi in grado d'identificare i malware conosciuti.
Alan: Con un rootkit per kernel, è come tornare all'epoca del DOS. Puoi trovare un anti-rootkit fantastico, ma poi può saltare fuori un rootkit migliore, in versione n+1, capace di vincere lo scontro, e la cosa potrebbe andare avanti all'infinito. Un sistema operativo ben progettato, invece, obbliga i cattivi ad agire a livello utente, e l'amministratore può giocare il ruolo della guardia, a livello kernel. Così si ha sempre il coltello dalla parte del manico, di fronte al software pericoloso, e l'unico modo per andare oltre, e sfruttare un qualche bug per arrivare al Ring 0.
Joanna: Sì.
BluePill, la pillola blu, continua
TH: Quindi il punto è avere un livello di accesso che sia almeno un livello superiore rispetto all'avversario. Più piccolo è il numero, più forti siamo. A questo punto ci puoi parlare degli exploit "Ring -1", e della tua "pillola blu"?
Joanna: Ring -1 è un nome informale, coniato quando AMD e Intel introdussero la virtualizzazione a livello di CPU, circa tre anni fa. Quelle nuove tecnologie introdussero un nuova modalità operativa, chiamata "root mode" o anche "host", in base al produttore. A livello informale, questa novità è stata chiamata "Ring -1", per sottolineare il fatto che l'hypervisor ha più privilegi del kernel del sistema operativo, tradizionalmente a livello Ring 0.
Ho scritto BluPill nel 2006 per dimostrare come la tecnologia di virtualizzazione a livello hardware può offrire un'occasione per creare malware molto sofisticato: è possibile creare un hypervisor invisibile e, senza grossi ostacoli, spostare il sistema operativo principale in una macchina virtuale, controllate dall'hypervisor maligno.
Supponiamo di avere un software per controllare l'integrità del sistema, capace di verificare l'integrità del codice del kernel, strutture di dati e puntatori di funzioni, per controllare se uno di questi elementi è stato compromesso. Anche uno scanner così, del tutto ideale, non sarebbe capace di individuare malware come BluPill. Questo perché, a differenza dei rootkit kernel precedenti, BluPill non tocca nulla del kernel o dei dati. Quello che fa è installarsi sopra al kernel, senza bisogno di fare modifiche.
Un altro elemento unico di BluePill, che lo rende davvero unico nel suo genere, è che supporta la virtualizzazione "a nido" (nested). Si può caricare BluePill e poi, dentro alla macchina virtuale creata, avviare un normale hypervisor, come Xen o Virtual PC. Potete persino caricare diverse istanze di BluePill una dentro all'altra. In effetti, sono piuttosto orgogliosa dei risultati che ho ottenuto.
In molti hanno cercato di dimostrare che BluePill è individuabile, con diversi software scritti apposta. Il principio generale era che bastasse individuare un processo di virtualizzazione per poter dire di trovarsi dentro a BluePill.
Qualche hanno fa, in effetti, si poteva fare un'affermazione simile perché non c'erano altri prodotti che usassero la virtualizzazione a livello hardware. Chiaramente, però, se diamo retta a questa impostazione potremmo anche dire che se un eseguibile attiva o usa connessioni di rete, allora deve essere per forza l'elemento di una botnet.
BluePill, la pillola blu, continua
TH: Proviamo a chiarire: se io sto usando una macchina virtuale legittima e ho accesso a tutti gli strumenti del caso, mi stai dicendo che non ho modo di sapere che il gestore della macchina virtuale, l'hypervisor, è stato compromesso da BluePill? Posso usare lo strumento per individuare la virtualizzazione, ma mi dirà solo quello che già so, cioè che è attiva un macchina virtuale?
Joanna: sì, individuare la virtualizzazione e capire se una macchina virtuale è compromessa sono due cose diverse.
TH: Quindi l'unica ragione per cui le strategie di individuazione funzionano è il fatto che, in teoria, nel mio sistema non ci dovrebbero essere macchine virtuali attive, quindi se ne viene rilevata una, posso supporre che ci sia un problema, giusto?
Joanna: In teoria puoi investire del tempo per creare le istruzioni necessarie per le misurazioni anche in caso siano presenti macchine virtuali a nido, per scoprire se ce n'è una che non dovrebbe esserci. Lo abbiamo mostrato al Black Hat l'anno scorso, aggiungendo BluePill all'hypervisor Xen. Ma è un approccio molto rischioso e complesso, che dipende molto dall'implementazione dell'hypervisor (quello legittimo). Bisogna esserne ben consapevoli di tutti i parametri per riuscire a "separare i segnali dal rumore", e trovare quello che stiamo cercando. Credo che un approccio simile per risolvere il problema del malware simile a BluePill, anche se si presta bene alla speculazione, sarebbe un vicolo cieco. Non credo che vedremo circolare malware come BluePill nei prossimi tempi, ma solo perché il malware "vecchio stile", che colpisce a livello kernel funziona ancora alla grande. L'industria degli antivirus è un disastro per quanto riguarda l'individuazione e le prevenzione contro questo tipo di minaccia. Quindi chi sviluppa malware ha pochi incentivi a fare un nuovo passo evolutivo verso tecnologie più complesse. Naturalmente noi ricercatori non aspettiamo che i cattivi facciano la prossima possa, e stiamo già pensando a come evitare che questo malware, ancora potenziale, possa arrivare a diffondersi. Una possibile soluzione è la tecnologia Intel TXT (Trusted Execution), anche se in verità siamo già riusciti ad aggirarla qualche mese fa, in occasione del Black Hat DC.
Superare le protezioni hardware
TH: Con "red pill", invece, hai mostrato come sia possibile capire se un'applicazione sta girando dentro a "The Matrix", cioè l'ambiente virtualizzato nascosto di BluePill. Nella tua dimostrazione, sembra che basti usare l'istruzione SIDT per esaminare i dati IDTR.
Joanna: C'è una differenza tra individuare una virtualizzazione qualsiasi rispetto ad uno specifico hypervisor, come BluePill. RedPill cerca virtualizzazioni basate sul sofware, e infatti usavamo prodotti VMWare, prima che AMD e Intel introducessero le loro tecnologie, nel 2006. La prima versione di RedPill risale al 2004, e non era in grado d'individuare la virtualizzazione a livello hardware.
Altri ricercatori hanno presentato strumenti capaci, a volte, d'individuare la virtualizzazione a livello hardware, nel 2006 e nel 2007, dopo la mia prima presentazione di BluePill al Black Hat (nel 2006).
TH: Quattro anni e mezzo dopo, quindi, abbiamo al possibilità di identificare le macchine virtuali, grazie a strumenti avanzati, ma il concetto resta lo stesso.
Joanna: Sì, questo accade perché anche se praticamente ogni macchina in commercio oggi supporta VT-x alcuni prodotti usano ancora la virtualizzazione software. Credo che VMWare Workstation la usi ancora con i sistemi a 32-bit. I nuovi identificatori di virtualizzazione, la prossima generazione di RedPill, possono riconoscere la virtualizzazione VT-x o AMD, ma in genere sono "timing based" o "caching based".
TH: Se sei nella squadra dei buoni, probabilmente ti preoccupa il malware con accesso di livello Ring -1. Identificare la presenza di una macchina virtuale, quindi, può essere un aiuto importante. Se non ci dovrebbero essere macchine virtuali attive, dopotutto, trovarne una è un ottimo campanello di allarme.
Joanna: Certo, ma non dimentichiamo che la virtualizzazione sta diventando un fenomeno di massa, usata persino su sistemi desktop Xen Client Initiative (conosciuto anche come Project Independence) o Phoenix HyperCore.
TH: Detto questo, se fossi uno dei cattivi, potresti alterare i risultati per mantenere nascosto il malware? Se l'antivirus vedesse un'applicazione che richiede l'IDT e la successiva linea di codice è "il risultato comincia con 0xc0 o 0x80", altererebbe i risultati. Come ci possiamo proteggere da questo tipo di attacco?
Joanna: Non si può. Questi attacchi però partono dal presupposto che l'attaccante conosca il codice del programma usato per l'individuazione. In altre parole, dovrebbe avere un database con tutti i possibili codici d'identificazione, e conoscere quali frammenti di codice dovrebbero essere ingannati, così da far credere all'applicazione che non ci sia virtualizzazione. Questi sono attacchi specifici per certe implementazioni, ma si adattano male ad un uso generale. Il loro uso non è necessariamente legato alla virtualizzazione invisibile, quanto piuttosto alla disabilitazione di popolari programmi antivirus.
Dal punto di vista dai buoni, purtroppo, non c'è modo di prevenire attacchi del genere se si lavora con privilegi uguali o minori a quelli usati dal malware. Ecco perché gli antivirus stanno perdendo la battaglia con i rootkit a livello kernel, che spesso sono in grado di disabilitare la modalità kernel dell'antivirus, almeno per i prodotti più conosciuti, proprio perché sono famosi, e facili da analizzare e neutralizzare. Quando c'è una nuova versione di un antivirus anche tutto il malware deve essere aggiornato, naturalmente, e quindi si tratta di una corsa senza fine, dove i criminali si divertono e si arricchiscono, così come i produttori di antivirus. L'obiettivo, proteggere gli utenti, non è però mai raggiunto veramente.
Superare le protezioni hardware, continua
TH: E c'è chi si arricchisce su entrambi i fronti, proprio come i mercanti d'armi. Alcuni malware attuali sono progettati per fermare tutte le azioni sospette se si trovano dentro a una macchina virtuale. In questo modo l'autore del codice cerca di evitare che i ricercatori come te possano individuare il malware e le sue caratteristiche, o almeno tentano di renderlo un lavoro più difficile. Il malware cerca di sfruttare la IDT (Integrated Device Technology) nella memoria di alto livello, dove possiamo trovare anche i sistemi operativi. D'altra parte, però, l'autore del malware non ha modo, con questo metodo, di sapere se ha colpito un utente inconsapevole che sta sfruttando queste tecnologie (che però sarebbe quantomeno insolito), oppure un abile ricercatore che gli ha teso una trappola.
Joanna: Gli autori di malware capirebbero rapidamente che non vale più la pena di evitare i sistemi virtualizzati, e ci ritroveremmo al punto in cui siamo oggi.
TH: Al momento tu però sei un passo avanti, perché il malware non può nascondersi dentro ad una VM. In un certo senso, la tua proposta riduce il tempo necessario a trovare le soluzioni, giusto?
Joanna: Come dicevo prima, questo modo di pensare è un po' ingenuo. In verità questo approccio non offre protezione a lungo termine.
TH: Ok, la tua squadra però non si è fermata al livello Ring -1. Cosa succede a Ring -2?
Joanna: In effetti il malware a livello Ring -1 è del 2006! Ogni CPU x86 ha un cosa chiamata System Management Mode (SMM), che in sé non è nulla di nuovo, visto che è stata presentata con i processori 80386. Ciò che lo rende interessante, oggi, è che quando fu aggiunta la virtualizzazione ai processori, è emerso che il sistema SMM aveva privilegi maggiori di quelli introdotti con la virtualizzazione, cioè Ring -1, dati all'hypervisor. S'introdusse quindi il concetto di livello Ring-2, per enfatizzare la loro maggiore potenza, rispetto a Ring-1.
Il nostro gruppo, in ogni caso, non è stato il primo a sfruttare la SMM. Nel 2006, infatti, Loic Duflot presentò un attacco contro OpenBSD che usava la modalità SMM, sfruttandola come strumento, non come obiettivo. All'epoca, in effetti, era normale che la SMM non fosse protetta in alcun modo sulla maggior parte dei sistemi, quindi se si aveva un accesso di root (kernel mode), era possibile iniettare codice liberamente ed eseguirlo con i privilegi, altissimi, della SMM. Per fortuna, tuttavia, c'èra comunque bisogno di privilegi di root per sfruttare questo meccanismo.
Poi i produttori hanno cominciato a proteggere la SMM. C'è una parte della DRMA usata per ospitare il codice eseguito in SMM, chiamata SMRAM, alla quale sono state applicate speciali protezioni tramite il chipset (tramite il Memory Controller Hub, per essere precisi). Sulla maggior parte dei sistemi moderni, quindi, non è facile eseguire del codice con privilegi SMM. Bisogna trovare un bug nel chipset o nel BIOS per farlo (anche con accesso kernel). All'ultimo Black Hat di Las Vegas Sherri Sparks e Shawn Embleton hanno presentato un rootkit SMM, ed era chiaro che il rootkit poteva essere caricato solo su sistemi vecchi, precedenti al 2006. Nei giorni successivi, curiosamente, vedemmo diverse comunicazioni inerenti ad attacchi a Xen, e parlammo di un bug nei BIOS di Intel che permetteva l'esecuzione di codice arbitrario in modalità SMM. Credo che sia stato il primo bug di questo tipo di cui si è parlato pubblicamente; da allora abbiamo trovato altri modi di aggirare la protezione della SMM su molti sistemi. Alla fine del 2008, per esempio, abbiamo scoperto che molti sistemi Intel (e potenzialmente anche altri BIOS) erano vulnerabili, e abbiamo usato la falla per aggirare la Intel TXT al Black Hat DC di febbraio.
Questo bug non è ancora stato risolto, e non è l'unico. Ne abbiamo trovato un altro nella semantica di caching usata dalle CPU Intel, confermato anche da Loic Duflot, con cui ci siamo accordati per la pubblicazione contemporanea della documentazione relativa.
In conclusione, i rootkit SMM (o rootking Ring -2) hanno bisogno di un accesso alla memoria SMM, che è molto ben protetta sui sistemi moderni, quindi un attaccante dovrebbe trovare e usare exploit davvero molto complessi, anche per i più bravi di noi.
TH: Questi attacchi SMM sono legati ad hardware specifico?
Joanna: In generale sono limitati a certe versioni di certi BIOS, o famiglie di BIOS, e anche a famiglie di chipset.
Il malware può flashare il BIOS?
TH: Un programma maligno potrebbe aggiornare (flashare) il BIOS?
Joanna: No! C'è stata molta confusione negli ultimi mesi. Alcuni credono che gli attacchi SMM siano automaticamente in grado di aggiornare il BIOS, ma non è vero. C'è stata una presentazione, non molto fortunata in verità, all'ultimo CanSecWest, fatta da due ricercatori di Core, su "Infezioni resistenti del BIOS". Ho visto le loro diapositive, e facevano sembrare che avessero trovato un modo di aggiornare il BIOS, e che non ci fossero protezioni possibili contro questo attacco. Nulla di più lontano dalla verità.
Per cominciare hanno scelto di colpire BIOS di fascia bassa: un Award BIOS e anche un BIOS VMWare (che di per sé non conta molto, visto che non è un vero BIOS). Questi due BIOS non richiedevano che gli aggiornamenti includessero la firma digitale del produttore, quindi non era particolarmente difficile aggiungerci del codice nona autorizzato. La maggior parte dei BIOS moderni, invece, accetta solo firmware certificati come aggiornamenti, ed è una cosa che succede da anni, che non ha nulla a che fare con la TPM o altre tecnologie Trusted Computing.
Questa situazione non è molto buona per noi, perché al prossimo Black Hat Rafal e Alex presenteranno dei veri attacchi che aggiornano il BIOS, che includono l'aggiramento della protezione dei BIOS Intel. È una cosa molto complicata, e il vero exploit è davvero un capolavoro. Dubito, però, che il malware potrebbe cominciare a sfruttare attacchi simili, che sono semplicemente troppo complessi, e devono essere adattati ad ogni BIOS. Dal punto di vista della ricerca, però, si tratta di un passo avanti molto importante, con un potenziale impatto enorme, che potrebbe diventare praticamente permanente, su una macchina infetta.
TH: Non vediamo l'ora. Parlaci degli attacchi Ring -3.
Joanna: È una cosa del tutto nuova, e molto complicata. Potrebbe dare ancora più potenzialità ai rootkit SMM. Com'è possibile ottenere privilegi ancora maggiori rispetto a quelli della SMM? Purtroppo non posso dirvi molto ora, se non che siamo in contatto con Intel riguardo la vulnerabilità che abbiamo trovato, e che loro sono già al lavoro su una patch che dovrebbe essere disponibile a breve.
TH: Cosa puoi dirci dell'HyperCore?
Joanna: HyperCore è un hypervisor leggero per i portatili sviluppato da Phoenix Technologies. Siamo stati assunti da Phoenix per fare ricerche su diverse tecnologie che potrebbero, potenzialmente, servire a rendere più sicuro questo prodotto. Non posso parlare liberamente di questa ricerca, come d'abitudine in questo settore.
TH: Gran parte delle tue ricerche, fino ad ora, consistono nell'avvicinarsi sempre di più alla CPU. Cosa ci dici dell'approccio contrario, cioè avvicinarsi all'utente. Se fosse possibile, per esempio, impossessarsi della memoria della GPU, sarebbe possibile visualizzare una falsa richiesta di password e spingere l'utente ad inserire dati sensibili. Oppure si potrebbe entrare nel controller USB, e usare per registrare ciò che viene digitato sulla tastiera. Cosa ne pensi?
Joanna: Credete che avvicinarsi alla CPU significhi allontanarsi dall'utente? Davvero? La CPU è il centro del sistema, ogni utente la usa, ogni programma, tutti i dati passano da lì. È l'elemento del sistema più vicino all'utente che si possa immaginare. È nella CPU che i dati vengono decodificati, se protetti da crittografia, e sono eseguite tutte le azioni.
TH: Non è insolito pensare che la GPU sia "più vicina all'utente", se si pensa alla grafica 3D, al GPGPU, e ai tanti utenti che hanno l'hobby del fotoritocco. È un po' come dire "occhio non vede cuore non duole".
Joanna: Consideriamo la possibilità di sfruttare la memoria della GPU: non sarebbe una soluzione molto pratica per chi scrive malware, perché le password sono visualizzate come asterischi, ed è questo che vede la GPU!
Strategie di difesa
TH: A meno che non si stia usando un iPhone, con cui le password non sono coperte da asterisichi. Scusa l'interruzione …
Joanna: Sfruttare la tastiera o il controller USB, invece, sarebbe una strategia valida, ma funzionerebbe solo in scenari molto semplici, come quelli rappresentati da siti bancari che usano pratiche di sicurezza scadenti. Un attacco migliore, dal punto di vista del malware, sarebbe colpire semplicemente il browser; il difetto principale di questo approccio, invece, starebbe nel fatto che un antivirus con privilegi kernel potrebbe individuarlo, almeno in teoria, perché in realtà fanno tutti pena.
Un altro problema di questo approccio potrebbe essere un utente un po' più attento della media, che usa browser diversi per le sue attività quotidiane, e magari li tiene dentro a una macchina virtuale, e uno dedicato per l'online banking. In questi casi non sarebbe facile colpire il browser che usa per accedere alla banca, e ci vorrebbe un po' di lavoro aggiuntivo.
La ragione per la quale ci concentriamo su attacchi di basso livello basati sull'hardware è che siamo convinti che un sistema sicuro deve essere costruito su fondamenta solide, altrimenti le pratiche di sicurezza non avrebbero senso. Questo è specialmente vero se si crede, come me, all'approccio "Sicurezza tramite l'isolamento".
(Potete leggere un post specifico di Joanna qui: http://theinvisiblethings.blogspot.com/2008/09/three-approaches-to-computer-security.html)
TH: Ma perché concentrarsi su un solo approccio. Un sviluppatore non dovrebbe lavorare sul principio di "Sicuro per progettazione ", e poi declinarlo in quello di "Sicurezza per isolamento".
Joanna: Certo, ma dovremmo progettare i nostri sistemi a partire dall'idea che ogni applicazione può avere dei bug, e il SO dovrebbe essere in grado di proteggere le altre applicazioni da quelle malfunzionanti o malevole.
TH: Puoi darci qualche consiglio pratico? La maggior parte delle tue ricerche riguarda aspetti estremi della sicurezza, e attacchi molto sofisticati, e la maggior parte del malware in circolazione nemmeno si avvicina a certi livelli. Cosa consigli ai nostri lettori per rendere più sicuri i propri sistemi.
Joanna: Si tratta di una domanda molto generica, ed è difficile dare un'unica risposta che soddisfi tutti i bisogni.
Strategie di difesa, continua
TH: Che cosa fai per i tuoi sistemi di uso quotidiano?
Joanna: Come dicevo, credo nell'approccio dell'isolamento. Il problema è che tutti i sistemi operativi più popolari, Windows, Mac OS e Linux, non offrono un isolamento accettabile per le applicazioni. Questa situazione è la conseguenza di kernel monolitici pieni zeppi di driver di terze parti che hanno gli stessi privilegi del kernel. Come risultato, è relativamente facile, per un'applicazione malware, introdursi nel kernel e aggirare tutte le impostazioni di sicurezza del sistema operativo.
Cerco quindi di migliorare questo debole isolamento con la virtualizzazione. Uso diverse macchine virtuali per eseguire diversi tipi di browser, che uso per diverse attività. Così mi ritrovo con una VM "Rossa" per la navigazione quotidiana, cioè le attività poco sensibili, come la lettura di notizie, le ricerche, etc., una"Gialla" per cose di media criticità, come lo shopping, l'aggiornamento del blog, e simili, e infine una VM "Verde" per le cose delicate, cioè l'accesso al conto bancario.
Non m'importa molto dei rischi che ha la VM "rossa", e infatti la ripristino ogni settimana. Curo un po' di più quella gialla, per esempio disattivando gli script nel browser, fatta eccezione per alcuni siti che m'interessano davvero. Qualcuno potrebbe usare un strategia "man-in-the-middle" (MITM) su una connessione HTPP inserita tra quelle permesse, e iniettare del codice pericoloso, ma, trattandosi della macchina "gialla" me lo posso permettere. La macchina "verde", invece, ammette solo connessioni sicure HTTPS da e verso il sito della banca. È molto importante assicurarsi che questa macchina usi solo connessioni HTTPS per ridurre il potenziale pericolo degli attacchi MITM, che potrebbero verificarsi, per esempio, con il WiFi di un albergo.
Uso queste impostazioni da un po' di tempo, e devo dire che mi ci trovo piuttosto bene. La mia compagna, che non ha nulla a che vedere con la tecnologia, usa impostazioni simili sul suo Mac, e ci si trova bene. Immagino che non sia una cosa troppo tecnica, dopotutto.
C'è qualche altro dettaglio che va preso in considerazione, riguardo a queste impostazioni, per esempio la gesione degli aggiornamenti, l'uso della clipboard, il trasferimento di file, dove tenere il client di posta, perché usare la VM verde solo per tenerci un browser, e altre ancora. Immagino però che questa non sia la sede adatta per parlare di tutti i dettagli, altrimenti questa intervista diventerebbe una guida.
In ogni caso, non posso dire di essere del tutto soddisfatta. Per attivare tutte le mie macchine virtuali uso un hypervisor di tipo II (VMWare Fusion), che è una pesante applicazione attiva sulla macchina principale. Da un punto di vista teorico, non ci sono ragioni per credere che sia più difficile trovare un bug nell'hypervisor rispetto al sistema operativo in sé. Entrambi sono grandi e grossi, e accolgono molti driver. Praticamente, però, sembra più difficile violare un hypervisor: un malintenzionato dovrebbe trovare un modo di eseguire del codice nel kernel virtualizzato. Ricordate che l'attacco si base sulla possibilità di eseguire codice nel browser, da cui poi bisogna trovare un modo di attaccare la VMM (hypervisor). Poi bisogna uscire dalla VM e colpire il sistema operativo sottostante, che potrebbe anche essere un SO del tutto diverso da quello della VM. Nel mio caso, per esempio, uso Windows virtualizzato su Mac OS.
Quanto è corretta la "Sicurezza per correttezza"?
TH: Usi Googla Chrome?
Joanna: Sì, lo uso sulla macchina rossa. La ragione principale è la sua GUI, la velocità e il fatto che supporta praticamente ogni cosa, dagli script al flash, necessaria per la navigazione quotidiana.
In ogni caso, si tratta sempre di una soluzione temporanea. L'ideale sarebbe avere un hypervisor molto leggero, come Xen, caricato in maniera sicuro al momento dell'avvio (tramite qualcosa simile all'Intel TXT), e poi usare questo hypervisor leggero per gestire tutte le VM. Naturalmente per alleggerire davvero un hypervisor bisognerebbe rimuovere tutti i driver e gli emulatori di I/O, e per farlo abbiamo bisogno delle tecnologie Intel VT-d (da non confondere con VT-x) o la AMD IOMMU. Allo stato attuale delle cose, è possibile farlo un con portatile basato su una CPU Centrino 2, e l'Hypercore Phoenix e il Project Independence di Xen rappresentano dei tentativi in questa direzione. Ad oggi, però, gli hypervisor ti tipo II, quelli "grassi", sono l'unica opzione.
TH: Passando al livello successivo, quindi, cose come i firewall, i software anti-spyware a antivirus non sembrano essere una protezione adeguata, almeno non contro il malware più sofisticato. Al momento non crediamo che ci sia in circolazione malware simile ma, dopotutto, potremmo semplicemente non esserne al corrente. Cosa possiamo fare?
Joanna: Quello che ci può proteggere è un buon design del SO (o un hypervisor e un SO), non un'applicazione di terze parti applicata ad un design non sicuro.
TH: Quindi la sicurezza della progettazione è importante?
Joanna: Solo quella di alcuni componenti critici del sistema (kernel/hypervisor), non di tutto il software in generale.
TH: Come consumatori abbiamo un modo di spingere le aziende ad assumere un approccio più attivo per quanto riguarda la sicurezza?
Joanna: Sfortunatamente non credo che esista un modo semplice di farlo. Molto semplicemente, non ci sono in circolazione prodotti validi tra i sistemi operativi. Che sia Mac, Windows o persino Linux, tutti questi SO usano grossi kernel monolitici, ricolmi di driver di terze parti. Questa situazione crea un enorme vettore per possibili attacchi contro i dispositivi d'isolamento del sistema operativo, come la separazione dei processi, quella degli account utente o la protezione del kernel.
TH: Il furto d'informazioni è una cosa molto delicata. Se ti sottraggono i dati della carta di credito, la puoi bloccare, e la polizia potrebbe persino riuscire a trovare i colpevoli. Se invece ti rubano, per esempio, dati riguardanti la tua situazione sanitaria, le conseguenze potrebbero essere disastrose.
Joanna: Verissimo. D'altra parte sembra che molte persone non abbiano problemi a usare servizi online per tenerci informazioni personali sensibili, dalle agende ai documenti, e persino i dati sanitari, tramite Google Health. Prendiamo pure per vero il fatto che Google, o altri servizi simili, sia del tutto affidabile come azienda; non significa che ci si possa fidare al 100% di chi ci lavora. Ad oggi, per fortuna, la maggior parte delle informazioni personali è sui nostri computer, e non online. Se (quando) saremo tutti passati "nella nuvola", un computer infetto potrebbe comunque rappresentare un pericolo, se è quello che usiamo per accedere ai servizi online. Quindi sì, la sicurezza del PC è l'aspetto più importante della sicurezza informatica in generale, e le implicazioni di una scarsa attenzione potrebbero andare ben oltre il furto del numero della carta di credito.
Quanto è corretta la "Sicurezza per correttezza"?, continua
TH: La maggior parte delle persone obietterebbe che comunque la si metta la base di tutto sta nella sicurezza "per design". Bisogna verificare attentamente il codice, che deve essere scritto con cura sin dal primo momento. Solo in questo modo di ottiene la migliore probabilità di successo, rispetto ad un approccio di correzioni (patch) successive, dovute al fatto che si riutilizza codice che è stato scritto in un periodo nel quale la sicurezza non era una questione importante. Tutti gli altri elementi, come l'isolamento, aggiungono ulteriori layer di sicurezza. È corretto?
Joanna: Io sono piuttosto scettica verso l'idea di "Sicurezza dalla correttezza". Non mi aspetto che le applicazioni, i driver, e il software in generale possano diventare privi di bug in tempi ragionevoli, e probabilmente non potranno mai. Sarebbe meglio concentrarsi sulla creazione di componenti leggeri, che potrebbero davvero essere privi di bug, come gli hypervisor di tipo I, e poi inserirli in un ambiente ben isolato rispetto agli altri componenti, per limitari i possibili danni (per esempio un browser danneggiato, usato per le ricerche quotidiane, non influenzerà il browser sicuro usato per l'home banking). L'industria della sicurezza sembra invece credere all'approccio "Sicuro perché corretto", e che gli sviluppatori, un giorno, smetteranno di fare errori e di inserire bug nel proprio lavoro. O almeno è quello che vogliono farci credere.
Quando leggo notizie su un nuovo bug in IE, o Adobe Reader o Flash Player non posso fare a meno di scrollare le spalle e dire "e allora, che cosa cambia?"
TH: Oggi niente, ma dovremmo comunque tentare di rendere il codice più sicuro, specialmente quando creiamo cose nuove. Prendiamo il tuo esempio del browser compromesso sulla macchina rossa, a confronto con un browser più sicuro su una macchina separato, usato per accedere alla banca. Dov'è il vantaggio nel proteggere un browser che ha uno o più bug, che mi permette di vedere le informazioni di altri?
Joanna: Qui parliamo però di sicurezza dal lato server, mentre fino ad ora ci siamo concentrati sui computer personali. Si tratta di una cosa molto diversa, così come le soluzioni necessarie. Permettimi di chiarire un punto: rispetto molto l'abilità di quelli che cercano e sfruttano i bug nei browser, è un'attività davvero notevole. Ma è irrilevante per chi cerca di sviluppare macchine più sicure, perché non riusciremo mai a chiudere tutti i buchi presenti in IE o Firefox, che sono applicazioni in continuo sviluppo ed espansione. Quando IE7 sarà stato completamente rivisto, bisognerà ricominciare con IE8, e così via. Naturalmente per i produttori di software come Microsoft è più facile rispondere ai problemi, quando compaiono, con una patch. È certamente molto più semplice che prendere un sistema operativo e riprogettarlo da zero, e poi far riscrivere tutti i driver ai produttori di hardware.
Mi sembra curioso come tanti esperti di sicurezza si concentrino su temi di alto profilo tecnico, come l'heap-based overflow, e allo stesso tempo non siano coscienti delle novità introdotte dalle tecnologie recenti e del loro potenziale per aumentare la sicurezza. Certo, è divertente scrivere exploit per le applicazioni, ma entrare in questo rincorrersi senza fine non è certo il modo migliore di rendere i computer più sicuri. Non si migliora la sicurezza cercando bug e scrivendo exploit.
Quanto è affidabile un ecosistema eterogeneo?
TH: Forse l'approccio giusto è l'isolamento delle applicazioni e lo sviluppo di servizi sicuri "by design" I server usati per i servizi cloud dovrebbero avere molte applicazioni isolate, ma in questo caso dovremmo ancora fare affidamento sulla "sicrezza per design", giusto?
Joanna: Certo. Come dicevo la sicurezza dal lato server è una questione completamente diversa rispetto a quella dei desktop.
TH: Sembra che noi, come comunità, dovremmo evitare la standardizzazione e la diffusione di massa di hardware e software. Un ospedale, per esempio, può comprare centinaia di computer in colpo solo, tutti dello stesso modello. Se emerge che la scheda madre, o la CPU, hanno un difetto, allora tutta l'istituzione è a rischio. Dovremmo, in casi simili, considerare ecosistemi più eterogenei? Magari dei sistemi Intel e alcuni AMD? Magari mischiando Windows, Mac OS e Linux?
Joanna: Una cosa del genere potrebbe chiamarsi "sicurezza tramite l'oscuramento". Se ci preoccupano gli attachi DoS sarebbe certamente d'aiuto. Se, invece, ci preoccupa il furto d'informazione, che implica un attacco più mirato, allora avremmo solo un falso senso di sicurezza, dando per scontato che l'ospedale usi sistemi operativi comuni, non versioni personalizzate e ricompilate di Linux.
TH: Probabilmente dipende da quanto è sofisticato l'ospedale. Ci sono i server, che hanno un sistema operativo dedicato, e poi i terminali, che in generale sono Windows o Mac.
Joanna: Potrebbero essere anche distribuzioni Linux generiche. Per l'attaccante non farebbe nessuna differenza.
Quanto è affidabile un ecosistema eterogeneo?
TH: È l'approccio "a strati". Si può andare a cercare direttamente l'informazione, che è conservata da qualche parte di un sistema cloud. Oppure si può andarla a cercare nel sistema dell'utente finale, che accede a quel sistema. Se si trova, per esempio, un bug in Windows che permette di compromettere un intero sistema, un organizzazione dotata di un sistema eterogeneo potrebbe isolare velocemente tutti i sistemi Windows, e continuare a lavorare con Linux e OS X.
Joanna: Come dicevo, questo sistema può servire solo a limitare gli attacchi DoS, non a prevenire il furto d'informazioni. Una variante dell'approccio "per oscuramento" in molti SO. Per esempio c'è la tecnica ASLR, che agisce sul layout della memoria, e che fu introdotta su Linux con la patch PaX, poi portata su Windows Vista, e che arriverà anche su Mac OS X,
Un'altra tecnica è la protezione degli stack tramite i cosidetti "canaries", che sono valori inseriti in uno stack per individuarne e controllarne l'overflow. Anche in questo caso siamo in presenza di un approccio "per oscuramento". L'idea fu introdotta da Stack Guard su Linux circa dieci anni fa, ed è presente da tempo anche nel compilatore Visual Studio di Microsoft.
Quindi raccomanderei di usare approcci specifici che sfruttano anche questo il concetto di eterogeneità, piuttosto che investire molto denaro in un ecosistema con tre diversi sistemi operativi, affinché sia possibile isolarne uno in caso di bisogno. Sarebbe, tra l'altro, una scelta probabilmente inutile e potenzialmente dannosa.
TH: A meno che fossimo paranoici e preferissimo applicare tutti gli approcci di cui abbiamo parlato su diverse macchine.
Joanna: Quale sarebbe il beneficio, a parte la protezione da attacchi DoS?
Qualche raccomandazione
TH: Se dovessi dare qualche raccomandazione, consiglieresti Mac, PC o Linux. O piuttosto ritieni che siano altrettanto (in)sicuri?
Joanna: Dipenderebbe dalle cose che si vogliono fare con il sistema. Se una persona davvero paranoica mi chiedesse aiuto su come impostare un sistema per attività critiche, potrei suggerire misure estreme come uno Xen personalizzato, che userebbe cose come la VT-d per la disagreggazione Dom0, TPM e TXT per l'avvio sicuro, e isolamento di alto livello tramite partizioni personalizzate DomU. Ogni DomU, poi, avrebbe una versione rinforzata di Linux.
Per usi generici e comuni mortali, tuttavia, raccomanderei tanto Windows quanto Mac. Linux, purtroppo, è ancora indietro quanto a supporto periferiche. Non potete sincronizzare l'iPhone con Linux, per esempio, ed è difficile anche impostare la connessione 3G, con un portatile Linux.
Chi non ha molto a cuore l'estetica probabilmente sceglierà un sistema Windows, mentre altri non possono fare a meno delle linee eleganti di un Mac. A conti fatti, è solo una questione di estetica e d'interfaccia, secondo me.
Non importa se si sceglie un PC o un Mac, l'unica risposta seria, oggi, al problema della sicurezza è la virtualizzazione, per ottenere l'isolamento necessario tra le varie applicazioni, o almeno tra i browser, come dicevo prima. Un antivirus, almeno uno di quelli odierni, sarebbe uno spreco di denaro e di risorse, per come la vedo io. È successo persino che l'antivirus stesso avesse dei bug, che introducevano delle vulnerabilità ai sistemi che dovevano proteggere! Io non uso nessun antivirus, nemmeno sulle macchine virtuali, e non vedo come uno di questi programmi possa offrire un qualche miglioramento alla sicurezza, con le impostazioni che ho creato per rafforzare la virtualizzazione.
TH: Ultima domanda. Uno studio recente mette in evidenza come nel settore dei computer le donne siano ancora poco rappresentate. C'è un qualche consiglio che vorresti dare alle donne che interessate alla tecnologia?
Joanna: Vorrei avere la risposta. Molti studi suggeriscono che le ragazze e le donne vanno peggio, quando si tratta di scienza e tecnologia, soprattutto perché tutti si aspettano che sia così. In ultima analisi, si tratta di una manifestazione della società patriarcale. Fortunatamente in molte parti del mondo questo sistema, fatto di uomini forti e intelligenti e donne belle e sensibili, sta diventando obsoleto, quindi c'è speranza per il futuro.
TH: Speriamo che qualcuno dei nostri lettori trovi ispirazione nelle tue parole. Grazie per il tempo che ci ha dedicato, Joanna.
Joanna: È stato un piacere, e congratulazione a tutti i lettori che sono riusciti ad arrivare in fondo.