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

Oggi ho speso un po di tempo per analizzare un malware che è stato segnalato da parecchi utenti ai nostri laboratori di ricerca e che è stato intercettato euristicamente da Prevx Edge.

L’infezione è già conosciuta nel web come Trojan.Neprodoor, ma guardando su Internet non ho trovato informazioni tecniche veramente utili riguardo questo trojan, così ho deciso di dargli uno sguardo più in profondità.

E’ stato immediatamente chiaro che l’infezione non è banale ed è in grado di superare la maggior parte dei prodotti attuali di sicurezza.

L’infezione si propaga per mezzo di un dropper, chiamato reader_s.exe. Tuttavia, questo è solo il primo di una lunga catena di installer.

Il dropper è criptato con un packer proprietario, così non appena viene eseguito si decomprime in memoria ed inizia il proprio payload.

Effettua una copia di sé all’interno della directory di sistema di Windows %windir%\system32 e all’interno della cartella del profilo utente, aggiungendo poi le relative chiavi di registro HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run e HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run, in entrambe utilizzando il valore [reader_s] e il percorso all’eseguibile.

Questo può essere definito come il pre-loader. Terminato il processo, il dropper esegue un nuovo processo svchost.exe nel quale inietta il proprio codice sottoforma di dll. Esegue dunque un thread all’interno del neo-creato processo.

Il controllo passa ora al loader reale, che controlla l’infezione ed è in grado di scaricare ed installare i componenti dell’infezione. Il loader comunica con uno dei server centrali utilizzando un protocollo privato e criptato. Tutto il traffico passa dunque per la porta TCP 80, ma non sarà controllato dai filtri web a causa della codifica.

Il loader è in grado di rubare informazioni dal PC, funzionare come proxy server, scaricare ed installare altre componenti dell’infezione.

Ora inizia la parte più interessante. Il loader scarica una componente spambot e un rootkit installer.

Dopo che i due installer sono stati scaricati in memoria, vengono iniettati all’interno di altri due processi svchost.exe. Tutto viene eseguito in memoria, niente è fisicamente scritto sul disco.

Mentre la dll con funzioni di spambot è una componente classica, ciò che è più interessante è il rootkit installer. Eseguito, infetta il driver ndis.sys leggendone il codice originale, codificandolo e includendolo nel proprio codice malevolo. Poi, il nuovo ndis.sys viene sovrascritto all’originale e una copia del nuovo ed infetto driver viene inserita anceh all’interno della directory di sistema dllcache. Ora, il driver ndis.sys è criptato e inglobato nel codice del rootkit.

Facendo così, il rootkit non ha bisogno di alcuna chiave di registro di Windows per eseguire il servizio e può sopravvivere nascosto in memoria.

Dopo che il servizio ndis viene riavviato, il rootkit è in grado di allocare parte della memoria nel kernel e copia il proprio codice lì dentro, poi viene eseguito il vero ndis.sys.

Il rootkit, che è ora un pezzo di codice non tracciabile in memoria, installa una routine per il controllo dei processi in esecuzione, al fine di intercettare l’esecuzione del processo services.exe.

Una volta intercettato, il rootkit inietta all’interno del processo lo stesso loader di cui ho parlato prima. Il ciclo ricomincia, con la componente spambot che verrà nuovamente scaricata e iniettata all’interno del processo svchost.exe.

Per rimanere invisibile all’interno dell’hard disk, il rootkit prende il controllo della funzione del kernel IofCallDriver, cambiando il puntatore alla funzione e redirezionandolo alla propria funzione.

Questo è uno dei vari modi per filtrare la lettura dell’hard disk, intercettando le chiamate dei driver. Se qualsiasi software tenta di leggere il driver ndis.sys, verrà mostrata la copia originale e pulita del driver. Ogni tentativo di modifica del driver verrà inoltre negato.

Il malware è chiaramente opera non di un teenager annoiato, l’intera architettura che sta dietro all’infezione lascia pensare che sia il lavoro di qualcuno con esperienza nel campo.

Il rootkit è in grado di restare invisibile alla maggior parte delle attuali tecnologie antirootkit e la struttura modulare dell’infezione lascia pensare che il(/i) malware writer possa aggiornarla in maniera rapida.

Prevx Edge e Prevx CSI sono in grado di rimuovere l’infezione.

Nel mentre che cercate tracce di infezione da SMM rootkit nel vostro PC, tanto che ci siete, date un occhio se magari un semplice, banale kernel mode rootkit non stia già controllando il vostro sistema operativo.

Prevx Blog

La ricerca è focalizzata sulle possibilità di sfruttare un bug scoperto nei sistemi basati su CPU Intel per riuscire ad eseguire del codice arbitrario in System Management Mode, la modalità di funzionamento più privilegiata nei processori Intel.

