Repliche estive: “Hasta la vista” (20 ottobre 2006)

Nel periodo estivo le televisioni sono ripartite come di consueto con le repliche. E se lo fanno loro, lo faccio anch’io. Per qualche settimana pubblicherò delle repliche di articoli apparsi sul defunto sito di ISMProfessional.

Questa settimana ripropongo un articolo che parlava di come rendere totalmente inefficaci tutte le misure di sicurezza che venivano sbandierate come la soluzione definitiva al problema malware che affligge tutte le versioni di Windows. Buona lettura.

Tutto nasce da una presentazione trovata da Massimiliano, che tratta di come evitare che malware sofisticati nascondano se stessi e prove della loro presenza ai normali strumenti di rilevamento, in particolare ai kit per l’analisi forense.

Al termine della presentazione, peraltro incentrata su un prodotto specifico, fra i riferimenti c’era il sito di Joanna Rutkowska, ricercatrice di sicurezza già nota per la tecnica della “pillola rossa”, un pezzo di codice in grado di rilevare se è in esecuzione dentro una Virtual Machine. Uno degli ultimi post del suo blog è una presentazione dal titolo Subverting Vista Kernel For Fun And Profit, la cui lettura consiglio caldamente.

Per chi non ha tempo, riassumo brevemente.

Una delle nuove feature di Vista sotto la categoria sicurezza è il controllo della firma crittografica di tutti i file di sistema prima di caricarli ed eseguirli, firma che viene collegata alla presenza del famigerato chip TPM (Trusted Platform Module), e grazie alla quale neanche l’amministratore può caricare un driver non firmato. Esistono ovviamente dei modi per aggirare questo ostacolo, ad esempio entrando in modalità debug, ma tutti richiedono un riavvio del sistema.

Joanna mostra nelle slide che senza usare magia nera, con funzioni documentate nel SDK di Vista è possibile iniettare codice a piacere al livello di driver di sistema, quindi nel ring0, il sancta sanctorum del kernel. E scusate se è poco.

La procedura, una volta spiegata, non è complicatissima. L’idea di base è di cambiare il codice eseguibile in memoria di un driver o di una porzione del sistema operativo quando viene paginato sul file di scambio.

La sequenza è questa:

  1. diciamo che il nostro malware riesce ad entrare nel computer ed attivarsi usando un account amministrativo (fin qui niente di strano)
  2. il malware inizia ad occupare memoria per costringere il sistema operativo a paginare su disco tutto il superfluo. Fra queste cose vi sono porzioni di codice dei driver marcate come “paginabili”, ossia che si possono spostare temporaneamente sul file di scambio. Ad esempio il driver di sistema del device NULL ha la porzione di codice che esamina ogni richiesta di agire sul device (denominata dispatch) marcata come “paginabile”.
  3. quando l’occupazione di memoria è sufficientemente grande, il malware è ragionevolmente certo che tutto quello che non è usato è stato scaricato nel file di scambio. A questo punto non deve fare altro che una ricerca nel file di scambio per una sequenza di alcune decine di byte caratteristiche del codice del driver scelto come bersaglio. Se la sequenza è sufficientemente lunga si ha la ragionevole certezza che si trova solo nel punto in cui è paginata la parte di codice cercata.
  4. parte l’attacco: il malware, accedendo al device fisico su cui risiede il file di scambio soprascrive pochi byte nel punto dove è paginato il driver (operazione permessa ai processi che girano con diritti di amministratore). Ora il codice del driver contiene una istruzione di salto al codice del malware. Oppure può saltare in una zona di memoria che contiene codice scaricato dal malware. I limite è solo la fantasia (o la perversità, fate voi).
  5. rimane il problema di come attivare il codice modificato. Niente di più semplice: aprire il device modificato con una operazione normalmente innocua, ad esempio lettura. Il sistema operativo diligentemente riporterà in memoria la porzione del driver del device modificata e la eseguirà. Il malware è ora in ring0. In barba a firme crittografiche, TPM e tutto il resto.

Nel seguito della presentazione Joanna espone alcune strategie per impedire lo sfruttamento di questo metodo, ma tutte coinvolgono una limitazione di operatività, oppure hanno un impatto sulle prestazioni, o richiedono una massiccia riscrittura di gran parte dei driver o del kernel.

Nella seconda parte presenta un concetto di rootkit che, pur rimanendo un concetto, fa veramente paura. Cito (riassumendo e semplificando):

