È necessario tuttavia rinnovare l’allarme per questa minaccia, che durante questi mesi è stata continuamente aggiornata da parte dei propri creatori.

Il team alle spalle del rootkit sta lavorando costantemente per migliorare la propria creatura. In questi mesi non si sono mai fermati, continuando ad aggiornarlo ogni giorno – in alcuni casi anche piu volte al giorno – e in modo da evitare ogni individuazione tramite signature generiche.

Tutti i dropper del rootkit vengono ricompilati lato server ogni giorno. Questo permette ai creatori di evadere da ogni semplice signature o signature generiche basilari. Effettivamente queste signature sono l’unico vero ostacolo che molti software di sicurezza pongono, perché una volta che l’infezione è attiva è invisibile per la gran parte degli antivirus e antirootkit.

Anche il rootkit vero e proprio è stato aggiornato, con routine di auto-difesa per evitare l’attacco di tool anti-rootkit specifici. È quasi simpatico seguire l’evoluzione del rootkit, sembra di assistere ad una partita di scacchi tra chi attacca e chi difende. È una delle poche volte in cui si possono vedere questi due fronti rispondersi quasi in tempo reale.

Già si sapeva che il rootkit è in grado di infettare uno dei driver di sistema di Windows e filtrare l’accesso al disco fisso in lettura e scrittura. Ora il rootkit ha aggiunto anche un watchdog thread capace di monitorare la chiave del registro di sistema relativa al driver infetto, bloccandone ogni modifica. Facendo così, il rootkit è ora in grado di bloccare alcuni semplice tool di cleanup.

Un’altra tecnica di auto difesa è l’impossibilità per chiunque nel sistema di ottenere un handle al file infetto. In questo modo il rootkit previene alcuni tool anti-rootkit dal leggere il contenuto del file in questione. Le versioni precedenti del rootkit permettevano la lettura del file infetto, ma mostravano la copia originale del file. Questo escamotage veniva utilizzato da alcuni tool di sicurezza per recuperare la copia pulita original del file infetto.

Sorgono tuttavia alcuni dubbi riguardo la vera utilità di questa tecnica di difesa. Se è vero che nessuno è piu ingrado di accedere al contenuto del file, è altresì vero che ora è molto piu facile scoprire quale file è infetto, poiché ogni accesso a quel file sarà negato e molti software di sicurezza riporteranno questa anomalia.

Lo scorso Martedì Microsoft ha rilasciato degli update per Windows, alcuni dei quali critici perché correggono un bug presente in Windows da ben 17 anni. Dopo che alcuni utenti hanno aggiornato il proprio sistema operativo, tuttavia, si sono ritrovati con un terribile BSOD.

La reazione di questi utenti sarà stata chiaramente quella di insultare pesantemente la società di Redmond. Tuttavia, questa volta, il problema non è stato causato da Microsoft. In realtà, molti utenti che hanno riscontrato questo problema erano affetti dal rootkit TDL3.

Più esattamente sembra che il rootkit TDL3 sia incompatible con l’update MS10-015. Questa è la causa del BSOD. Il problema risiede nella pigrizia degli autori del rootkit quando hanno progettato la routine di infezione del driver.

Quando il dropper viene eseguito, l’infezione calcola gli offset RVA di alcune funzioni del kernel di Windows – ZwReadFile, ZwOpenFile, ObQueryNameString - e scrive ingloba questi offset nel codice dell’infezione, senza verificarli ad ogni avvio del sistema.

Questo ha funzionato perfettamente fino all’update MS10-015, con cui Microsoft ha aggiornato il kernel di Windows. Con questo aggiornamento sono stati effettuati alcuni cambi che hanno modificato gli offset delle funzioni in questione. Finita la procedura di aggiornamento, viene richiesto il riavvio del sistema. Al riavvio, il codice del rootkit tenta di invocare un indirizzo non valido e il sistema genera un BSOD.

La buona notizia è che i creatori del rootkit hanno cura di tutti noi ed hanno rilasciato in poche ore una nuova versione aggiornata del rootkit compatibile con la nuova patch della Microsoft.

Purtroppo il numero di utenti affetti da questo problema è rilevante. Ciò significa che l’infezione causata da questo rootkit si sta diffondendo velocemente.

Inoltre, una variante di questo rootkit si sta diffondendo in maniera parallela alla versione ufficiale. Questa variante utilizza una tecnologia già utilizzata nelle prime varianti del TDL3 rootkit. La dll iniettata non è più denominata tdlcmd.dll bensì z00clicker.dll.

Le forze di polizia internazionali dovrebbero prendere in seria considerazione l’idea di collaborare con le società di sicurezza per tentare di bloccare questa botnet. Il team alle sue spalle è attivo, sono in grado di rilasciare aggiornamenti ogni giorno, sono già una seria minaccia che deve essere bloccata il prima possibile.

Prevx Blog

Alcuni anni fa scoppiò il caso Aruba e Hosting Solutions, due tra i maggiori hosting provider italiani, che si videro compromettere centinaia di siti web ospitati nei loro server. “Una particolare tecnica di phishing, ben congeniata, che era riuscita ad ingannare gli utenti e a convincerli a comunicare le password di accesso ai propri siti web“. Questa fu, secondo una delle due società, la causa principale della compromissione dei siti web ospitati. Nessuna falla del sistema.