Come già sottolineato dalla stessa Joanna Rutkowska e Rafal Wojtczuk nel documento rilasciato, questo non è il primo attacco sviluppato nei confronti dell’SMM. Da alcuni anni abbiamo visto molti tentativi di muovere gli attacchi dal campo del sistema operativo, più in profondità del Ring0. Abbiamo visto dei proof of concept rootkit basati su hypervisor a Ring -1 e ora del malware in modalità SMM (che potrebbe essere definito come Ring -2).

Premettendo che non commenterò la ricerca in sé - potrebbe essere l’argomento per un altro post - vorrei invece focalizzarmi su alcuni punti importanti.

Il progetto bluepill è già conosciuto e pubblico da qualche tempo, così lo sono altri progetti quali SubVirt, ci sono anche proof of concept di infezioni del firmware delle schede PCI. La ricerca è un fattore intrinseco nell’uomo e permette a tutti di fare continuamente passi avanti.

Tuttavia va tutto visto secondo la giusta prospettiva.

Leggendo in alcuni forum, ho notato alcune persone spaventate da questo attacco che parlavano addirittura di buttare la propria CPU perché probabilmente vulnerabile a questi attacchi.

E’ vero, c’è la remota possibilità che possa accadere un’infezione, un rootkit che sfrutti un attacco all’SMM. Tuttavia è molto improbabile. Perché?

Semplice. I malware attuali sono utilizzati per rubare informazioni, numeri di carte di credito, informazioni bancarie, sottrarre soldi e identità digitali. I malware writer hanno capito che non c’è bisogno di utilizzare tecniche avanzate quale può essere un attacco tramite l’SMM, che è molto difficile da scrivere ed è hardware dipendente.

Poi ci sono gli attacker che invece vogliono trasformare il pc degli utenti in degli zombie per creare una botnet e venderla al miglior offerente o utilizzarla per estorsioni o per inviare spam. Anche qui ci sono svariati rootkit kernel mode che sono in grado di superare la maggior parte dei software antirootkit inclusi nelle suite di sicurezza antivirus.

Sì, ci sono tool antirootkit standalone online che sono in grado di individuare anche le ultime infezioni, ma sono troppo complicati e difficili da utilizzare per l’utente medio.

Attualmente gli attacchi sono progettati e sviluppati per essere veloci, efficienti e per cambiare continuamente al fine di rimanere invisibili. I malware writer hanno capito che se vogliono colpire le società di antivirus devono colpire il più veloce possibile, sapendo che le tecnologie attuali degli antivirus non riusciranno a tenere il loro passo e verrano così superate.

Noi alla Prevx vediamo questo trend continuamente, isolando migliaia di nuovi malware ogni giorno.

Da una ricerca interna è stato possibile vedere chiaramente come la maggior parte dei rootkit in the wild riescano a nascondersi agli occhi delle suite antivirus con una facilità estrema. Non hanno bisogno di sovrascrivere l’SMRAM - come i rootkit SMM fanno - o di utilizzare tecnologie di virtualizzazioni per prendere possesso del sistema operativo. Sono “semplici, elementari, kernel mode rootkit”.

Sì, non interessanti quanto i rootkit SMM, ma sono questi il vero nemico contro cui combattare ogni giorno. E il sistema operatio è ancora il campo di battaglia che tanto piace ai malware writer.

I SMM rootkit sono sicuramente una possibile minaccia ma sono molto meno pericolosi dei malware attuali che sono là fuori. Per registrare i tasti premuti, password e dati personali, non c’è bisogno di codice eseguito in SMM - in realtà è possibile farlo anche da user mode in un account limitato senza bisogno di alcun exploit.

Bisogna essere spaventati dagli SMM rootkit tanto da buttare la propria CPU? Assolutamente no. C’è bisogno di utilizzare più prodotti di sicurezza per rafforzare le barriere del sistema? Certamente.

Sono state isolate alcune false e-mail scritte chiaramente in un italiano da traduttore online che si spacciano per una comunicazione di Microsoft. Un classico e banale esempio di social engineering che sfrutta un periodo particolarmente movimentato dal punto di vista della sicurezza informatica data la diffusione del worm Conficker.

L’e-mail, con oggetto: Microsoft ha recentemente rilasciato un aggiornamento della protezione recita:

Cari Clienti Microsoft,

Vi preghiamo di notare che Microsoft ha recentemente rilasciato un aggiornamento della protezione per Microsoft Windows OS.
L’aggiornamento si applica alle seguenti versioni di sistema operativo: Microsoft Windows 98, Microsoft Windows 2000, Microsoft Windows Millennium, Microsoft Windows XP, Microsoft Windows Vista.
Si prega di notare, che la presente aggiornamento si applica al aggiornamenti con prioritа alta categoria.
Al fine di proteggere il computer dalle minacce alla sicurezza e problemi di prestazioni, si consiglia di installare questo aggiornamento.
Dato che la distribuzione pubblica di questo aggiornamento tramite il sito ufficiale http://www.microsoft.com sarebbe risultato efficace nella creazione di un software “maligni”, abbiamo preso una decisione di emettere una versione sperimentale privato di un aggiornamento per tutti gli utenti di Microsoft Windows OS.
Come il computer и impostato per ricevere le notifiche quando sono disponibili nuovi aggiornamenti, che avete ricevuto questo avviso.
Al fine di avviare l’aggiornamento, si prega di seguire passo-passo le istruzioni:

