MBR rootkit si trasforma e torna all'attacco

Quando il MBR rootkit venne isolato a cavallo tra la fine del 2007 e l’inizio del 2008, fu immediatamente chiaro che si trattava di un’infezione senza precedenti, differente da ogni tipologia di infezione vista in the wild. Il proof of concept era conosciuto dal 2005 ma nessuno si aspettava di vedere un malware in the wild utilizzare questa tecnologia. Bastarono pochi mesi al MBR rootkit per diventare una delle peggiori minacce dello scorso anno, con decine di migliaia di PC infetti.

Anche se la prima variante del MBR rootkit non viene ancora individuata da alcuni prodotti antivirus, i suoi creatori hanno deciso di svilupparne una nuova versione, capace di passare inosservata a tutti i prodotti di sicurezza, anche quelli che si erano dimostrati in grado di individuare la prima release. I nostri laboratori di ricerca hanno cominciato a ricevere nuove segnalazioni di questa infezione dai primi giorni di Aprile.

Se il primo MBR rootkit era già sufficientemente complesso, questa nuova variante è ancor più complessa da individuare. Il Master Boot Record è ancora l’obiettivo principale, ma il modo con cui il rootkit si nasconde nel sistema è qualcosa di tecnologicamente impressionante. Entro fine settimana rilasceremo un nuovo prodotto, Prevx 3.0, che tra le altre cose è in grado di individuare e rimuovere l’infezione gratuitamente.

La prima variante del MBR rootkit utilizzava degli IRP hook per filtrare ogni tentativo di accedere in lettura e scrittura al MBR. Il driver di sistema disk.sys, utilizzato per gestire l’accesso ai dischi, veniva compromesso e le funzioni di Windows adibite alla gestione dei pacchetti diretti ai dischi venivano sostituite con quelle del rootkit. Ovviamente ogni riferimento in memoria alle originali funzioni rimpiazzate veniva manomesso, in modo da rendere più complesso il tentativo di pulizia del sistema.

Manomettere il driver disk.sys significa lavorare veramente in profondità, riuscendo a rendere inoffensivi anche quei prodotti di sicurezza che affermano di leggere i dischi a basso livello.

Tuttavia, quando il MBR rootkit infettava il sistema, era comunque semplice capire che il sistema era stato compromesso a causa della presenza di thread di sistema orfani e hook IRP che puntavano a zone di memoria non identificabili.

La nuova versione del MBR rootkit è sufficientemente intelligente da far passare un brutto quarto d’ora ai ricercatori, a causa delle tecniche di hooking molto più avanzate e di una presenza massiccia di codice offuscato. Il rootkit sta ancora utilizzando hook IRP, ma in maniera molto più subdola.

Innanzitutto non manomette più il driver disk.sys, va molto più in profondità, attaccando il driver al quale il device DeviceHarddisk0DR0 è collegato. Una volta identificato, la funzione IRP_MJ_INTERNAL_DEVICE_CONTROL del driver viene manomessa.

Se il driver a cui il device in questione è collegato è atapi.sys, dunque l’hook sarà presente in atapi.sys. Se il driver è acpi.sys, dunque l’hook sarà presente in questo driver. Se il driver è vmscsi.sys, quest’ultimo sarà alterato. Si possono ottenere risultati diversi da PC a PC, e da PC a virtual machine quali VMware.

Molto interessante, ma la parte veramente intelligente deve ancora arrivare. Questo hook, utilizzato per nascondere il MBR, è configurato al volo, in tempo reale, ogni volta che il rootkit intercetta un tentativo di leggere il Master boot Record aprendo un handle al diso rigido. Poi, quando l’handle viene chiuso, l’hook è rimosso immediatamente dal rootkit. Tutto risulta pulito, nessun hook immediatamente riscontrabile.

Ecco la cosa più impressionante: per capire quando qualcuno tenta di aprire un handle al disco, il rootkit utilizza una tecnica denominata Direct Kernel Object Hooking. Questa tecnica, già conosciuta da diverso tempo ma poco utilizzata a causa della complessità, attacca gli oggetti del kernel di Windows. Facendo cuiò, eventuali attacker possono controllare ed alterare il comportamento del sistema operativo sedendo in uno dei posti in prima fila. Alcune varianti del rootkit Rustock hanno utilizzato questa tecnica.

