Avevo parlato mesi fa riguardo il famoso TDL3 rootkit, il più avanzato rootkit in the wild mai analizzato. Bene, l’ultima versione di questo rootkit era stata rilasciata mesi fa ed era la build 3.273. Dopo di questa non ci furono ulteriori aggiornamenti al driver del rootkit. Un comportamento molto sospetto, sopratutto se si era abituati a vedere aggiornamenti quotidiani del rootkit da parte dei propri sviluppatori per contrastare le difese dei software di sicurezza.

Ovviamente il rootkit era ben stabile nel sistema e funziona attualmente su tutti i sistemi operativi Windows a 32 bit basati su kernel NT senza bug significativi. Va ovviamente ricordato che il dropper necessita di privilegi amministrativi per potersi installare nel sistema. Tuttavia il team alle spalle del TDL3 rootkit era troppo silenzioso per non doverci aspettare qualcosa di nuovo.

Ed effettivamente hanno confezionato un gran bel regalo, perché il nuovo TDL3 rootkit è stato aggiornato, e stavolta l’aggiornamento è significativo: il rootkit è ora in grado di infettare il kernel dei sistemi operativi Windows a 64 bit.

Perché si tratta di una notizia molto importante? Le versioni a 64 bit del sistema operativo Windows sono considerate molto piu sicure delle loro rispettive versioni a 32 bit per via di alcune misure di sicurezza aggiuntive studiate per rendere molto più difficile l’alterazione del kernel di sistema.

Windows Vista 64 bit e Windows 7 64 bit non permettono a tutti driver di essere caricati nel kernel a causa di una minuziosa verifica della firma digitale del driver. Se il driver non è stato firmato digitalmente, Windows non ne permetterà il caricamento. Questa tecnoglogia permette a Windows di bloccare i rootkit che vanno ad alterare il kernel di Windows, visto che questi rootkit solitamente non sono firmati – o almeno non dovrebbero esserlo.

La seconda tecnica utilizzata da Microsoft per prevenire l’alterazione del kernel di Windows è la famigerata Kernel Patch Protection, meglio conosciuta come PatchGuard. Questa routine di sicurezza blocca ogni tentativo di modifica delle zone sensibili del kernel di Windows – ad esempio SSDT, IDT, codice del kernel e altro.

Queste due tecniche utilizzate assieme hanno permesso ai sistemi Windows x64 di essere fino ad ora molto piu protetti dai rootkit kernel mode.

I primi tentativi di superare queste protezioni sono state viste nel Whistler bootkit, un framework venduto al mercato nero e capace di colpire sia le versioni x86 che x64 di Windows.

Ma questa versione del TDL3 rootkit può essere considerata come la prima versione veramente diffusa di kernel mode rootkit compatibile con i sistemi a 64 bit. I database Prevx hanno individuato questa infezione più di 9 giorni fa e, al momento, si registrano nuovi sample ogni giorno. Questo significa che l’infezione si sta diffondendo nel web, sia tramite siti web a luci rossi che exploit kit.

Parlando dell’infezione in sé, è ancora in fase di analisi. Ma, ad una prima analisi, è difficile considerarla come una versione totalmente nuova di TDL3.

Sembra che qualcuno sia entrato in possesso del codice sorgente del TDL3 rootkit e gli abbia aggiunto alcune funzionalità di bootkit. QUesto perché il TDL3 rootkit ora colpisce il Master Boot Record, come fece il MBR rootkit anni fa e come sta facendo il Whistler bootkit.

Per superare sia il Kernel Patch Protection e la verifica della firma digitale, il rootkit modifica il Master Boot Record in modo da intercettare le routine di startup di Windows, prenderne possesso, modificarle e caricare il proprio rootkit driver. In questo modo entrambe le misure di sicurezza sono superate.

Se nei sistemi x86 di Windows il rootkit non necessita di riavviare immediatamente il sistema perché il driver può essere caricato immediatamente, nelle versioni a 64 bit di Windows la procedura di infezione è differente.