Che il phishing sia una delle più gravi piaghe degli ultimi anni è risaputo, ma che a cadere vittima di una tecnica di phishing sia uno dei maggiori siti italiani dedicato alla lotta contro il phishing, questo sembra fuori da ogni possibile logica. E, d’altronde, a distanza di anni, potrebbe riaprire la diatriba portata avanti per settimane “fu colpa degli hosting provider e di una falla di sistema o fu veramente colpa degli utenti e di qualche sofisticata tecnica di phishing?“.

In queste ore il sito web anti-phishing.it, una delle maggiori risorse italiane nella lotta contro il phishing, è stato compromesso e nella home page è stato inserito un javaScript offuscato che reindirizza ad alcune pagine web contenenti exploit. Il server contenente gli exploit è individuabile all’indirizzo 70.38.31.90. Il sito è ospitato in uno dei server Aruba dedicati allo shared hosting.

Le pagine web malevole si occupano, attraverso exploit vari, di scaricare automaticamente nel PC vittima un trojan che installa il famigerato MBR rootkit.

Il fatto in sé farebbe rivalutare la causa “phishing“, vista la vittima illustre. Ad un’analisi più dettagliata risultano piu di una cinquantina i siti web compromessi con lo stesso javaScript offuscato, per ora tutti ospitati su Aruba.

Tra le vittime illustri anche il sito web personale del deputato dell’Italia dei Valori Franco Barbato, il sito non ufficiale italiano dedicato a Twitter, il sito ufficiale del gruppo musicale Zero Assoluto, il sito della rete sismica sperimentale italiana I.E.S.N . L’analisi di molti siti web è ancora in corso tuttavia, non è possibile escludere a priori ulteriori siti web famosi compromessi.

Il dropper scaricato nel PC della vittima attraverso gli exploit è al momento individuato, stando ad una scansione su VirusTotal, da soli 10 antivirus su 41 testati. Una volta eseguito, si connette all’indirizzo IP 72.51.41.83 da dove scarica la seconda parte dell’infezione, che si occuperà di installare il rootkit vero e proprio.

Il fatto che i siti web compromessi siano ospitati su diversi server Aruba e non centralizzati tutti su uno stesso indirizzo IP lascerebbe pensare che non si tratti di una falla nei server di Aruba, ma più di un attacco mirato verso specifici obiettivi. Tuttavia, la presenza di un sito web quale anti-phishing.it tra le vittime dell’attacco porterebbe idealmente ad escludere l’ipotesi di un attacco tramite phishing e di un infezione nel sistema dei gestori del sito web.

Rimarrebbe l’ipotesi di una compromissione lato server, che potrebbe combaciare anche se i siti web sono sparsi tra vari indirizzi IP. I pirati informatici potrebbero voler non dare troppo nell’occhio ed evitare di far vedere di avere libero accesso ai server. Facendo così, colpendo pochi siti web e sparsi tra i vari server, apparirebbe come una lacuna lato client, colpa di qualche webmaster distratto e di qualche e-mail di phishing ben costruita. Purtroppo, però, la verità – qualunque essa sia – difficilmente verrà mai a galla.

Al momento gli utenti Prevx sono completamente protetti da questo attacco. Chi pensa possa essere rimasto infetto, può effettuare una scansione gratuita con Prevx. In caso di infezione presente, verrà identificata come Rootkit.MBR.

UPDATE 23/01/2010 ore 10.20

Questa è una lista parziale dei siti web ospitati sui server Aruba rimasti colpiti dal javaScript offuscato:

Alcuni di questi, tra cui anti-phishing.it, hanno già bonificato la pagina web e rimosso il codice nocivo.

Prevx SafeOnline: licenza omaggio per chi diventa fan della pagina facebook di Prevx SafeOnline

Il TDL rootkit – in veste di terza edizione – è ad oggi il rootkit kernel mode più avanzato mai visto in circolazione, capace di nascondersi nel sistema così bene da impedire ad ogni software di sicurezza l’individuazione e la rimozione dell’infezione. In pochi ne parlano, perché non esiste una soluzione definitiva al momento.

L’infezione è aggravata dal fatto che il team alle spalle del rootkit TDL è costantemente attento alle tecniche di difesa messe in atto dai software antivirus e risponde giornalmente – in alcuni casi anche con piu aggiornamenti al giorno – con contro misure capaci di annullare ogni timida controffensiva.

Il rootkit si diffonde attraverso siti di crack o attraverso le reti peer to peer. Gli aggiornamenti giornalieri fanno sì che il dropper del rootkit sia in grado di evadere agevolmente le signature dei software antivirus.

Una volta eseguito – il dropper necessita dei privilegi di amministratore per poter installare il rootkit – tenta di evadere il controllo di alcuni basilari software HIPS e carica in memoria il driver del rootkit. Da questo momento in poi, il rootkit diventa letteralmente invisibile. Se l’UAC è disabilitato – o si danno i diritti di amministratore manualmente – il rootkit è in grado di infettare anche Windows Vista e Windows 7.

I file che compongono l’infezione – il driver, due librerie dll e file di configurazione – vengono scritti negli ultimi settori del disco rigido, fuori dal file system del sistema. Seppure i file, in questa maniera, siano già invisibili a qualsiasi software antivirus, il rootkit applica un’altra tecnica particolarmente interessante ed avanzata: il rootkit utilizza un file system proprietario e crittografato, con una propria MFT e sistemazione dei file al suo interno. La conseguenza è che leggendo gli ultimi settori del disco rigido ci si trova davanti solo dei byte casuali apparentemente senza senso, perché crittografati.

L’accesso in lettura e scrittura al contenuto crittografato è gestito in tempo reale dal rootkit, che codifica e decodifica on-the-fly i file quando sono richiesti.