I rootkit basano la loro invisibilità su una idea di base, e sfruttano la “security by obscurity”: ad esempio trovano il modo di cancellarsi dalla lista dei processi attivi, o modificano il blocco di dati che viene ritornato dalle funzioni del sistema operativo demandate al controllo dei processi. Una volta scoperto il trucco si può creare un rivelatore e scoprire il rootkit.

Provate ad immaginare un rootkit tale che, pur conoscendone nei dettagli il funzionamento, ed avendo il codice aperto e liberamente disponibile per l’analisi, sia assolutamente non rilevabile.

Insomma la pillola blu del noto film.

Le rimanenti pagine della presentazione sono assolutamente incomprensibili per chi non ha dimestichezza con le architetture dei moderni microprocessori, ma in sostanza Joanna traccia un quadro assolutamente impressionante: un rootkit che una volta insediato in ring0 crei una macchina virtuale ed in un colpo solo sposti il sistema operativo con tutto quello che c’è caricato in quel momento un livello sotto, mentre è in esecuzione, “on the fly”.

Da quel momento il rootkit lavora come un hypervisor, il programma di controllo tipico dei sistemi di virtualizzazione (vedere Xen o VMWare), ispezionando l’attività del sistema operativo, che ora non è più host ma guest.

Siamo dentro una macchina virtuale, sappiamo di esserlo, sappiamo come funziona, ma non possiamo in alcun modo sfuggire al rootkit, perché controlla “dall’alto” tutto quello che sta combinando il sistema operativo. Non solo, sfruttando il metodo esposto prima per infiltrarsi, il rootkit può risiedere totalmente in memoria, quindi non essere rilevabile con l’analisi live per la presenza della macchina virtuale, e non lasciare tracce (o quasi) dopo un riavvio con un kit di analisi forense.

E’ rimasta solo la pillola blu.

Oggi invece

Sono passati 18 mesi dalla pubblicazione dell’articolo. Informaticamente parlando una intera era geologica.

La pillola blu è una realtà, non si limita ad una specifica versione di Windows, ed ha molte più feature di quelle del primo prototipo.

Microsoft ha preso atto di questo tipo di attacco ed ha totalmente disabilitato l’accesso da userspace ai device fisici rappresentanti i dischi, chiudendo apparentemente la porta a tutta questa categoria di malware.

In realtà, come spiega Joanna in un successivo articolo, ne ha aperta una grande il doppio. Ora tutti i produttori di utility di controllo e manutenzione dei dischi dovranno scrivere il proprio driver da installare ed eseguire nel kernel space. Con tutte le (non troppo ovvie) conseguenze del caso.

Riferimenti

3 pensieri su “Repliche estive: “Hasta la vista” (20 ottobre 2006)

  1. Serendippo

    ehm, non ci ho capito molto, ma a intuito butto lì un paio di domande: (1) onestamente, i sistemi Linux sono esenti o coinvolti in questa sindrome della ‘blue pill’? In caso affermativo, una spiegazione per gli illetterari, grazie… (2) perché adesso la porta è grande il doppio? forse era solo una battuta, ma se non rido me la spieghi?
    Grazie e ciao

  2. Mario Pascucci Autore articolo

    Ciao Serendippo, bentornato. Quasi sentivo la tua mancanza ;-)
    Passo a risponderti. Per quanto riguarda il “blue pill” nessun sistema operativo è immune, ce n’è per tutti. In un prossimo “hackmeeting” Joanna ed i suoi presenteranno sistemi e tool per sovvertire Xen, ossia far andare Xen dentro una macchina virtuale “ostile”. A suo tempo hanno già “impasticcato” con il blue pill VirtualPC, VirtualBox e VMWare workstation. Il punto in tutte le sue dimostrazioni è che una volta che si è guadagnato l’accesso “root” ad un computer *niente* ti può salvare.
    Per quanto riguarda la porta aperta, il fatto che ogni produttore debba svilupparsi il suo driver in kernel space per accedere a basso livello ai dischi implica che la possibilità di avere driver “deboli” dal punto di vista sicurezza diventa molto più reale. Lo dice Joanna stessa nel suo articolo, suggerendo la strategia di “prendere in prestito” il driver da una di queste applicazioni per accedere a basso livello al disco e portare lo stesso attacco al file di scambio.
    Spero sia più chiaro ora.

  3. Pingback:   Repliche estive: “Un malware veramente cattivo #2: trovami, se ci riesci…” (20 dicembre 2006) — Il non-blog di Mario Pascucci

I commenti sono chiusi.