1. Esegui il file, che avete ricevuto insieme a questo messaggio.
2. Seguire attentamente tutte le istruzioni che appaiono sullo schermo.

Se non cambia nulla dopo aver eseguito il file, probabilmente nelle impostazioni del vostro sistema operativo si dispone di una indicazione di eseguire tutti gli aggiornamenti in un contesto di routine.
In tal caso, a questo punto, l’aggiornamento del vostro sistema operativo sarа finito.
Ci scusiamo per gli eventuali disagi che questo ritorno potrebbe essere la causa per voi.

Grazie, Steve Lipner Direttore della Sicurezza Assurance Microsoft Corp.

L’allegato, ovviamente non proveniente da Microsoft, è una variante del trojan ZBot, con alcune modifiche per evitare di essere eseguita all’interno di macchine virtuali e sandbox. Il malware bloccherà la propria esecuzione, mostrando un messaggio di errore, se eseguito all’interno di:

• VMware
• VirtualBox
• VirtualPC
• CWSandbox
• JoeBox
• ThreatExpert
• Anubis
• Sandboxie

Una volta eseguito, il malware verrà iniettato all’interno di vari processi. Il trojan ha funzionalità di rootkit user mode, prendendo il controllo delle API:

NtQueryDirectoryFile
LdrGetProcedureAddress
LdrLoadDll
NtCreateThread
GetClipboardData
TranslateMessage

Il trojan viene copiato all’interno della directory di sistema di Windows con il nome di oembios.exe. Le dimensioni sono varie, visto che il trojan aggiunge alla fine del file dei dati casuali, così da evitare una facile individuazione da parte delle società di sicurezza, rendendo inutile ogni checksum sull’intero file.

Inoltre vengono creati i file sysproc86.sys e sysproc32.sys all’interno della directory %systemroot%\sysproc64. I due file non sono driver, ma sono file criptati contenenti dati sensibili catturati dal trojan all’interno del PC e istruzioni fondamentali per il funzionamento del malware.

Per autoeseguirsi all’avvio, il trojan modifica la voce Userinit alla chiave: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\Currentversion\Winlogon aggiungendo il percorso al file oembios.exe.

È, come al solito, raccomandabile non eseguire alcun allegato da e-mail sospette. In questo caso, una lettura attenta del testo dell’e-mail avrebbe fatto scattare alcuni sospetti, dato l’errato utilizzo della lingua italiana.

Sia Prevx Edge che Prevx CSI sono in grado di individuare e rimuovere l’infezione. Prevx Edge ha euristicamente bloccato l’infezione prima ancora che la firma virale fosse stata aggiunta.

È il caso del Worm.Conficker, che da un mese a questa parte si sta diffondendo nelle reti aziendali e su internet sfruttando principalmente la vulnerabilità pubblicata da Microsoft con il bollettino di sicurezza MS08-067.

Una nuova variante è stata isolata a fine anno, interessante perché tenta più vie di diffusione e blocca l’accesso ai siti internet delle società di sicurezza.

La dll che viene creata all’interno della directory di sistema, dalle dimensioni di 157.816 bytes e dal nome casuale, è compressa con UPX e con un packer proprietario, utilizzato per offuscare il codice. Infatti, decompresso il primo livello di compressione, ci si trova davanti a dello spaghetti-code, una serie continua e interminabile di redirezioni di codice, inserite con lo scopo di rallentare tentativi di decompressione del codice malevolo.

La libreria di sistema viene configurata con gli attributi di file nascosto, file di sistema e sola lettura. Inoltre vengono modificati diritti di accesso al file, settando le ACL in modo tale che nessuno possa accedervi.

Il malware disabilita alcuni servizi di Windows, tra cui Windows Defender, BITS e Windows Update.

Per autoavviarsi, la libreria di sistema crea una voce all’interno del registro di sistema, alla chiave:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\{NOME CASUALE} con valore %SystemRoot%\system32\svchost.exe -k netsvcs

e come parametro ServiceDll il percorso alla dll infetta. Facendo ciò, il malware ha modo di avviarsi tra i servizi di sistema, iniettato all’interno del processo svchost.exe.

Modifica le impostazioni di Windows in modo da velocizzare la diffusione di sé stesso all’interno di lan aziendali. Per far ciò modifica il parametro autotuning attraverso il comando:

netsh interface tcp set global autotuning=disabled

Modifica la voce di registro SYSTEM\CurrentControlSet\Services\Tcpip\Parameters [TcpNumConnections]

Carica un driver per patchare in memoria il driver tcpip.sys e sbloccare il limite delle connessioni che Microsoft ha inserito in Windows XP SP2.

Crea inoltre la seguente chiave di registro:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run [VALORE CASUALE] = “rundll32 [NOME DLL INFETTA],{stringa casuale}”