Da notare che una tecnica simile, ma più semplice, era stata già vista nel MBR rootkit, il quale scrive il proprio driver negli ultimi settori del disco rigido.

Una volta depositati i file necessari, il rootkit infetta uno dei driver di sistema che gestiscono l’hard disk I/O, filtrando in maniera efficace i pacchetti in transito.

L’infezione è particolare, diversa sia da Rustock.C che Neprodoor. Da questi ultimi due rootkit eredita l’idea di infettare un driver di sistema(ad es. atapi.sys), evitando così di dover nascondere una eventuale nuova chiave di registro di sistema che verrebbe comunque identificata per mezzo di analisi approfondite.

La tecnica però è migliorata: Rustock.C infettava il driver aggiungendo del codice virale in fondo al codice del driver. Infezione individuabile grazie ad una scansione incrociata per verificare eventuali incongruenze sulle dimensioni del file. Neprodoor cripta direttamente tutto il codice del driver e inserisce un proprio loader che si occupa di decodificare il driver del rootkit e il driver originale in memoria. Anche questa tecnica è identificabile per mezzo di una scansione incrociata alla ricerca di incongruenze di dimensioni del file e, in aggiunta, anche una semplicissima analisi incrociata di una piccola porzione del file mostrerebbe delle evidenti incongruenze.

TDL rootkit eredita questa tecnica e la migliora: il malware infetta il driver modificando solo 824 bytes all’interno della sezione del file dedicata alle risorse e reindirizza l’entry point del file in modo che venga eseguito questo loader di pochi bytes. Il loader provvederà poi a caricare il vero driver criptato nei gli ultimi settori del disco rigido e, successivamente, passerà il controllo al driver infettato. Il driver originale non viene alterato in termini di dimensioni e, per scoprire l’infezione, è necessaria un’analisi completa del file. Solo un confronto per mezzo di un hash del file intero mostrerebbe l’incongruenza.

Cosa particolarmente complessa però visto che il rootkit, una volta attivo nel sistema, applica dei filtri a livello di I/O che impediscono a qualsiasi software antivirus di leggere il vero contenuto del disco, nascondendo così il driver infetto e gli ultimi settori del disco. L’utente non vede niente di anormale, il driver infetto viene visto dal sistema come originale, senza alcuna alterazione.

I filtri applicati dal rootkit sono così efficaci che al momento sono state trovate veramente poche soluzioni pubbliche efficaci per aggirare il problema. Inoltre, ogni tentativo rilasciato pubblicamente viene reso inoffensivo nel giro di poche ore, o giorni, dal team alle spalle del rootkit che aggiorna la propria creatura.

La parte del rootkit in kernel mode inietta poi all’interno dei processi – in particolar modo nei processi relativi ai browser – le proprie librerie dll che si occupano di portare avanti il payload dell’infezione.

Il computer, una volta infettato, diventa fondamentalmente uno zombie, capace di ricevere comandi da parte di uno o piu C&C. Tdlcmd.dll e tdlwsp.dll sono le componenti dell’infezione, anch’esse depositate all’interno del file system crittografato creato dal rootkit. Al momento il rootkit è in grado di reindirizzare la navigazione degli utenti e di simulare click – probabilmente per guadagni derivanti dall’online advertising. Ciò non toglie che il rootkit potrebbe essere istruito per fare qualsiasi cosa. Tutte le comunicazioni con i server C&C sono crittografate per mezzo di SSL, rendendo difficile l’analisi del contenuto della connessione.

Come già detto all’inizio dell’articolo, TDL è un’infezione attiva, totalmente invisibile e si sta diffondendo in maniera capillare. L’unica cosa anormale che gli utenti possono riscontrare è la redirezione casuale durante la navigazione web e, in alcuni casi, l’allarme dei software di sicurezza riguardo le due dll riconosciute come infette. Tuttavia, anche riscontrando la presenza dei due file, i software di sicurezza non potrebbero fare niente perché non sanno dove essi siano effettivamente situati, visto che il file system è crittografato.

Il fatto che se ne parli poco, al momento, è solo dovuto al fatto che molte società di sicurezza non hanno le idee chiare su come affrontare la situazione. Il problema è non solo reale, ma effettivamente diffuso.

Riporto qui gli indirizzi IP e i domini al momento utilizzati dal rootkit per comunicare con i C&C:

d45648675.cn d92378523.cn a57990057.cn a58990058.cn c36996639.cn c58446658.cn m2121212.cn a23423424.cn a76956922.cn mfdclk001.org 91.212.226.60

91.212.226.61 212.117.174.176 212.117.174.177 212.117.174.176 188.40.164.210 188.40.164.211 78.47.248.115 188.40.85.251 94.228.209.143 94.228.209.144 188.40.101.169

Gli amministratori di rete potrebbero applicare momentaneamente filtri per bloccare le comunicazioni ed arginare in parte l’infezione. Da notare come alcuni indirizzi IP utilizzati dal rootkit siano situati in Europa, dove teoricamente dovrebbe essere piu facile intervenire a livello di legge. In pratica ciò non è così, visto che alcuni di questi indirizzi sono attivi gia da due mesi, liberi di agire.

I clienti Prevx, se dovessero riscontrare reindirizzamenti durante la navigazione web oppure connessioni ad uno dei domini o indirizzi IP sopra riportati, possono contattare l’assistenza Prevx. I nostri tecnici sono in grado di analizzare il sistema da remoto e rimuovere manualmente l’infezione.

