Siamo quasi al termine delle repliche estive. Ancora un altro articolo e abbiamo terminato. Qui esaminavo una classificazione dei malware proposta dalla ricercatrice di sicurezza Joanna Rutkowska. Ci rileggiamo alla fine per le oziose considerazioni di rito.
Un malware veramente cattivo #2: trovami, se ci riesci…
Nel precedente articolo abbiamo mostrato (con l’aiuto di Joanna Rutkowska) come risolvere il problema di comunicare con l’esterno senza essere scoperti.
Qui vedremo le opzioni a disposizione dei malware per occultarsi invece all’interno del computer colpito.
Ogni malware, come sappiamo, è un programma, una porzione di codice che deve essere eseguita per rendere attivo il malware stesso. Una volta attivato e compiute le operazioni necessarie a stabilirsi, rimane da risolvere il problema di evitare di essere scoperto troppo facilmente. Un malware che si fa scoprire ha vita breve, mentre lo scopo è quello di agire senza insospettire né il normale utente, né l’amministratore di rete più smaliziato.
In realtà questo problema ha due aspetti: sfuggire sia all’occhio umano, sia agli strumenti automatici di rilevamento (antivirus, rootkit checker, ecc.). Joanna propone una classificazione ragionata dividendo i malware in quattro classi, in funzione del modo in cui si insediano e di come questo li renda difficili da rilevare.
Tipo 0
L’insediamento avviene con un normale programma, che usa le normali funzioni del sistema operativo per essere avviato per esempio come servizio di sistema. In questo caso il malware compare fra i processi in esecuzione, ed ha una porzione di memoria dedicata come tutti gli altri. La sua rilevazione è piuttosto semplice, in quanto con le normali funzioni di controllo del kernel se ne può controllare lo stato di esecuzione, le risorse impegnate, ecc.
Ad esempio un classico botnet agent come Gaobot è un malware di tipo 0. Il fatto che alcuni malware, come Gromozon, adottino delle strategie molto sofisticate per non essere rimossi, non cambia il fatto che rimangono malware di tipo 0, usando sempre e solo API documentate del sistema operativo per agire.
Tipo I
I malware di questo tipo non si presentano come processi separati, ma si agganciano al codice di altri processi sia del kernel che di servizi di sistema fondamentali. Una volta attivati non si notano processi aggiuntivi, ma un servizio di sistema, una porzione del kernel, un driver o una applicazione fondamentale per il funzionamento del sistema divengono portatori del malware, che si esegue nello stesso processo.
Per far questo viene modificata una parte dell’immagine in memoria del processo preso di mira dal malware, con una vera e propria operazione di patching, che aggiunge il proprio codice a quello in esecuzione.
In questo caso è molto più difficile trovare il malware, dato che non ha usato normali API per insediarsi, ma ha modificato il codice di una parte del sistema operativo o di una delle sue applicazioni.
Tipo II
Questo tipo di malware usa una strategia ancora più sofisticata. Il kernel contiene alcune strutture dati che sono in realtà puntatori a funzioni, di dimensione variabile e compilate con i giusti valori al momento dell’avvio del sistema operativo. Ad esempio i driver NDIS sono elencati in una struttura dati di questo tipo. I malware di questo tipo non toccano niente nel codice del kernel o delle applicazioni principali, ma si agganciano ad una di queste strutture dati, modificando un puntatore e inserendosi al suo posto o in aggiunta a quelli già presenti.
Il vantaggio di questo tipo di tecnica è che tali strutture sono modificabili per definizione e non possono essere bloccate, né protette dalle modifiche.
Tipo III
E’ il tipo più temibile: non tocca nulla all’interno del sistema operativo colpito, non genera nuovi processi, non modifica né porzioni di codice né strutture dati, è completamente esterno e fuori dalla visibilità. Al momento l’unica tecnica conosciuta è quella della virtualizzazione, applicata ad esempio nella pillola blu, che abbiamo già conosciuto.
Richiede che l’architettura del computer colpito sia conforme alle specifiche per macchine virtuali sicure, come la tecnologia Pacifica di AMD™ e quella VT-d di Intel™, e quindi è legata ad uno specifico tipo di hardware, ma l’efficacia è devastante.
La ciliegina sulla torta
I malware di tipo 0 e I hanno bisogno di operazioni aggiuntive per non rivelare troppo facilmente la loro presenza. Alcuni agganciano porzioni specifiche del kernel e nascondono le informazioni necessarie a scoprirli: per esempio filtrando l’elenco dei processi in esecuzione o l’elenco dei driver caricati. Il discusso sistema anticopia della nota multinazionale usa un filtro sul filesystem per nascondere i propri file.
Un rootkit sperimentale denominato Shadow Walker usa un sofisticato metodo per capire se un altro processo sta leggendo la zona di memoria in cui risiede il suo codice, tipicamente un antivirus che spazzola la memoria per capire se ci sono segni di malware, e mostra una differente zona di menoria all’antivirus, rendendone impossibile la rilevazione. Ma ha bisogno di modificare la parte di kernel che gestisce la memoria, e questo permette di scoprirne le tracce.
I malware di tipo II pongono un problema del tutto nuovo: non modificando in alcun modo nessuna parte del codice del kernel o delle applicazioni, ma solo strutture di dati che per definizione sono modificabili, diventano del tutto invisibili ai normali meccanismi di rilevamento.
I malware di tipo III, pur limitati ad una specifica architettura hardware, sono del tutto fuori dalla portata di qualsiasi metodo di rilevamento che sia interno alla macchina compromessa.
Sappiamo tutti la difficoltà di rimozione per alcuni tipi di malware, vedi Gromozon, come pure la fatica nel rilevarne la presenza, come il noto rootkit del sistema anticopia. Vedremo in un prossimo articolo le difficoltà che pongono queste nuove categorie di malware, sia per la rilevazione da parte di strumenti automatici che da parte di una persona che sappia dove guardare.
Oggi
Joanna Rutkowska è andata molto più avanti, ed in direzioni impensate. Ora è possibile annidare gli hypervisor, ossia un malware può virtualizzare un sistema già virtualizzato: ecco il NBP (Nested Blue Pill, pillola blu annidata). E’ stato dimostrato che la virtualizzazione, ritenuta dai più anche un modo per rendere più sicuro un sistema operativo, dato che l’hypervisor è in teoria isolato dall’interferenza delle macchine virtuali, non risolve per nulla il problema. Prendendo di mira Xen, il sistema di virtualizzazione usato in Linux, di cui è disponibile il sorgente, è stato dimostrato come sovvertirlo e riuscire da una macchina virtuale a modificare la memoria dell’hypervisor, demolendo di fatto l’assunto base della sicurezza della virtualizzazione.
E’ stato anche dimostrato come aggirare la protezione aggiuntiva offerta dall’architettura VT-d di Intel, grazie ad un bug nel bios di alcuni modelli di schede madri.
Ora, il semplice fatto che sia stato dimostrato che si può fare, dimostra che la virtualizzazione e tutto meno che un sistema di sicurezza. Ma il mondo IT, sordo a queste dimostrazioni, ritenute teoriche ed irrealizzabili in pratica, sta andando esattamente in questa direzione, con l’idea di mettere un semplice hypervisor dentro il sistema operativo allo scopo di proteggere il nucleo principale di esso.
Tutto questo nella Xen 0wning Trilogy di Joanna Rutkowska che vi invito a leggere.
Ma, naturalmente, nessuno userà mai questo per creare malware. Noooooo. Mai. E’ impraticabile.
D’altra parte lo stesso si diceva riguardo l’IP spoofing ed il TCP sequence number prediction. Poi nel Natale del 1994 Kevin Mitnick riuscì a penetrare nel computer di Tsutomu Shimomura usando proprio questo tipo di attacco.