Modifica la seguente chiave di registro per evitare di mostrare i file nascosti:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\explorer\Advanced\Folder\Hidden\SHOWALL [CheckedValue] = “0″

Per evitare il ripristino di sistema, utilizza l’API ResetSR esportata dalla libreria del sistema operativo srclient.dll in modo da cancellare tutti i punti di ripristino esistenti.

Le ACL delle chiavi di registro create per autoeseguire l’infezione vengono modificate in modo tale da renderne più difficile l’accesso e la rimozione.

Il worm, modifica il firewall di Windows, aprendo una porta TCP casuale e mettendosi poi in ascolto come server HTTP. Il server verrà utilizzato per diffondere l’infezione via lan.

Per bloccare l’accesso ai siti web dedicati alla sicurezza informatica il worm intercetta e blocca le richieste DNS contenenti una delle seguenti stringhe:


cert.
sans.
bit9.
vet.
avg.
avp.
ca.
nai.
windowsupdate
wilderssecurity
threatexpert
castlecops
spamhaus
cpsecure
arcabit
emsisoft
sunbelt
securecomputing
rising
prevx
pctools
norman
k7computing
ikarus
hauri
hacksoft
gdata
fortinet
ewido
clamav
comodo
quickheal
avira
avast
esafe
ahnlab
centralcommand
drweb
grisoft
eset
nod32
f-prot
jotti
kaspersky
f-secure
computerassociates
networkassociates
etrust
panda
sophos
trendmicro
mcafee
norton
symantec
microsoft
defender
rootkit
malware
spyware
virus

Una volta fatto ciò, il worm inizia la routine di replicazione. Per fare ciò, tenta di diffondersi attraverso la lan sfruttando attacchi dizionario e un exploit per la falla MS08-067, già sistemata da Microsoft con gli aggiornamenti di Windows.

Per l’attacco dizionario, il worm cerca tutti i PC in rete con condivisione ADMIN$ e tenta l’accesso utilizzando una delle seguenti password:

0
00
000
0000
00000
0000000
00000000
1
11
111
1111
11111
111111
1111111
11111111
2
22
222
2222
22222
222222
2222222
22222222
3
33
333
3333
33333
333333
3333333
33333333
4
44
444
4444
44444
444444
4444444
44444444
5
55
555
5555
55555
555555
5555555
55555555
6
66
666
6666
66666
666666
6666666
66666666
7
77
777
7777
77777
777777
7777777
77777777
8
88
888
8888
88888
888888
8888888
88888888
9
99
999
9999
99999
999999
9999999
99999999
123
123123
12321
123321
1234
12345
123456
1234567
12345678
123456789
1234567890
1234abcd
1234qwer
123abc
123asd
123qwe
1q2w3e
12
21
321
4321
54321
654321
7654321
87654321
987654321
a1b2c3
aaa
aaaa
aaaaa
abc123
academia
access
account
Admin
admin
admin1
admin12
admin123
adminadmin
administrator
anything
asddsa
asdfgh
asdsa
asdzxc
backup
boss123
business
campus
changeme
cluster
codename
codeword
coffee
computer
controller
cookie
customer
database
default
desktop
domain
example
exchange
explorer
file
files
foo
foobar
foofoo
forever
freedom
fuck
games
home
home123
ihavenopass
Internet
internet
intranet
job
killer
letitbe
letmein
login
Login
lotus
love123
manager
market
money
monitor
mypass
mypassword
mypc123
nimda
nobody
nopass
nopassword
nothing
office
oracle
owner
pass
pass1
pass12
pass123
passwd
password
Password
password1
password12
password123
private
public
pw123
q1w2e3
qazwsx
qazwsxedc
qqq
qqqq
qqqqq
qwe123
qweasd
qweasdzxc
qweewq
qwerty
qwewq
root
root123
rootroot
sample
secret
secure
security
server
shadow
share
sql
student
super
superuser
supervisor
system
temp
temp123
temporary
temptemp
test
test123
testtest
unknown
web
windows
work
work123
xxx
xxxx
xxxxx
zxccxz
zxcvb
zxcvbn
zxcxz
zzz
zzzz
zzzzz

Se l’attacco ha successo, la dll infetta viene copiata all’interno di \\[indirizzo pc]\ADMIN$\System32\[NOME CASUALE].dll e ne viene programmata l’esecuzione come job attraverso l’API NetScheduleJobAdd.

Il worm si diffonde anche attraverso dispositivi removibili, quali pen drive usb. Una volta connesso il dispositivo, il malware crea il file autorun.inf e copia la dll all’interno della cartella RECYCLER. Sia la cartella che il file vengono configurati con attributo di sola lettura.

Se la data del sistema è il 1 Gennaio 2009, il worm tenterà di scaricare una versione aggiornata di sé stesso - con possibili nuove funzionalità - da una serie di siti Internet.

È dunque importante per tutte le aziende e gli utenti rimasti infetti di controllare i PC e di rimuovere l’infezione.