D’altronde l’utilizzo di Internet per i servizi di pagamento online, di gestione dei propri conti correnti o della propria carta di credito è diventato all’ordine del giorno. Pagamenti delle utenze sul sito delle poste italiane o per mezzo del proprio conto corrente gestito totalmente online sono solo alcuni esempi di come sul web passino ogni ora migliaia e migliaia di dati personali pronti per essere catturati dai pirati informatici.

Il phishing è solo uno dei possibili esempi di un attacco studiato per rubare informazioni e dati personali agli utenti ignari: una falsa pagina web che simula in maniera perfetta la pagina web originale del sito di una banca o di un servizio online di transazioni e l’utente si fida ciecamente, tanto da inserire i propri dati, i quali verranno debitamente utilizzati per scopi tutt’altro che onesti.

Come fare dunque per verificare che la pagina web che si sta andando a visitare sia effettivamente quella che si pensa di star visitando e non una copia costruita ad arte per carpire le informazioni? Il suggerimento che si dà sempre ai meno esperti è di controllare che compaia il famoso lucchetto sulla barra degli indirizzi, indice di pagina protetta e certificata.

In effetti la comparsa del prefisso https:// e del lucchetto indicano che su quella pagina è attivo un protocollo di crittografia che permette di inserire i propri dati personali senza preoccuparsi che chi sta nel mezzo possa riuscire a leggere le informazioni, poiché viaggiano all’interno di un canale crittografato. Per utilizzare questo tipo di crittografia c’è bisogno di almeno un certificato SSL. Inoltre, il certificato garantisce – o dovrebbe garantire – che il sito web è affidabile e verificato, non è quindi una pagina web contraffatta.

Questo certificato può essere acquistato oppure generato semplicemente da chiunque. Avendo il duplice scopo di certificare l’attendibilità di un sito web e di attivare la crittografia tra client e server, bisogna guardare a cosa il gestore del server ha bisogno.

Se la necessità è solo quella di crittografare i dati in traffico da e verso il proprio sito web, è possibile generare da sé dei propri certificati. Funzioneranno tranquillamente, ma non saranno certificati attendibili, perché nessuno conosce la fonte di provenienza del certificato. Di conseguenza, andando su un sito web che ha un certificato SSL creato ad hoc dal gestore del server, qualsiasi browser che includa un controllo dei certificati SSL (e tutti i browser attuali lo fanno) mostrerà un errore di certificato non attendibile, perché la fonte del certificato è sconosciuta dalla lista di fonti attendibili che i browser e i sistemi operativi includono.

Viceversa, se la necessità è anche quella di garantire l’attendibilità di un sito web oltre che quella di crittografare i dati, allora è necessario acquistare un certificato SSL da un rivenditore (un certificate provider) conosciuto ed affidabile. L’acquisto, spesso oneroso, di un certificato da uno di questi provider implica che il provider verifichi l’identità del gestore del sito web, attraverso numerosi controlli. Solo dopo aver effettuato questi controlli, il provider rilascerà un certificato SSL che può così garantire sia la crittografia dei dati che l’attendibilità della pagina web. Un browser che arriverà alla pagina web che contiene il certificato SSL firmato da una società attendibile non mostrerà alcun avviso, ma semplicemente l’immagine di un lucchetto e il classico prefisso https://.

Questo breve excursus è servito per spiegare cosa avviene, in parole povere, quando si acquista un certificato SSL e perché, solitamente, la presenza di un certificato SSL dovrebbe garantire non solo che il traffico web è crittografato, ma che la pagina stessa e l’identità del gestore sono state verificate.

La logica conseguenza di tutto ciò nel pensiero comune è: basta verificare che il browser non dia alcun tipo di messaggio e che sia presente il prefisso https:// e l’immagine del lucchetto per essere sicuri che la pagina web sia sicura ed attendibile.

In effetti non è proprio così. Per motivi di necessità differenti, con il tempo i certificate provider hanno deciso di spaziare e di variare le proprie offerte in base alle richieste delle utenze. Acquistare un certificato SSL ha da sempre avuto un costo proibitivo, qualcosa che solo chi aveva veramente necessità di attestare la propria identità sul web poteva acquistare – banche, grandi istituzioni e simili.

Ci sono però anche siti web che vorrebbero poter utilizzare un certificato SSL semplicemente per garantire la crittografia dei dati durante il tragitto client-server, senza però doversene generare uno proprio senza una firma attendibile perché ciò metterebbe in dubbio l’onestà del sito web agli occhi degli utenti.

Per questo motivo con il tempo sono nati i certificati SSL DV (DV SSL certificates), cioè Domain Validated. Cosa significa? Che ad un prezzo modico – anche gratuito, alcune società lo fanno – i certificate provider rilasciano un certificato SSL valido e firmato da loro – quindi attendibile agli occhi di un browser – previa esclusiva verifica della proprietà del dominio sul quale il certificato verrà installato.

In parole povere: il certificate provider manda una e-mail con un codice di conferma all’indirizzo web dell’amministratore del dominio per il quale si va a richiedere il certificato SSL. Il codice dovrà poi essere inserito come verifica che l’utente ha la proprietà del dominio. Effettuato questo semplice controllo, l’utente avrà un certificato SSL valido e funzionante. Non più dunque una verifica dell’identità del richiedente del certificato, ma una semplice verifica della proprietà del dominio web. Rimangono ovviamente disponibili i servizi forniti dai certificate provider di richiedere un certificato SSL valido e verificato, che possa garantire l’identità del gestore del sito web.