Tuttavia, anche questo attacco può essere individuato. In verità, se si tenta una scansione dei Windows kernel objects su un sistema infetto dal MBR rootkit, niente sembrerà essere stato manomesso. I creatori del MBR rootkit sapevano di poter andare più in profondità del semplice DKOH, e lo hanno fatto.

Prima di spiegare come hanno agito, vorrei sottolineare che una tecnica similare è stata utilizzata per nascondere degli hook SSDT.

Individuare hook SSDT è veramente banale, perché basta analizzare il System Service Descriptor Table alla ricerca di discrepanze, redirezioni, inline hook, o anche un mix di tutte queste tecniche. Cosa accadrebbe però se qualcuno forzasse le applicazioni ad utilizzare un’altra System Service Descriptor Table che altro non è che una copia dell’originale ma con gli hook settati? Un attacker è in grado di reindirizzare arbitrariamente le applicazioni ad utilizzare una falsa SSDT e lasciare le applicazioni di sicurezza analizzare l’originale SSDT che non sarà stata dunque toccata. Un anti-rootkit che non si aspetta una tecnica simile non troverà niente di compromesso nel sistema, nessun hook nell’SSDT.

Una volta che si ha la padronanza di questo concetto, si può capire come funziona il nuovo MBR rootkit. Si tratta solo di un’applicazione più complessa e più in profondità, ma il concetto è praticamente lo stesso.

Spiegato nella maniera più semplice possibile, ogni oggetto come un oggetto device in Windows è definito da una struttura immediatamente precedente l’oggetto stesso. Questa struttura, denonimata object header, definice l’oggetto, assegnandolo al relativo kernel object. Per esempio, il device object DeviceHarddisk0DR0 è definito come kernel object “Device”.

Ora, se qualcuno volesse manomettere l’oggetto di sistema “Device”, potrebbe rimpiazzare i suoi metodi. Tuttavia sarebbe facilmente identificabile da una qualsiasi scansione degli oggetti di Windows. Questo non è quello che gli autori del MBR rootkit vorrebbero, l’infezione non sarebbe sufficientemente nascosta.

Dunque cosa hanno deciso di fare? Hanno creato un oggetto di Windows personalizzato, sulla falsa riga del kernel object “Device”. Questo nuovo object, tuttavia, è manomesso. Esattamente il metodo ParseProcedure è stato compromesso. Una volta facco ciò, il device DeviceHarddisk0DR0 viene definito non più come l’object originale “Device”, bensì viene definito nel suo object header come il nuovo object appena creato.

Facendo ciò, l’hook sarà totalmente invisibile ad una semplice scansione anti-DKOH perché i kernel object non sono stati alterati.

Quando un handle al device viene aperto, il rootkit configura immediatamente l’hook IRP e setta un hook globale al kernel object “File”, modificandone il metodo CloseProcedure. Facendo ciò, il rootkit è in grado di sapere quando l’handle verrà chiuso, così da essere in grado di rimuovere i propri hook.

Il funzionamento di questa infezione è veramente impressionante. Un altro motivo per cui non dovremmo veramente preoccuparci al momento di SMM rootkit o attacchi alle CPU più di quanto non dovremmo già esserlo per le minacce attuali. Neprodoor, il nuovo MBR rootkit e molti altri sono tutti attacchi in the wild che stanno mettendo in evidenza le difficoltà dei prodotti di sicurezza a combattere contro questi malware.

I laboratori Prevx hanno già identificato molte infezioni causate dal nuovo MBR rootkit e sono numeri che tenderanno a crescere molto velocemente, visto il trend seguito dalla prima variante del rootkit lo scorso anno.

Abbiamo già scritto le routine di individuazione e pulizia perquesta infezione. Sarà rilasciato un importante aggiornamento durante la settimana ai prodotti Prevx che, tra le altre cose, includerà anche questa funzionalità. La rimozione di questa infezione sarà gratuita.

Prevx Blog