Prevx CSI ed Edge sono in grado di individuare, intercettare e rimuovere l’infezione.

Come già fatto per il 2006, ripropongo quest’anno un breve report delle principale minacce a livello di malware riscontrate durante il 2008, con accenni a possibili evoluzioni nel 2009 dei malware e dei prodotti di sicurezza.

Il pdf, è scaricabile da qui: 2008: Il web si tinge di giallo.

Auguro a tutti una buona lettura e, soprattutto, un nuovo anno che sia ricco di felicità e di serenità - anche, perché no, dal punto di vista informatico.

L’attacco è tutt’ora utilizzato e non esiste al momento un aggiornamento risolutivo del problema, la vulnerabilità è ancora in fase di analisi.

L’exploit sfrutta un errore di Internet Explorer nella gestione del DCOM Data Binding e non, come erroneamente dichiarato da alcuni siti online, un errato comportamento del parser XML.

L’errore è stato identificato in uno use-after-free, cioè l’utilizzo di una o più determinate zone di memoria dopo che queste siano state deallocate e non più utilizzate. Solitamente questo errore consiste nel lasciar puntare ad uno o più puntatori - che inizialmente puntano ad determinata una zona di memoria allocata - ancora la stessa zona di memoria dopo che questa sia stata liberata. Di conseguenza, si rischia la sovrascrittura di dati importanti - se la zona di memoria in questione è stata già riutilizzata - con la conseguenza di possibili crash, sino anche alla possibile esecuzione di codice malevolo.

Alcune pagine web, volutamente malformate, permettono così di istruire Internet Explorer a scaricare e ad eseguire codice nocivo.

Al momento gli exploit pubblici colpiscono esclusivamente Internet Explorer 7, ma Microsoft ha specificato che tutte le versioni di Internet Explorer sono vulnerabili.

Se non esistono patch al momento - sia Windows Vista SP1 che Windows XP SP3 totalmente aggiornati sono vulnerabili - esistono però alcuni workaround che permettono di limitare il problema.

Il primo è l’utilizzo della tecnologia DEP per limitare il problema. Nel caso di Vista, Internet Explorer 7 di default ha la funzionalità DEP disattivata, mentre la versione la versione a 64 bit di Vista ha attivato il DEP su tutti i processi. Per attivare il DEP nella versione a 32 bit di Vista è necessario eseguire Internet Explorer come amministratore, andare dunque su Strumenti - Opzioni Internet - Avanzate - Attiva la protezione della memoria per contrastare gli attacchi da Internet.

Il DEP deve chiaramente essere supportato da un processore che gestisca la tecnologia NX Bit (o XD Bit).

Un’alternativa può essere l’utilizzo di software che prevengono gli attacchi causati dall’esecuzione di codice da zone di memoria adibite ai dati. Un esempio è il programma free Comodo Memory Firewall.

Un altro workaround è la configurazione in Internet Explorer dell’area di navigazione Internet e Intranet su Alta, così da richiedere l’autorizzazione per l’esecuzione dell’Active Scripting. Altrimenti, se si utilizza una configurazione manuale di Internet Explorer, configurare l’Active Scripting in modo tale da chiedere l’autorizzazione prima di eseguire script.

Un altro workaround è la disabilitazione della funzionalità XML Data Island, eliminando la seguente chiave di registro: HKEY_CLASSES_ROOT\CLSID\{379E501F-B231-11D1-ADC1-00805FC752D8}.

Su Windows Vista e Windows Server 2008 è necessario eseguire Regedit come amministratore prima di effettuare i seguenti cambi ed assegnare i diritti della chiave di registro. Eseguito Regedit, andare alla chiave di registro HKEY_CLASSES_ROOT\CLSID\{379E501F-B231-11D1-ADC1-00805FC752D8}, tasto destro sulla chiave, poi cliccare su Autorizzazioni - Avanzate - Proprietario - cambia proprietario all’amministratore. Fatto questo, eliminare la chiave in oggetto.

Un altro - seppur drastico - workaround è la disabilitazione della dll oledb32.dll attraverso il comando:

Regsvr32.exe /u “%ProgramFiles%\Common Files\System\Ole DB\oledb32.dll”

Per i sistemi a 64 bit, i comandi sono invece:

Regsvr32.exe /u “%ProgramFiles%\Common Files\System\Ole DB\oledb32.dll”
Regsvr32.exe /u “%ProgramFiles(x86)%\Common Files\System\Ole DB\oledb32.dll”

Chiaramente quest’ultimo workaround è particolarmente drastico, perché tutti i programmi che utilizzano le funzionalità della libreria oledb32.dll non funzioneranno più correttamente.

Al momento tutti i malware individuati che sono stati utilizzati in attacchi web con questo exploit sono stati euristicamente bloccati da Prevx Edge senza alcun problema. Inoltre, in Windows Vista con UAC attivato e Internet Explorer 7 in modalità protetti, i danni sono comunque limitati grazie alla protezione dell’account utente e al livello di integrità, che riescono a prevenire gravi danni al sistema.