Un servizio utile insomma, ma che apre un mare di possibilità anche ai malware e al phishing. Chi crea pagine di phishing non può permettersi un certificato SSL valido e verificato, perché dovrebbe mandare via fax per la verifica della documentazione che non ha. Ma ora può permettersi tranquillamente, ad un prezzo nullo o di poche decine di euro, un DV SSL certificate che garantisce che il gestore del sito web è veramente il gestore del sito web, ma non garantisce chi è il gestore del sito web. E per la registrazione di uno spazio web basta una semplice identità falsa, rubata magari precedentemente a qualcuno sul web.

Agli occhi degli utenti ignari cosa significa tutto ciò? Basti vedere gli ultimi casi di phishing a causa delle Poste italiane: un sito web costruito ad hoc, perfetta replica del sito originale, con l’aggiunta di un certificato SSL valido, senza che il browser avverta di niente – d’altronde il certificato è stato firmato da un provider attendibile. Per un browser al momento non cambia se il certificato è stato rilasciato previa verifica dell’identità o solo del dominio. Al browser basta che il certificato sia stato firmato da una fonte attendibile. Per il programma è valido ed affidabile. E di conseguenza lo diventa anche per l’utente meno esperto, che si trova un sito web perfettamente identico all’originale, un lucchetto ed il prefisso https://, come gli è stato insegnato dovrebbero essere i siti web affidabili.

La patata bollente passa in mano dei soli filtri anti-phishing, che rimangono l’unico avviso disponibile per l’utente medio, il quale in teoria dovrebbe verificare sempre che l’indirizzo web digitato sia quello corretto, ma che in pratica non fa mai.

N.B. Tra i livelli di sicurezza possibili di un certificato SSL, il più alto è L‘Extended Validation SSL (EV SSL certificate), che garantisce il massimo dei controlli e la sicurezza che il gestore del sito web è totalmente affidabile. Le ultime versioni dei browser (es. Mozilla Firefox 3.5, Internet Explorer 8, Safari 4, Opera 10, Google Chrome) riconoscono questi certificati e, oltre a mostrare il lucchetto e ovviamente utilizzare il prefisso https://, colorano la barra dell’indirizzo web di verde (oppure solo una parte di essa, ad esempio in Firefox la parte a sinistra del prefisso). Questo è il massimo grado di sicurezza ed affidabilità dei certificati SSL. Esistono comunque diversi livelli di affidabilità inferiori all’EV SSL – che è chiaramente il più oneroso – e questi non mostrano alcuna barra di colore verde, ma semplicemente il solito lucchetto e il prefisso https://. Tuttavia anche questi tipi di certificati, prima di essere rilasciati, verificano l’identità del richiedente. Gran parte dei siti web e banche utilizzano questo tipo di certificati, che purtroppo all’occhio dell’utente si confondono con i Domain Validated SSL, che non verificano l’identità del richiedente ma solo il fatto che sia proprietario del dominio per cui si va a chiedere il certificato.

Il nuovo Prevx, rilasciato nella versione 3.0.5.6, contiene quasi 1000 cambi effettuati dalla ormai vetusta versione 3.0.1.65, dalla completa compatibilità con Windows 7 alla riscrittura dell’engine di protezione del programma, all’ottimizzazione dell’engine di scansione.

Ma, il punto focale della nuova versione di Prevx è l’implementazione della nuova componente Prevx SafeOnline, un notevole passo avanti per la sicurezza delle transazioni online effettuate dagli utenti su Internet.

Prevx SafeOnline è la nuova funzionalità di Prevx che promette agli utenti di navigare sui siti web, inserire dati sensibili ed essere sicuri che nessun malware potrà intercettare queste informazioni personali.

L’utilizzo sempre più frequente di servizi di e-banking, di pagamento online, di e-shop, prevede che l’utente debba sentirsi sicuro nel momento in cui inserisce le proprie informazioni personali e dati sensibili quali dati di accesso ai conti correnti online o numeri di carte di credito.

I siti web in questione – siti di banche, paypal, ebay e molti altri – mettono al sicuro l’utente grazie all’utilizzo di connessioni HTTPS, l’utilizzo del protocollo crittografico SSL per garantire che la trasmissione di dati dal pc dell’utente al server remoto dell’azienda sia crittografata e impossibile da intercettare per qualsiasi pirata informatico che si trovasse tra il server e il PC dell’utente.

Ciò non esclude però che il PC dell’utente possa essere infetto da un qualsiasi malware. Nel 98% dei casi, infatti, è un malware all’interno del PC dell’ignara vittima a catturare le informazioni nel momento in cui vengono digitate dall’utente nel sito web a cui si vuole accedere.

Esempi possono essere il famigerato MBR rootkit, ma anche trojan quali ZeuS, SilentBanker, Goldun e migliaia di altri trojan con funzioni di keylogging o screengrabbing. Trojan silenziosi, inseriti all’interno del PC che intercettano la connessione a determinati siti web e catturano i dati di accesso dell’utente per poi spedirli ad un server remoto. I dati, in mano ai pirati informatici, potranno essere utilizzati in svariati modi, oppure anche venduti al miglior offerente.

L’utente, per evitare ciò, effettua una scansione con un software antivirus il quale, non trovando infezioni, convince l’ignaro user che può inserire i propri dati senza essere spiato.

In realtà, tuttavia, più e più volte singoli software antivirus si sono lasciati sfuggire infezioni attive nel sistema. Di fatto nessun software di sicurezza può garantire di individuare il 100% dei software nocivi.

