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.
Quale è il vettore dell’infezione? Un exe, un MIME type compromesso da una falla qualunque, una botnet?
Il vettore dell’infezione solitamente sono siti web compromessi contenenti JS offuscati. L’utente viene reindirizzato a siti web contenenti vari exploit che permettono l’esecuzione del malware arbitrariamente su computer non aggiornati
Ho avuto a che fare con due di queste infezioni.
Su entrambi i pc, aprendo il programma edit.com si aveva spesso una segnalazione di errore NTVDM error och e il non funzionamento della tastiera.
Ho poi notato, nel primo, che nel firewall aziendale era presente traffico proveniente da quella stazione non elencato da “netstat”.
Una scansione compiuta con avg e fprot da boot cd linux ha segnalato la presenza di varianti di sinowal (file datato 31 marzo).
La macchina è stata riformattata e reinstallata da zero.
Il secondo pc presentava gli stessi sintomi (non funzionamento della tastiera in applicazioni 16 bit, blocchi). Ho provveduto al ripristino dell’mbr dopo un boot da cd e quindi ho scansionato il sistema sia da linux che da windows senza trovare – al momento – ospiti indesiderati.
Mi chiedo se un reset dell’MBR basti a disattivare il rootkit.
In fatto di infezioni dal WEB mi pare di capire che oltre ad un buon AV siano ormai caldamente consigliati browser con un certo grado di sandboxing, come IE7-8 o Chrome… almeno eventuali exploit con bassi privilegi faranno molti meno danni e difficilmente saranno in grado di installarsi silenziosamente.
Al momento con quali strumenti è possibile individuarne la presenza? Come dice francesco basta il semplice reset dell mbr per rimuoverlo oppure bisogna fare qualcos’altro?
Avendo privilegi limitati si può fare? E ammettendo che si possa fare, Vista 64 con patch guard per evitare modifiche al kernel dovrebbe risultare sicuro giusto?
Mario scrive:
>>Il vettore dell’infezione solitamente sono siti web compromessi contenenti JS offuscati. L’utente viene reindirizzato a siti web contenenti vari exploit che permettono l’esecuzione del malware arbitrariamente su computer non aggiornati
Marco scrive:
>>Il vettore dell’infezione solitamente sono siti web compromessi contenenti JS offuscati. L’utente viene reindirizzato a siti web contenenti vari exploit che permettono l’esecuzione del malware arbitrariamente su computer non aggiornati
Sig Marco
Attenzione perche’ non e’ un normale javascript eseguito dal browser che fa installare il malware nel MBR del disco .Il javascript redirecta solamente il browser sul sito iniettato con l’exploit ..
quello che farebbe installare il malware sul MBR del disco e’ un exploit sul motore del browser che poi evidentemente manderebbe lo stesso browser al 99% in memory corruption ed esecuzione arbitraria da remoto
quale browser?? ce ne sono 6 di browser in giro ..e che falla da sfruttare tramite exploit e’?
Io nn conosco ad esempio su Firefox 3.0.8 vulnerabilita’ da sfruttare tramite exploit che permettano remote code executions
Sig Marco se ci fa sapere quale vulnerabilita’ del browser viene sfruttata da questo explit per installare il MBR RootKit e quali browser ne sono affetti con relativa vulnerabilita non patchata sarebbe ideale
saluti
Salve,
come lei ben saprà tenere un sistema costantemente aggiornato è una delle cose da fare sempre. In questo caso, ci sono tool server side ad hoc che sfruttano vari exploit contemporaneamente, tentando di trovare almeno una applicazione vulnerabile tra le varie conosciute e vulnerabile.
Se il sistema è totalmente aggiornato, nessuno dei browser sarà vulnerabile attualmente. Anche se poi questa stessa affermazione non è del tutto vera, ma forse era troppo impegnato nello scrivere “Sig Marco” per riflettere su queste cose.
Era sottointeso che il js reindirizza a pagine web infette.
Quello che invece non apprezzo è questo “Sig Marco” pronunciato chiaramente in senso ironico e dispregiativo, che testimonia perfettamente il tipo di persona che sta scrivendo.
Distinti saluti
Marco ti do del tu se vuoi
ti ho dato del signor perche’ nn ti conosco e per educazione
le ho fatto domande pacate mi sembra senza offendere nessuno ..
nn capisco perche’ si offende ???
se io navigo con Firefox 3.0.8 che non ha vulnerabilita’ di esecuzione codice arbitrario aperte e con lo stesso Firefox 3.0.8 mi connetto e “browso” un sito web con l’exploit di cui ha parlato lei per far installare questo rootKit sulla MBR del disco , non prendo nulla se anche ho un altro software installato sul sistema non aggiornato e nn lo sto usando per navigare sul sito con l’explit …ovvero nn lo uso
Se navigo e beowso sul sito con l’exploit, chi sara’ sensibile all’exploit e’ e sara’ solo il browser web con cui sto navigando sopra a quelsito “contaminato” con lo stesso exploit , ovvero Firefox 3.0.8 nel mio esempio.
se poi questo exploit sfruttasse una vulnerabilita’ dei plug-ins del browser che interagiscono col browser web stesso in questo caso si deve tenere aggiornati anche la Java Sun VM, il flash player , Adobe reader , Quick Time etc come giustamente deve essere dato sono plug-ins che interagiscono con browser per la visualizzazione di una pagina web
un saluto
Allora mi sarò sbagliato nella lettura del tuo post 😉 E’ che dalle mie parte o si scrive Sig. cognome o altrimenti il nome direttamente, Sig. è piu facile prenderla come una sottile ironia. Ma dammi del tu e risolviamo ogni problema, come fanno il 98% delle persone che commentano questo blog.
Anche in questo caso non è del tutto vero. E’ esatto quello che scrivi tu, era chiaramente sottointeso che per software inizialmente intendevo plugin che interagiscono con il browser ma tenere un sito computer aggiornato ti aiuta e non di poco. Ci si mette poco a far scaricare un pdf ad un utente e il pdf sfrutta qualche exploit del pdf reader.
A questo punto si fa prima a tenere tutti i software aggiornati, non credi? 😉
Marco, siamo tutti d’accordo su quello che dici.
I due computer che mi si sono infettati erano, per quanto mi risulta, aggiornati. Uno dei due è il clone di altri 15 pc tutti allineati come aggiornamenti !
Sarebbe interessante sapere (magari anche in privato) se questa diffusione ha avuto una diffusione attraverso un particolare exploit – magari mi è saltato l’aggiornamento di qualche programma….
Viene usato il NeoSploit tookit che sfrutta
SuperBuddy LinkSBIcons CVE-2006-5820
QuickTime RTSP CVE-2007-0015
Adobe getIcon CVE-2009-0927
Adobe Collab overflow CVE-2007-5659
ed altri
il CVE-2009-0927 dovrebbe essere l’exploit più recente
per scrivere nel MBR sono richiesti i privilegi di amministratore, quindi tutti gli utenti di Windows Vista possono dormire sogni tranquilli dato che nessun utente su Vista ha i privilegi di amministratore essendo abilitato lo UAC
Salve a tutti.Attualmente che si deve fare per sapere se si è infetti??Il mio PrevX mi ha rilevati una cosa del genere, e l’ho rimosso, tutto questo mi è successo al riavvio del sistema!!Altro modo??Grazie!!!
Volevo sottolineare riguardo a tenere tutto ben aggiornato che molte vulnerabilità sfruttate dai malware sono cosiddetti “0day” quindi è consigliabile stare sempre aggiornati ma ciò non significa essere “al sicuro”