Microsoft ha rilasciato il bollettino identificato come 961051.

Bollettino scomparso dal sito stesso della società dopo pochi giorni - e dopo notevoli polemiche in tutta la comunità informatica - e rimpiazzato da un annuncio in cui Apple afferma si trattasse di un vecchio articolo e che, in realtà, i Mac non necessitano di software antivirus perché sono progettati con tecnologie di sicurezza che forniscono già di proprio la protezione contro software malevoli.

Un’affermazione discutibile, sicuramente, come la stessa società di sicurezza F-Secure ha commentato nel proprio blog. Il problema è che quando si va a toccare l’argomento sicurezza in sistemi operativi diversi da Windows, immediatamente si alza un polverone a scudo protettivo.
Solitamente le frasi che si sentono dire è: “Passa a Mac, quello sì che è un sistema sicuro e non Windows“, “Passa a Mac che lì non esistono virus” et similia.

Entrambe le affermazioni sono false, ma non è altrettanto scontato dire il contrario, cioè “Il Mac è insicuro” e “Esistono tanti virus per Mac quanti quelli per Windows“.

Bisogna fare delle riflessioni ed avere un minimo di apertura mentale.

Partiamo con delle cifre: dalle statistiche W3Counter relative ad Ottobre 2008, risulta una diffusione di Windows pari a circa l’89,86%, di MacOS X pari a circa il 5,33% e di Linux pari a circa il 2,09%.
Questi sono dati significativi, ma non da soli, vanno presi in esame insieme ad altri fattori ed utilizzati per unire poi tutti i punti di riflessione.

Chiaramente, in quell’89,86% c’è alta probabilità che siano presenti una vasta gamma di persone, da quelle esperte fino a quelle che del computer sanno a malapena come si apra un browser - e soprattutto se sanno che si chiami browser.

In un 5,33% di utilizzatori MacOS X è statisticamente molto più semplice che siano presenti coloro a cui il MacOS X piace per scelta - per tutte quelle caratteristiche che rendono il MacOS X unico. Spesso gli utilizzatori di MacOS X sono persone che, bene o male, hanno un livello di conoscenze normalmente superiori rispetto alla base degli utenti Windows. Questo perché, per la maggior parte, gli utenti che poi passano a Mac hanno comunque in qualche modo avuto conoscenza di Windows - sia essa superficiale o meno - e sono costretti ad adattarsi alla nuova struttura del sistema operativo di casa Cupertino.

Comunque sia, queste sono solo ipotesi e dati statistici che a poco servono per riflettere sul grado di sicurezza di un sistema operativo.

Tecnicamente, Windows è - senza ombra di dubbio - il sistema più attaccato da virus informatici per una serie di motivi.

In primo luogo, ovviamente, c’è la percentuale di diffusione che fa sì che sia una vittima illustre in ambito desktop. Ma, soprattutto, per il modo con cui durante questi anni Windows è stato utilizzato.

Tutto il ramo Windows relativo al Kernel NT (Windows NT, Windows 2000, Windows 2003, Windows XP, Windows Vista) è costituito da alte prestazioni in ambito sicurezza informatica. Windows XP, attualmente il sistema operativo di maggior successo di Microsoft, ha delle ottime funzionalità di sicurezza che, se utilizzate, riuscirebbero a ridurre drasticamente la diffusione di malware informatici. Prima nota: ridurre drasticamente non significa azzerare. Seconda nota: per l’appunto, “se utilizzate“.

Probabilmente per motivi di semplicità e di compatibilità, Windows è spesso venduto di default con un account amministratore (root, per chi utilizza sistemi operativi Linux/UNIX/UNIX based), cioè lascia all’utilizzatore del sistema operativo i diritti per poter fare qualsiasi cosa. Dal semplice lanciare un gioco o un’applicazione, sino a poter modificare qualsiasi aspetto, anche quelli più tecnici, del sistema operativo.

Questo, altrettanto probabilmente, fu fatto per rendere le cose più semplici agli sviluppatori di software, che hanno poi abusato della possibilità di default di scrivere in qualunque parte del sistema operativo. Inoltre, è più semplice l’utilizzo da parte di un vasta gamma di utenti. Insomma, un circolo vizioso.

OS X è un sistema operativo che sfrutta, di default, già alla partenza, tutte le caratteristiche di sicurezza del kernel XNU, tra le quali l’utilizzo immediato di un account limitato che permette di “isolare” bene la zona relativa ad un determinato utente impedendogli di poter effettuare modifiche al di fuori di essa se non con permesso root.

Cosa possibilissima, anche se in alcuni casi è effettivamente più difficile a causa di alcuni problemi di compatibilità causati dal circolo vizioso sopra evidenziato, anche con Windows XP attraverso least-privileged user account (LUA) e Software Restriction Policy (SRP).