Prevx, con il tempo, ha dimostrato che molti PC degli utenti – dichiarati puliti da altri software antivirus – erano in realtà ancora infetti da dei malware.

Anche noi alla Prevx però sappiamo che Prevx non è in grado di individuare il 100% dei software nocivi, perché nessun software sarebbe in grado di fare una cosa del genere. Per questo abbiamo sviluppato Prevx per essere totalmente compatibile con gli altri software di sicurezza e al contempo leggero sul sistema, per permettere all’utenza di installare Prevx in combinazione con un altro antivirus e fornire così maggiori possibilità di individuazione di infezioni.

Il punto, però, è che anche combinando piu prodotti di sicurezza, qualche infezione potrebbe sfuggire. È fisiologico, è impossibile da evitare. Ma bisogna porre rimedio in qualche modo. Da questo concetto nasce Prevx SafeOnline.

Prevx SafeOnline si integra in maniera totalmente automatica con tutti i browser più comunemente utilizzati ed inizia a proteggere la navigazione online dell’utente. Nel momento in cui si accede ad un sito web protetto – la lista dei siti web che si vuole proteggere è scelta arbitrariamente dagli utenti – Prevx SafeOnline inibisce il funzionamento di qualsiasi trojan con funzioni di keylogging, o trojan capaci di intercettare i dati nella clipboard o effettuando delle immagini istantanee del desktop.

Il concetto di Prevx SafeOnline è, in definitiva, quello di proteggere i dati degli utenti, indipendentemente dal fatto che il PC sia infetto o meno. Anche se il PC è infetto, i malware non saranno in grado di intercettare i dati digitati dall’utente.

Non è tutto quì. Prevx SafeOnline integra una protezione anti-phishing e una protezione anti-dns poisoning, grazie alla quale viene effettuato un controllo incrociato del sito web che l’utente va a visitare per verificare che la navigazione non sia stata reindirizzata da qualche infezione verso un falso sito web.

Test indipendenti hanno valutato la bontà del prodotto, verificando e confermando l’effettiva capacità di Prevx SafeOnline di bloccare i malware attualmente in circolazione capaci di rubare le informazioni degli utenti.

La compatibilità del prodotto è ancora limitata ai sistemi a 32 bit, ma a breve verrà espansa anche ai sistemi a 64 bit.

Maggiori informazioni alla pagina web http://www.prevx.com/safeonline.asp

Erano molte le attese rivolte a questo nuovo sistema operativo di casa Cupertino, soprattutto per quanto riguardava la sicurezza.

Come avevo già scritto in passato, in effetti, il sistema operativo della mela non era così inviolabile e al sicuro da exploit e malware come spesso veniva definito. La realtà era che Leopard era tanto vulnerabile agli attacchi quanto lo è Windows, almeno dal punto di vista tecnico.

Negli ultimi anni si è visto un aumento di sviluppo di software nocivi per OS X, sebbene sia stato sempre negato il rischio di infezioni in questo sistema operativo.

Nelle ultime conferenze relative alla sicurezza informatica si è visto sempre più come Leopard fosse molto piu facilmente vulnerabile di Windows ad exploit. Un esempio tra tanti è lo scorso Pwn2Own 2009, una gara tenutasi a Marzo durante il CansecWest, dove Safari su OS X è stato il primo browser sotto attacco a capitolare in una manciata di secondi. Giusto per curiosità: al prossimo SMAU sarà presente un convegno/workshop dove si parlerà di exploit e, proprio in tale occasione, sarà trattato l’exploiting del sistema operativo Mac OS X.

Insomma,un quadro abbastanza diverso da quello che si descrive solitamente quando si parla di Mac OS X come sistema assolutamente sicuro in confronto a Windows. Tutte “falle” che sarebbero dovute essere state sistemate con Snow Leopard.

Ma, a pochi giorni dal rilascio del nuovo sistema operativo di Apple, si sono viste novità che, invece, hanno messo in risalto come la stessa società di Cupertino stia correndo ai ripari preoccupata dall’avanzata degli attacchi nei confronti del proprio “pargolo”. Come era, d’altronde, chiaramente prevedibile una volta che OS X fosse uscito dalla propria nicchia di utilizzatori.

Parlando di attacchi che prevedono la corruzione di memoria, Snow Leopard implementa un DEP di gran lunga migliorato rispetto all’implementazione precedentemente presente in Leopard, ma lascia un ASLR ancora acerbo, fratello gemello dell’implementazione presente in Leopard.

Avere un’impementazione del DEP efficace ma un ASLR parziale significa avere comunque dei grossi problemi di sicurezza, come era già stato scritto nel precedente articolo su OS X 10.5 e, prima ancora, in un altro articolo più generico sull’argomento.

Ma, una delle varie sorprese, è stata trovare in Snow Leopard una funzionalità anti-malware integrata, una sorta di vero e proprio scanner antivirus che, grazie ad un database di firme virali, analizza i file che vengono scaricati nel sistema operativo e blocca eventuali infezioni.

Possiamo rigirare le parole come vogliamo, possiamo chiamarla in tanti modi visto che appena si parla di antivirus su OS X inizia una guerra interplanetaria. Una nuova caratteristica del sistema operativo, una funzionalità di sicurezza, una protezione aggiuntiva al sistema operativo. Questo è, de facto, uno scanner anti-malware, con tanto di database di firme virali aggiornabile.