Il rootkit necessita dei privilegi amministrativi per infettare il Master Boot Record, e anche così non può comunque caricare il proprio driver nel kernel ancora. Per cui viene forzato un riavvio immediato del sistema. In questo modo, il MBR opportunamente modificato inizia a fare il proprio lavoro. Il codice del MBR è opportunamente codificato tramite una semplice operazione di ROR.

Anche il numero di versione del rootkit è cambiato, da 3.273 a 0.02. Sembra dunque che sia una build beta, anche perché da test interni il rootkit è sembrato abbastanza instabile.

L’idea principale è che i sorgenti del rootkit siano stati venduti e il nuovo team che l’ha acquistato abbia iniziato ad adattarlo ai sistemi a 64 bit, utilizzando tecniche già viste nel Whistler bootkit e nello Stoned v2 bootkit.

Ciò che è più importante però è che con questa versione del TDL3 rootkit è iniziata ufficialmente una nuova era: l’era dei rootkit a 64 bit.

Un’analisi più approfondita dell’infezione – sempre effettuata da me – è presente a questo indirizzo in inglese – la traduzione italiana verrà effettuata successivamente.

Un nuova falla insomma, o almeno è quello che si può leggere da alcuni articoli che stanno diffondendosi velocemente nel web.

Da quello che si può leggere, questa vulnerabilità permette di eseguire arbitrariamente del codice forzando alcune applicazioni a caricare dei file nocivi. Non sono al momento a conoscenza di ulteriori dettagli sulla falla, e sembra che la società Rapid7 rilascerà ulteriori dettagli durante questa settimana. Così il massimo che possiamo fare è fantasticare un po.

L’articolo di ComputerWorld ricorda che Apple iTunes era vulnerabile a questa falla, che è stata successivamente corretta da Apple. Basta leggere il bollettino di sicurezza Apple per capire che forse questo tipo di attacco 0day non è poi così nuovo.

Il bollettino di sicurezza Apple riporta:

A path searching issue exists in iTunes. iTunes will search for a specific DLL in the current working directory. If someone places a maliciously crafted file with a specific name in a directory, opening another file in that directory in iTunes may lead to arbitrary code execution. This issue is addressed by removing the code that uses the DLL

Questo mi ricorda così tanto un vecchissimo trucco per iniettare codice all’interno di un’applicazione, conosciuto ormai da svariati anni. La parola chiave di tutto ciò è: Dynamic-Link Library Search Order.

Di cosa stiamo parlando? Quando un’applicazione prova a caricare in memoria uno specifico modulo, utilizza solitamente l’API di Windows LoadLibrary / LoadLibraryEx – almeno se si vuole seguire la modalità documentata da Microsoft.

Uno dei parametri accettati dall’API è il percorso al modulo richiesto. Se il programmatore non specifica in maniera esplicita tutto il percorso al modulo bensì solo il nome del modulo, il sistema operativo inizierà a cercare il suddetto modulo in una serie di percorsi già prestabiliti.

La lista di questi percorsi già prestabiliti è chiamata Dynamic-Link Library Search Order ed è esplicitamente documentata nell’MSDN di Microsoft. Questa lista dipende dalle configurazioni del sistema operativo. Tuttavia, la configurazione standard è:

• The directory from which the application loaded.
• The system directory. Use the GetSystemDirectory function to get the path of this directory.
• The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
• The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
• The current directory.
• The directories that are listed in the PATH environment variable.

Quindi, se l’applicazione sta tentando di caricare un modulo specificandone solo il nome, il sistema operativo prima di tutto verificherà se si tratta di un modulo già conosciuto (sono elencati nella chiave di registro KnownDLLs). Se non lo è, inizierà la ricerca in ognuno dei percorsi sopra elencati uno ad uno.

Ad esempio, se il modulo viene trovato subito all’interno della directory da dove l’applicazione è eseguita, Windows interrompe la ricerca e carica questo modulo.

Ora tutto diventa più chiaro, e le possibili vie per sfruttare questo trucco sono molte, soprattutto se si pensa ad un pirata informatico.