Windows Vista, in ambito sicurezza, ha fatto notevoli passi avanti grazie allo User Account Control che permette, finalmente, di avere di default un account “limitato” così come in OS X. Come in OS X è necessario inserire la password di amministratore per effettuare dei cambi al sistema, altrettanto è necessario su Windows Vista fornire l’autorizzazione.

Inoltre, in Windows Vista, sono state implementate molte tecnologie riguardanti la sicurezza informatica, tra le quali migliorie ed aggiunte alla prevenzione di attacchi causati da buffer overflow. L’ultimo caso, tra i vari che sfruttano buffer overflow, sono stati i worm che sfruttano la vulnerabilità MS08-067 - ma basti ricordare Sasser (MS04-011) e Blaster (MS03-026) su tutti.

Windows Vista, oltre al supporto al Data Execution Prevention (DEP), include il supporto all’ASLR, che fornisce un ottimo alleato per la prevenzione di questa tipologia di attacchi.

MacOS X, dal punto di vista di difesa da attacchi buffer overflow, è invece carente rispetto sia a Windows che a Linux.

Mentre l’ASLR in Windows e Linux è applicato in tutti i processi all’avvio del sistema o dinamicamente per ogni processo, in MacOS X gli indirizzi delle librerie vengono randomizzate solo quando la cache condivisa viene aggiornata (update_dyld_shared_cache).

Da Apple: “update_dyld_shared_cache ensures that dyld’s shared cache is up-to-date. (This command can also be called as update_prebinding.) Normally, this command never needs to be manually run. Instead, it is automatically run by launchd when dyld notices the shared cache is out of date“.

Inoltre, in MacOS X, l’ASLR non randomizza l’eseguibile stesso, zone di memoria quali stack, heap e altre importanti zone.

Il DEP, come spiegato in un articolo precedente, permette di marcare le zone di memoria che non dovrebbero contenere codice eseguibile come non-executable (NX bit). Gli attuali processori supportano pienamente l’NX-Bit. Le versioni Tiger e Leopard per sistemi x86 settano l’NX bit esclusivamente su segmenti stack, lasciando completamente scoperto l’heap.

Già questo, di per sé, lascia capire come scrivere exploit, e malware che sfruttano exploit, è possibile su Windows tanto quanto su MacOS x. Anzi, a dirla tutta, dal punto di vista di protezione da corruzione di memoria il MacOS X risulta un passo indietro rispetto a Windows Vista e Linux.

Fatta questa precisazione, solitamente le due osservazioni che vengono fatte sono: “Per MacOS X non esistono virus” e “Si, ma se esistono c’è comunque bisogno della password di root per fare danni“.

Riguardo la prima affermazione, è ovviamente falsa. Se è vero che il numero è esiguo, non è corretto dire che il pericolo sia inesistente.

Esistono diverse famiglie di malware per OS X, e lo sviluppo si è impennato soprattutto in questo ultimo periodo durante il quale il MacOS X ha visto incrementare la propria diffusione.

DNSChanger, Leap, Inqtana e altri sono una riproduzione in piccolo della fauna presente già da anni in ambiente Windows.

C’è chi afferma che è comunque necessario fornire la password di root per far danni al sistema intero. Vero, così come è necessario dare l’autorizzazione su Windows Vista.
Ma ciò non ferma gli utenti più sprovveduti a fornire questo lasciapassare al malware in questione che, ingannando lo sprovveduto user, lo convince della bontà delle proprie intenzioni.

Questo è il grande problema di una larga diffusione di un sistema operativo, che finirà delle mani di tante persone, gran parte delle quali non hanno (e non vogliono neanche
perderci tempo) le basi fondamentali, minime, di sicurezza necessarie per l’utilizzo del computer.

I falsi codec per visualizzare filmati porno, finti programmi attaverso programmi di IM, crack, divx/vmw/xvid protetti da falsi DRM. Il social engineering, l’ingegneria sociale, è ancora il veicolo principale di numerosi attacchi e di diffusione di malware informatici in ambito Windows, ma ciò non toglie che lo stesso possa succedere in ambito MacOS X dove il problema che si porrebbe sarebbe identico.

Sempre che il malware in questione voglia fare danni al sistema, perché altrimenti potrebbe anche accontentarsi di girare sotto account limitato, sufficiente comunque per ottenere determinate informazioni.

Senza considerare eventuali bug nel kernel o in qualunque altra componente del sistema - sia in Windows che in MacOS X - che potrebbero permettere l’innalzamento dei privilegi (privilege escalation) evitando la necessità delle credenziali di amministratore.

Il rischio di MacOS X di subire attacchi malware è tale e quale a quello di Windows, nel caso di exploit è tecnicamente anche più semplice rispetto a Windows Vista.

Inoltre, l’articolo è stato incentrato quasi esclusivamente sulla questione malware, ma quando si parla di sicurezza si parla anche di altri argomenti. Come la stessa F-Secure ha voluto sottolineare, gli utenti MacOS X sono esposti tanto quanto gli utenti Windows al phishing. E ciò non è da sottovalutare, viste le cifre del phishing e le relative vittime.