In realtà il database contiene solo due firme virali, per due specifiche infezioni – e, come è stato testato da alcune società di sicurezza, sono firme virali che non bloccano tutte le varianti di quelle specifiche infezioni. Inoltre, questo scanner anti-malware funziona esclusivamente quando specifiche applicazioni scaricano dei file. Non sono analizzati né Finder – quindi file copiati da LAN o dispositivi removibili non sono controllait – né programmi di messaggistica istantanea, client e-mail. Gli assenti illustri sono tanti, assenti che possono aprire la porta a quelle stesse infezioni per le quali la protezione anti-malware di Apple è stata progettata.

Comunque sia, sorvolando sulla parte tecnica, è interessante riflettere su alcuni punti: Apple ha fatto della sicurezza del proprio sistema operativo il cavallo di battaglia, in confronto al “colabrodo” Windows.

Tuttavia, come Apple stessa ha dimostrato con l’implementazione di questa nuova funzionalità, teme il problema dei nuovi malware che sempre più ultimamente stanno attaccando anche OS X. Una paura che, ora, non è più nascosta.

Se non fosse un problema ben sentito a Cupertino, non avrebbe avuto senso aggiungere uno scanner anti-malware, con uno specifico database di firme virali.

Inoltre, come vari ricercatori sparsi nel mondo stanno mostrando, OS X è tanto vulnerabile ad exploit quanto lo è Windows. Anzi, a detta di molti addetti al settore, Windows è molto più sicuro di OS X sotto questo aspetto.

Con questo non si vuol dire chiaramente che OS X sia un sistema operativo scadente, anzi, tutt’altro. Con Snow Leopard Apple ha fatto un grande passo avanti. Così come Microsoft sta effettuando la propria “rivoluzione” con Windows 7.

Le discussioni tra utenti di Windows e utenti di Mac OS X ci saranno sempre, le famigerate “guerre di religione”. Però, a questo punto, uno degli argomenti tanto usati durante queste discussioni, il tema sicurezza, non dovrebbe più essere sfruttato come il cavallo di battaglia.

Chiunque nel mondo della sicurezza informatica ha potuto assistere a ciò che è successo nel corso degli ultimi anni: un aumento del numero di malware in circolazione ma una drastica diminuzione della complessità del codice. La maggior parte dei malware non hanno molto di interessante da analizzare, spesso sono varianti o versioni ricompresse o criptate di varianti già conosciute. Qesto non significa comunque che non vengano rilasciate infezioni complesse, ma semplicemente che sono più rare di prima.

Chi ha provato a pulire un PC altamente infetto potrà facilmente ammettere che spesso è più facile e veloce reinstallare tutto piuttosto che tentare di rimuovere le infezioni attive. Proprio qui entrano in gioco una nuova tipologia di software.Sempre più utenti stanno cominciando ad utilizzare software di sicurezza che sono in grado di effettuare una “foto istantanea” del sistema e di redirigere successivamente tutto ciò che avviene – modifiche ai file o alle configurazioni di sistema – in una sorta di contenitore temporaneo. Poi, al riavvio del sistema, tutte le modifiche vengono eliminate così da lasciare il sistema intatto così come era stato trovato prima di aver effettuato tutte le varie modifiche.

Questra è una soluzione fantastica per chiunque voglia lasciare uno o più PC a disposizione di un pubblico con la sicurezza che il sistema non venga alterato. La stessa soluzione è utilizzata da chi vuole poter testare software senza installarli definitivamente nel sistema.

È in fondo un gioco semplice, dove bisogna seguire solo alcuni semplici passi: salvare lo stato del sistema, fare qualsiasi cosa si voglia, riavviare il sistema e ogni modifica effettuata verrà cancellata.

Deve essere stato un incubo per alcuni clienti l’aver scoperto che, pur dopo vari riavvii del sistema, un software nocivo rimaneva sempre lì. Più che altro perché chi utilizza questi software è convinto che qualsiasi modifica venga filtrata ed eliminata al riavvio, di conseguenza non pensa di dover utilizzare altri software di sicurezza per prevenire eventuali infezioni. Sanno già che, anche se un malware infetta il PC, sarà cancellato al successivo riavvio.

Ci sono state molte chiacchiere online riguardo un nuovo malware capace di superare i filtri di questi software di sicurezza, così da scrivere direttamente sul disco e sopravvivare ad un riavvio di sistema. Ma è vero o falso? Purtroppo è vero, ma era qualcosa che doveva succedere prima o poi. Il problema è più che altro di design e di come questi software siano implementati.

Quando un software prova a leggere o scrivere un file sul disco, la richiesta passa attraverso una catena di driver che la gestisce. Ogni volta che un driver finisce il proprio lavoro, invia la richiesta al successivo driver e così via fino a quando la richiesta è soddisfatta e il software riceve le informazioni che aveva richiesto.

La richiesta è gestita inizialmente da un file system driver, che la invia poi al famoso driver disk.sys. Quest’ultimo altro non è che un’interfacci utilizzata dal sistema per comunicare con gli hard disk fisici. Quì è dove questi software di sicurezza solitamente lavorano, filtrando ogni tentativo di scrittura su disco e ridirigendolo verso un deposito temporaneo. È una soluzione sicuramente efficace.

Tuttavia ora nascono due problemi. Il primo è che gli utenti credono di poter fare qualsiasi cosa quando sono protetti da questi software poiché tanto al successivo riavvio il sistema viene ripulito automaticamente. Il successivo passaggio è dunque che qualsiasi cosa viene eseguita con privilegi di amministratore. A chi interessa se un kernel mode rootkit si installa nel PC? Tanto qualsiasi modifica viene cancellata al riavvio. Sbagliato.