Sebbene l’implementazione di questo ordine possa essere oggetto di dubbi e domande, non penso che questa “falla” sia un problema di Windows. La logica dietro il caricamento dei moduli a runtime è ben documentata e spiegata all’interno dell’MSDN. Inoltre, sia l’ordine di ricerca che il funzionamento delle API LoadLibrary/LoadLibraryEx sono ben documentate. Diventa dunque un problema relativo agli sviluppatori, se hanno deciso di seguire le linee guida di sviluppo illustrate da Microsoft o meno. In realtà questo ambiguo comportamento di Windows è sfruttato ormai da anni dai malware ed è oggetto di discussioni online da molto tempo.

Non si sa se la falla discussa sia proprio questa, quello che si può dire è che in caso si tratterebbe di una vecchia-nuova falla 0day.

Il 20 Agosto 2008 il volo JK5022 della compagnia aerea Spanair in partenza da Madrid e diretto alle Canarie precipitò durante la fase di decollo, schiantandosi e prendendo fuoco. Nell’incidente morirono 153 persone delle 172 a bordo. L’aereo, secondo le ricostruzioni, si alzò ad una quota di 40 piedi prima di iniziare una rovinosa caduta. La causa dell’incidente fu riscontrata in una errata configurazione dell’aereo, inadatta per la fase di decollo.

L’aereo era provvisto un sistema di controllo della configurazione dell’aereo, denominato TOWS (Take Off Warning System), che verifica automaticamente le condizioni dell’aereo per il decollo e avvisa l’equipaggio di eventuali errate configurazioni tramite segnali acustici. Tuttavia, quel giorno, il TOWS non emise alcun allarme.

Il TOWS è in funzione solo se l’aereo è configurato in modalità ground, una delle modalità di funzionamento dei dispositivi dell’aereo. Le modalità di funzionamento dell’aereo sono controllate da sofisticati dispositivi elettronici, in grado di determinare la configurazione corretta da applicare. Il TOWS viene disattivato automaticamente nel momento in cui l’aereo è configurato in modalità flight.

Erronamente, però, quel giorno l’aereo – per malfunzionamenti tecnici in corso di verifica – era configurato in modalità flight (sorvolo al momento la specifica tecnica per la quale l’aereo fosse configurato per metà in modalità ground e per metà in modalità flight, una specifica molto interessante ma che rende difficile la comprensione dell’accaduto ai meno addetti ai lavori). Di conseguenza sia flap che slat erano configurati in modalità flight, modalità errata per la fase di decollo. Il TOWS avrebbe dovuto verificare le configurazioni dei flap e slat, lanciando l’allarme per la loro errata configurazione. Tuttavia, essendo configurato in modalità flight, il TOWS era stato automaticamente disattivato. Il pilota non si era dunque accorto di niente, procedendo al decollo.

Ora, tuttavia, vengono fuori ulteriori dettagli che spostano la questione verso il campo della sicurezza informatica. Stando all’articolo del giornale iberico, il computer centrale della compagnia spagnola Spanair dovrebbe collezionare tutti i dati diagnostici degli aerei e procedere alla verifica automatica degli stessi. In caso di errori, malfunzionamenti o errate configurazioni, un allarme sarebbe dovuto scattare sul monitor del PC, permettendo agli addetti di bloccare immediatamente la partenza e richiamare l’aereo per ulteriori verifiche.

A quanto sembra, però, l’allarme non scattò nel PC della società, perché gli errori che erano presenti nei dati diagnostici dell’aereo non furono registrati in tempo dal PC. Questo a causa di un malware informatico, di un trojan che a quanto risulta bloccò il sistema.

Nulla si sa al momento di questo trojan, sebbene si supponga che non sia stato inserito nel sistema allo scopo di causare l’incidente aereo, bensì sia stata una casualità i cui effetti collaterali sono risultati disastrosi.

Non è possibile verificare o meno la notizia, non avendo ulteriori fonti ufficiali. Tuttavia, non sarebbe neanche poi così impensabile la cosa. Altri worm, in passato, causarono notevoli disagi nelle reti di molte società anche legate a servizi pubblici. Tra i vari basti ricordare Slammer e Blaster, che fecero impazzire il web e tutto ciò ad esso collegato, comprese reti di servizi di pubblica utilità.

