[NEWS] MBR rootkit si trasforma e torna all’attacco

[c.m.g]

14 April 2009 di Marco Giuliani



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 \Device\Harddisk0\DR0 è 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 ciò, 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 \Device\Harddisk0\DR0 è 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 \Device\Harddisk0\DR0 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




Fonte: PcAlSicuro.com

[riazzituoi]

.

[sampei.nihira]

Quando in natura un virus muta patrimonio genetico radicalmente diviene molto pericoloso per la specie ospite.
Questa infatti non ha alcuna difesa immunitaria per la nuova specie,ed i precedenti contatti non servono più a nulla.
Inizialmente,in epoca pre-antibiotica,si verificava una moria della specie ospite (anche per le complicanze batteriche) che però raggiungeva un picco e non oltre.

I due organismi,per così dire,alla fine si vengono incontro per una esigenza di sopravvivenza.

Se è possibile fare un paragone forzato ma solamente fantasioso si potrebbe concludere che in informatica ancora non abbiamo raggiunto un picco.

E visto che gli "organismi ospiti" ,come massa di utenti, non saranno in grado di sviluppare adeguate difese,dato che sw come Sandboxie,HIPS,browser diversi da I.E. sono quasi sconosciuti ai più,e meno male che i privilegi ridotti sono "anticorpi innati" con i nuovi OS Microsoft,io credo che una serie di "pandemie" nel futuro saranno inevitabili, se continuerà questo trend.

[eraser]

Originariamente inviato da riazzituoi

Questo rootkit per nascondersi utilizza la stessa tecnica descritta da Wenbing Zheng e MJ0011, nel loro lavoro presentato all' XCON 2008...

Cosa intendi a riguardo? Se intendi la tecnica DKOH, non è del tutto vero. Questa tecnica è conosciuta da anni ed è già stata utilizzata da altri rootkit quali alcune varianti di Rustock e, positivamente, da software quali Sandboxie.

Se invece intendi come individuare il driver da filtrare, sì, in questo caso l'idea è concettualmente similare.

[c.m.g]

MBR Rootkit Colpisce Ancora su tweakness

MBR Rootkit ritenta l'attacco su webnews

[FulValBot]

Originariamente inviato da riazzituoi

Questo rootkit per nascondersi utilizza la stessa tecnica descritta da Wenbing Zheng e MJ0011, nel loro lavoro presentato all' XCON 2008...

Comunque la cosa più importante rimane la prevenzione, vale a dire tenere il sistema operativo e i software aggiornati (per quanto riguarda i vari reader o player, meglio non usare i prodotti più blasonati, generalmente affetti da bug exploitati in the wild), imparare ad usare i privilegi ridotti, utilizzare un browser sicuro e configurato come si deve, meglio ancora se sandboxato o utilizzato in un ambiente virtuale.


Adesso ci manca solo il Vbootkit 2

e cosa suggerisci come alternative?

[Blue Spirit]

Originariamente inviato da FulValBot

e cosa suggerisci come alternative?

bhe, io come lettore pdf uso pdfXchange e come lettore multimediale, VLC (e in qualche caso media player classic)...e mi trovo benissimo per rimpiazzare flash player, invece, al momento non saprei