Ci si muove in un campo minato. Anche se protetti da questi software di sicurezza, se viene eseguito un software con privilegi di amministratore si dà automaticamente accesso alla zona del kernel di Windows. Una volta entrati lì, un eventuale malware e il software di sicurezza giocano allo stesso gioco, con le stesse regole.

Disk.sys non è l’ultimo driver invocato da una richiesta di lettura/scrittura su disco. Una volta terminato il proprio lavoro, la catena continua fino ad arrivare al driver atapi.sys, che è il reale responsabile della comunicazione tra il sistema e gli hard disk.

Si può dunque provare ad immaginare cosa succederebbe se un malware fosse in grado di comunicare direttamente al driver atapi.sys, senza passare per la solita catena dei driver.

Questo è quello che il malware, conosciuto come SafeSys, sta facendo. È, cioè, in grado di sovrascrivere un file di sistema così da poter essere eseguito al successivo riavvio, anche se teoricamente dovrebbe venire eliminato.

Non scenderò ulteriormente nei dettagli sul funzionamento del malware, quello che ho scritto dovrebbe essere sufficiente per far capire alle persone che affidarsi ad un solo software di sicurezza non aiuta a prevenire le infezioni.

Prevx blog

Sfortunatamente sono passati due mesi e solamente un numero molto ristretto di produttori di software di sicurezza e ricercatori indipendenti hanno implementato uno scanner per il nuovo MBR rootkit. Ciò non è bene, soprattutto se stiamo parlando della stessa minaccia che ha infettato decine di migliaia di PC in tutto il mondo l’anno scorso, rubando password, dati sensibili quali account bancari e dati personali.

In effetti, come avevo scritto in un post precedente, la prima versione del MBR rootkit potrebbe essere utilizzata ancora con successo. Il problema per gli attacker è fondamentalmente il dropper, per via delle individuazioni da parte dei software antivirus. Tuttavia i dropper del MBR rootkit sono stati spesso in grado di evadere le scansioni degli antivirus basate sia su signature che su tecnologie euristiche – i creatori sanno bene come svolgere il proprio sporco lavoro.

Una volta che il dropper ha infettato il sistema, a quel punto solo un numero esiguo di software antirootkit sono in grado di intercettarlo.

Tuttavia, i creatori del MBR rootkit hanno comunque deciso di effettuare un altro passo verso l’invisibilità “completa” e hanno rilasciato due mesi fa quello che può essere definito come il peggior rootkit in-the-wild attualmente conosciuto. Praticamente tutti i software antirootkit sono stati superati.

A due mesi di distanza abbiamo isolato un’altra variante del MBR rootkit. Seppur esiguo, evidentemente il numero di software antirootkit che erano stati aggiornati per individuare la nuova versione dell’infezione era troppo alto per i creatori, che hanno dunque deciso di spazzare via ogni possibilità di poter vedere il rootkit all’interno del sistema.

Alcuni test interni sulla variante del MBR rootkit che avevamo isolato due mesi fa hanno messo in evidenza come solo cinque software antirootkit erano in grado di individuare questa infezione – incluso Prevx 3.0 che è stato il primo.

Ora, dopo questo nuovo update del malware, Prevx è rimasto l’unico software in grado di individuare e rimuovere l’infezione.

Questo nuovo aggiornamento del MBR rootkit include hook molto più efficaci, capaci di filtrare ancor più in profondità ogni tentativo di leggere il Master Boot Record da parte dei software di sicurezza.

La buona notizia è che sono state rimosse da questa variante del rootkit alcune routine utilizzate per nascondere gli hook. Tuttavia questa potrebbe essere solo una scelta temporanea, visto l’enorme successo delle tecniche DKOH utilizzate per nascondere ancor più in profondità l’infezione.

L’idea di manipolare il driver al quale il device \Device\Harddisk0\DR0 è collegato è ancora un’idea vincente, vista la difficoltà nel bypassare questo attacco.

Anche pensando di rimuovere l’hook del rootkit, sarebbe comunque difficile ripristinare la funzione di sistema originale, perché non si avrà a che fare sempre con lo stesso driver manipolato. In qualche sistema il driver potrebbe essere ACPI.sys, in altri vmscsi.sys, in altri ancora direttamente atapi.sys o molti altri. Quindi un eventuale routine di rimozione dell’hook dovrebbe innanzitutto individuare qual è il driver modificato e, in funzione del driver, conoscere già quale sia la funzione originale che è stata rimpiazzata. Un lavoro non banale.

Non l’avevo scritto nel primo post riguardante il MBR rootkit ma probabilmente quest’idea di prendere sotto attacco il driver immediatamente successivo al disk.sys è stata presa in prestito da un altro proof-of-concept bootkit, mostrato all’ultima XCon conference e denominato Tophet.A.

Come era possibile prevedere, abbiamo iniziato a vedere una rapida diffusione di queste nuove versioni del MBR rootkit, spesso iniettate nei sistemi degli utenti attraverso exploit ai quali vi si arriva attraverso siti web compromessi contenenti iframe o javascript offuscati che reindirizzano i browser ai server d’attacco veri e propri.

I produttori di software di sicurezza dovrebbero porre molta più attenzione a questa infezione e scrivere nuovi tool per l’individuazione e la rimozione invece di aspettare la fine del 2009 e dichiarare che il MBR rootkit è stata la peggiore minaccia dell’anno, così come è accaduto lo scorso anno.

Prevx 3.0 è in grado di individuare e rimuovere l’infezione gratuitamente.

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 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 \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