Quello che è certo è che il mondo virtuale dell’informatica e il mondo reale stanno confluendo sempre più, e la sicurezza informatica non va più considerata come un optional ma come un processo fondamentale per poter accedere al nuovo cyber-mondo che è sempre più intorno a noi.

Le due falle, come già detto in un articolo precedente, erano state utilizzate per eseguire del codice da remoto (CVE-2010-1797) e poi uscire dalla sandbox ed eseguire il codice con privilegi di root (CVE-2010-2973). Alcuni dettagli erano stati già specificati in un articolo precedente, altri vengono spiegati meglio in questo articolo.

La prima falla, presente nel lettore di file PDF integrato, permette tramite un documento PDF volutamente malformato di eseguire del codice inserito all’interno del documento stesso. Prima specifica da fare: molti si sono chiesti se in questa falla c’entrasse Adobe Acrobat Reader. Assolutamente no, Apple utilizza un proprio engine di rendering dei file PDF, e la falla è presente in questo engine. Più esattamente il problema risulta essere in una non corretta gestione di alcuni font CFF, nel caso dell’exploit utilizzato da comex di un Type1C font. L’esecuzione di codice avviene a causa di uno stack overflow.

Il font è stato incluso in uno stream del file PDF, stream che è stato poi compresso tramite il filtro FlateDecode (zLib). Questo specifico stream contiene sia il font malformato che il secondo exploit per ottenere i privilegi di root ed evadere dunque dalla sandbox.

Il secondo exploit, che è quello più grave, sfrutta una falla nel framework IOSurface, un framework utilizzato per condividere interfacce grafiche tra varie applicazioni e gestito interamente dal kernel. Alcuni parametri degli object IOSurface creati non vengono correttamente validati dal framework, causando un integer overflow. Essendo il codice gestito nel kernel, questo errore permette di eseguire codice con privilegi di root, ottenendo così di evadere dalla sandbox.

Nel caso dell’exploit, i parametri non correttamente validati dell’object IOSurface sono IOSurfaceAllocSize, IOSurfaceBytesPerRow, IOSurfaceHeight e IOSurfaceWidth. Come è possibile vedere dall’immagine, questi parametri vengono generati appositamente per sfruttare la falla in maniera corretta ed eseguire dunque l’exploit.

Con il rilascio dell’update da parte di Apple, anche l’hacker comex ha rilasciato il codice sorgente degli exploit utilizzati, rendendo molto più semplice la vita ad eventuali malintenzionati che potrebbero sfruttare il codice per installare codice nocivo nei sistemi Apple non aggiornati. È necessario infatti ricordare che tutti gli iPhone e iPod Touch con un firmware iOS inferiore al 4.0.2 sono vulnerabili a questi due exploit – mentre il dispositivo iPad è vulnerabile se ha qualsiasi firmware inferiore all’iOS 3.2.2. Indipendentemente se i dispositivi sono stati sbloccati o meno tramite tecnica di JailBreak, saranno comunque vulnerabili se non utilizzano gli ultimi firmware messi a disposizione dalla Apple.

Vista la gravità – e la complessità – dell’attacco, è caldamente raccomandato l’aggiornamento dei propri dispositivi al firmware 4.0.2, se si tratta di iPhone o iPod Touch, oppure al firmware 3.2.2 se si tratta di iPad.

Una piccola nota a margine è dovuta: il framework IOSurface è stato messo a disposizione anche nei sistemi Mac OS X, a partire da Mac OS X 10.6 Snow Leopard. Che possa essere potenzialmente presente anche qui questa grave falla?

Proprio il sistema operativo made in Apple che fa battere il cuore al famoso smartphone iPhone ha subito in queste ultime ore un grave attacco, fortunatamente utilizzato a scopo benevolo ma che, potenzialmente, può essere veramente molto grave in termini di sicurezza del dispositivo.

L’hacker comex ha rilasciato una procedura per effettuare il jailbreak del dispositivo così tecnicamente avanzata da rendere quasi banale l’intervento dell’utente, il quale deve semplicemente eseguire il proprio browser Safari installato nell’iPhone e aprire una specifica pagina web. Il resto, come per magia, è tutto automatico.