Ciò che “salva” MacOS X sono le cifre di diffusione, notevolmente inferiori rispetto a Windows, che lo difendono dall’ondata barbara di un’utenza spesso cieca alle problematiche di sicurezza, salvo poi trovarsi vittima di qualche truffa. Anche se, in molti casi, si tratta di cecità indotta. Le persone hanno già tanti problemi durante la giornata, non vogliono “perdere tempo” a preoccuparsi anche dei problemi di sicurezza di un pc. Vogliono che qualcuno ci pensi per loro.

Ciò che condanna Windows Vista è un’eredità pesante, causata probabilmente da scelte manageriali che hanno fatto al contempo la fortuna di Microsoft e dei malware writer.

Una cosa è certa: qualunque sistema operativo è a rischio malware.

Ogni giorno vengono creati migliaia di nuovi codici malevoli utilizzati spesso per attacchi mirati, uno dei fenomeni di primaria importanza da controllare per ogni società di sicurezza.

L’ultimo articolo che ho letto riguardo l’efficacia di soluzioni antivirus è redatto dalla società di sicurezza FireEye, nel proprio blog ufficiale. Sebbene l’articolo sia molto interessante e ben scritto, sarei stato personalmente molto più attento nel trarre le conclusioni finali.

L’opinione dell’autore dell’articolo è che le soluzioni di sicurezza siano efficaci contro malware più vecchi rispetto che contro i nuovi malware, dove la percentuale media di inviduazione è di un 40% dei prodotti. Essenzialmente, le parole dell’autore sono: “gli AV sono verosimilmente in grado di individuare un bot realmente in azione meno della metà delle volte“.

Sebbene condivida che l’individuazione e il blocco di nuove minacce sia una sfida molto difficile, perché necessita di tecnologie di prevenzione e engine euristici particolarmente efficaci, tuttavia mi sorgono parecchi dubbi sulle conclusioni raggiunte.

Dove non concordo assolutamente è l’utilizzo del servizio online VirusTotal come tool primario per verificare l’efficacia dei prodotti antivirus. VirusTotal è un utile servizio che permette di ottenere alcune statistiche, non può assolutamente essere utilizzato come strumento per la stesura di comparative e come metro di giudizio dell’efficacia di antivirus.

Purtroppo un bel numero di quelle che si definiscono come “comparative indipendenti” fanno riferimento ai risultati ottenuti da VirusTotal per giudicare un prodotto antivirus.

L’individuazione di nuovi malware sganciandosi dall’utilizzo di signature è un tema particolarmente caldo che è stato ampiamente discusso anche all’interno di conferenze internazionali. Chiunque lavori nel settore della sicurezza informatica sà che, ad oggi, l’individuazione per mezzo di firme virali non è più sufficiente. Lo sviluppo di nuove tecnologie per prevenire e bloccare attacchi mirati e nuovi malware è uno dei principali obiettivi di ogni produttore di software di sicurezza informatica. Non potrebbe essere differente.

Per noi alla Prevx è il nostro primo obiettivo. Appena rilasciato Prevx Edge, molti utenti ci hanno comunicato come Edge sia riuscito a bloccare nuove minacce anche se, scansionati su VirusTotal, questi file sospetti non erano individuati dall’engine Prevx incluso nello scanner online VirusTotal.

Un esempio su tutti: un famoso sito web è stato attaccato qualche giorno fa e la home page è stata modificate inserendovi all’interno del codice malevolo. Mentre molti utenti hanno testato il malware su VirusTotal traendo le conclusioni errate, Prevx Edge è stato in grado di bloccare euristicamente l’infezione dall’inizio.

Questo perché molte nuove tecnologie euristiche che utilizziamo non possono essere incluse in uno scanner on-demand, il quale controllerà esclusivamente se in un file è riscontrabile una precisa signature.

Questa è la situazione per Prevx, ma è anche una situazione comune per molte altre società di sicurezza. Spesso gli antivirus includono nuove tecnologie - behavior blockers, heuristic behavior analyzers, dynamic heuristic engine e così via - che sono utilizzate per mitigare (o addirittura colmare, la maggior parte delle volte) il gap che si viene a formare tra la creazione di un malware e il rilascio di firme virali.

Se qualche volta, analizzando un file su VirusTotal, viene fuori qualche individuazione euristica, ciò non implica necessariamente che tutta la tecnologia euristica di un determinato prodotto è stata inclusa nello scanner on-demand. Semplicemente, ci sono alcune tecnologie che non possono essere incluse in uno scanner on-demand. Ciò però non toglie che queste tecnologie giochino un ruolo cruciale nell’intercettazione di attacchi 0day.

Fare riferimento esclusivamente ai risultati di VirusTotal rischia di far perdere la reale efficacia delle soluzioni antivirus testate.

Questo è il motivo per il quale utilizzare VirusTotal per redigere comparative e test di prodotti antivirus è un approccio sbagliato.

Prevx Blog