In realtà, quella magia è una grave falla nel sistema operativo iOS4 versione 4.0.1 (e potenzialmente anche nei precedenti). Anzi, esattamente, sono due gravi falle, perché sono due gli exploit utilizzati contemporaneamete. Una nel browser Safari, l’altra del sistema operativo.

Nel momento in cui l’utente apre quella specifica pagina web, il browser carica automaticamente un file PDF malformato, contenente un exploit e del codice eseguibile. Non è una novità nel mondo Windows, nel quale i PDF che sfruttano exploit sono oramai veicolo di infezioni da molto tempo. Sono una semi-novità nei sistemi operativi di casa Apple, dimostrando che anche questi sistemi operativi sono altrettanto vulnerabili nel momento in cui vengono utilizzati da un bacino di utenza più ampio.

Nel caso in questione, il browser Safari non gestisce correttamente il formato dei font CFF (Compact Font Format) all’interno dei file PDF. L’apertura di un file PDF volutamente malformato, quindi, permette l’esecuzione di codice nocivo inserito all’interno del PDF stesso. Un exploit dunque che permette esecuzione di codice, anche da remoto come nel caso del tool di comex.

Una volta riusciti nell’esecuzione del codice nocivo rimane il problema più grande, cioè il codice è stato eseguito all’interno della sandbox integrata in iOS4. Il sistema iOS4 integra una sandbox che permette di isolare i file eseguibili, limitandone notevolmente la possibilità di agire nel sistema.

Il tool per il jailbreak non avrebbe comunque potuto funzionare se limitato dalla sandbox di iOS4. Qui entra in gioco il secondo exploit, che è molto più grave perché si tratta di un exploit in grado di evadere dalla sandbox, tecnicamente definito come un privilege escalation exploit.

Da alcune indagini iniziali sembrerebbe che la falla sfruttata da questo exploit possa risiedere nella libreria IOKit, facente parte di un framework di Apple messo a disposizione degli sviluppatori. Le indagini sono comunque in corso.

Come è possibile vedere, quello che agli occhi di un utente inesperto è sembrata una magia dell’hacker comex, il quale in pochi minuti è riuscito ad effettuare il jailbreak di un dispositivo, in realtà agli occhi di un utente esperto dovrebbe apparire come un gravissimo problema, una doppia falla nel sistema che spalanca le porte a possibili utilizzi malevoli di questa scoperta.

Apple non ha ancora rilasciato nessun aggiornamento né alcuna comunicazione a riguardo.

Paradossalmente l’unico modo per applicare qualsiasi workaround che possa inibire l’utilizzo di queste falle consiste nell’effettuare il jailbreak del proprio dispositivo ed installare delle patch di terze parti.

Procedura che ad Apple, chiaramente, non va giù.

Tra gli argomenti trattati si è potuto parlare di evoluzione dei malware, sicurezza dei vari sistemi operativi, quali browser sono al momento i più sicuri per poter navigare, e molto altro.

L’intervista, di 3 pagine, è raggiungibile a questo indirizzo.

Buona lettura

Nella giornata di ieri abbiamo isolato una nuova variante di un worm Autorun, individuato come Autorun:Worm-LNK, capace di diffondersi tramite dispositivi USB removibili utilizzando la vulnerabilità relativa ai file LNK. Una volta che il sistema è stato infettato, il malware copia in ogni dispositivo USB removibile collegato svariati file LNK modificati per l’exploit, insieme ad una copia di sé stesso.

Il primo problema nell’utilizzare l’exploit dei file LNK è che il collegamento deve essere il percorso esatto a dove il malware è effettivamente localizzato. Questo può diventare un problema visto che i dispositivi USB removibili cambiano lettera di unità ogni volta che vengono collegati ad un PC differente. Il malware tenta di risolvere questo problema creando più file LNK nel dispositivo USB, ognuno dei quali richiama una lettera di unità differente: da D: a J:. Poi, gli eseguibili del malware vengono salvati nella directory principale dell’unità. È una tipologia di bruteforce utilizzata per individuare quale sia la lettera di unità che è stata assegnata dal sistema al dispositivo USB removibile. Inoltre, il malware utilizza ancora il vecchio trucco dell’autorun.inf, che è – purtroppo – ancora efficace.

L’individuazione dei file exploit LNK tramite signature è ancora inaffidabile, visto che i file creati dal malware e analizzati su VirusTotal sono riconosciuti al momento solo da 5 antivirus su 41. Scrivere firme virali per questo exploit potrebbe essere un problema e causare falsi positivi, essendo una falla di progettazione e non di programmazione.

Vedremo probabilmente molti malware utilizzare questa tecnica, anche perché si tratta di una falla che colpisce tutte le versioni di Windows, da Windows 2000 a Windows 7, sia 32 che 64 bit. Ancor peggio, gli utenti che utilizzano Windows 2000, Windows XP, Windows XP Service Pack 1 e 2 non riceveranno alcun aggiornamento di sicurezza, essendo scaduto il supporto tecnico da parte di Microsoft per questi prodotti.

Il miglior workaround al momento è la disabilitazione della visualizzazione delle icone per i file LNK e PIF, come riportato da Microsoft nel loro bollettino di sicurezza. Microsoft ha inoltre rilasciato un Fix-it tool che applica automaticamente il workaround in questione, fino a quando la società non rilascerà un patch ufficiale – sperando che lo faccia il più velocemente possibile, visto che i malware writer non aspettano la patch, hanno già iniziato a giocare con questa falla.

Questa variante del worm Autorun si sta diffondendo abbastanza rapidamente, stiamo infatti ricevendo report costanti dalla comunità Prevx.

Prevx è in grado di individuare, bloccare e rimuovere dai PC questa infezione.

Prevx blog

Come avevo detto precedentemente, e confermato anche da altri ricercatori successivamente, non si tratta di una falla nella programmazione del codice, ma si tratta di una falla a livello di design del sistema operativo, un errore concettuale più che un bug.

Ciò significa che per Microsoft sarà un problema molto più difficile da sistemare, poiché richiede una nuova operazione di design affinché si possa risolvere la vulnerabilità.

Al momento la risposta delle società di antivirus non è rapida, anche perché la portata della falla non permette di poter scrivere velocemente signature generiche senza causare falsi positivi. Creando un nuovo file lnk ad hoc per sfruttare la falla si può subito vedere, tramite VirusTotal, come solo 7 antivirus su 42 riconoscano l’exploit. Invece, analizzando il proof of concept reso pubblico online qualche giorno fa, si può notare come quasi tutti i software antivirus lo individuino. Questo permette di capire come le signature per quest’ultimo file exploit non siano state studiate come signature generiche per la falla, ma come signature specifiche per il file specifico.

Non ho intenzione ancora di mostrare come poter creare da soli un exploit funzionante per questa falla, anche se le informazioni online sono oramai molte e permettono ai più abili di scoprirlo da soli. Quello che è oramai pubblico è in quale punto del sistema operativo risiede la falla, cioè nella gestione delle icone del pannello di controllo di Windows – dei file CPL.

Microsoft ha aggiornato il proprio bollettino di sicurezza, descrivendo più dettagliatamente la falla e comunicando alcuni possibili workaround da applicare per mitigare questo vettore di attacco.

Tra i workaround suggeriti c’è la disabilitazione della visualizzazione delle icone per i file LNK e PIF, la disabilitazione del servizio WebClient e il blocco del download di file LNK e PIF da Internet.

Chiaramente gli ultimi due sono dei consigli utili per mitigare il problema, ma il primo è quello veramente fondamentale, che permette al momento di bloccare la falla. Anche se, purtroppo, tutte le icone dei collegamenti nel sistema spariranno, lasciando spazio ad una icona bianca.

L’utilizzo più probabile di questa falla è tramite dispositivi USB removibili, permettendo ad un malware di venir eseguito automaticamente non appena l’utente apre attraverso un file manager – o semplicemente attraverso risorse del computer – la directory del dispositivo stesso. Ciò non toglie che sia possibile anche sfruttare questa falla tramite WebDAV, permettendo ad un file LNK o PIF di andare ad eseguire un malware che non è fisicamente presente nel sistema ma è residente in un PC collegato in rete. Inoltre, come anche dichiarato dal bollettino Microsoft, anche alcuni tipi di documenti che supportano per l’appunto questi collegamenti sono vulnerabili.

Purtroppo la diffusione dell’exploit tramite Metasploit non semplifica la vita alle società di sicurezza, ma la semplifica molto ai malware writer, che sanno ora come poter sfruttare questa falla in maniera rapida ed efficace.

Al momento tutte le versioni di Windows sono vulnerabili, ma gli utilizzatori di Windows 2000 e Windows XP (fino al Service Pack 2 compreso) dovrebbero preoccuparsi di aggiornare il proprio sistema operativo ad una versione che è ancora supportata da Microsoft. Questo perché, essendo questi sistemi operativi fuori supporto tecnico, non verranno aggiornati dalla società di Redmond. O ricorreranno a patch di terze parti (se verranno rilasciate), o continueranno a tenere il sistema operativo senza icone dei collegamenti, o continueranno a coesistere con tale falla – quest’ultima scelta sicuramente sconsigliata.

Microsoft ha messo a disposizione il proprio tool Fix It, per applicare il primo workaround sopra elencato. Il tool è scaricabile a questo indirizzo .

In coda a questo articolo metto un video che ho realizzato per mostrare SafeLink, una patch che sto sviluppando a titolo personale in grado di intercettare e bloccare questo exploit.

Questa funzionalità, proprio perché ampiamente abusata da malware – è stata disattivata di default in Windows 7 ma continua a mietere vittime nella moltitudine di sistemi Windows XP diffusi nel mondo. Anche nelle aziende, tutt’ora, è prassi comune disattivarla poiché causa primaria di infezioni.

Ora c’è un’altra minaccia di cui preoccuparsi tuttavia: è stata isolata da pochi giorni una falla 0-day (CVE-2010-2568) che colpisce trasversalmente tutte le versioni di Windows da XP a Windows 7 e che permette l’esecuzione automatica di qualsiasi libreria (dll) senza che essa venga effettivamente eseguita dall’utente.

La falla risiede in una gestione “errata” dei file LNK, dei file collegamento di Windows. Un file LNK volutamente malformato può forzare Windows a caricare in memoria un eventuale file nocivo. Ciò significa che un collegamento che magari potreste trovare in una pen drive USB in realtà è utilizzato per caricare un malware.

L’unica cosa che l’utente deve fare è aprire la finestra in Windows, ad esempio attraverso Risorse del computer, e nel momento in cui semplicemente si accede alla directory dove il file lnk è presente automaticamente Windows processerà il file e caricherà il file collegato.

Questa tipologia di attacco – prima sconosciuta – è stata individuata proprio durante un’analisi di alcuni malware da parte della società bielorussa VirusBlokAda Ltd. Malware che sembra siano stati utilizzati per degli attacchi mirati ad alcuni sistemi Siemens WinCC SCADA, visti alcuni codici specifici presenti nelle loro stringhe.

Non mi è possibile rilasciare ulteriori informazioni tecniche su come la falla funzioni, sebbene online si possano trovare stralci di informazioni tecniche che possono aiutare a comprenderne il funzionamento. Quello che però posso dire è che non si tratta di una falla vera e propria, nel senso di un exploit in grado di sfruttare qualche errore di programmazione lato Microsoft tramite stack overflow, heap overflow o tecniche similari. In realtà questa falla sfrutta una funzionalità di Windows.

Da una analisi che ho effettuato oggi della falla è lecito pensare che sia più una leggerezza lato programmazione, una feature sviluppata senza pensare ai possibili rischi conseguenti, che non piuttosto un bug vero e proprio.

Non ci sono aggiornamenti disponibili per ora da parte di Microsoft, la quale sta analizzando il problema. Al momento, come consigliato anche dalla società di Redmond, è necessario disabilitare la visualizzazione delle icone nei file lnk.

La procedura è meglio specificata nel bollettino di sicurezza Microsoft 2286198, alla sezione Workarounds.