La realtà dei fatti – condivisa da chiunque conosca tecnicamente i vari sistemi operativi – è che tutti e tre i sistemi operativi sono a rischio malware, sebbene Windows sia ampiamente più vulnerabile – sia chiaro, non per una questione tecnica, quanto più che per una maggiore esposizione che causa una maggiore attenzione da parte degli utenti e dei malware writer. Infatti, stando alle statistiche di Aprile 2011 pubblicate da MarketShare, Windows detiene uno share di mercato dell’88,91%, OS X del 5,40%, Linux dello 0,94%. Una differenza in punti percentuali abissale, che ben evidenzia quanto Windows possa essere un target preferenziale rispetto alle altre due piattaforme.

Una delle obiezioni che solitamente viene addotta contro l’affermazione secondo la quale i sistemi operativi Linux sarebbero vulnerabili alle infezioni è quella che qualsiasi operazione viene eseguita come utente limitato e non come root, amministratore di sistema. Di conseguenza, un eventuale malware eseguito come utente limitato non permetterebbe di fare alcun danno al sistema in sé.

Come è stato ampiamente dimostrato più volte, la realtà dei fatti è che, invece, un qualsiasi malware, pur essendo eseguito come utente limitato, può comunque danneggiare gravemente tutto ciò che riguarda la sessione dell’utente che ne rimane infetto, pur non intaccando l’integrità del sistema operativo.

Il concetto di malware si è evoluto nel tempo, codici nocivi non più interessati a rimanere quanto più possibili nascosti nel sistema o codici altamente complessi sviluppati allo scopo di mostrare le capacità individuali dei vari programmatori. I malware attuali puntano tutto sulla capacità di poter intercettare e rubare quanti più dati possibili, dati personali, identità, dati di accesso a siti di e-banking o di commercio online, password di e-mail, ftp, qualsiasi dato che è in genere facilmente intercettabile anche senza aver a disposizione diritti amministrativi. La facile accessibilità ad un numero incredibile di engine polimorfici, sia lato client che lato server, permette ai malware di poter agire spesso in maniera indisturbata agli occhi dei software antivirus, sfruttando quel lasso di tempo che intercorre tra il rilascio del malware e l’aggiornamento rilasciato per i software antivirus. E tutto da un semplice account utente limitato. Di esempi ce ne possono essere vari, da ZeuS a SpyEye, a Carberp, a Tatanga, tutti trojan che possono lavorare tranquillamente in ambiente limitato senza avere a disposizione privilegi di amministratore di sistema.

Su Linux il concetto non si sposta poi di molto. Anche su questa piattaforma, considerata al sicuro da malware, è possibile intercettare tutti questi dati con un semplice malware che catturi ad esempio le attività del browser. D’altronde, con lo stesso principio utilizzato per Windows, sia il malware che l’eventuale browser vengono solitamente eseguiti nella stessa sessione dell’utente.

Un esempio si può fare con un semplice keylogger, capace di intercettare le password digitate da tastiera. Nel caso di Windows ci sono svariati modi per poter verificare lo stato della tastiera e di eventuali tasti premuti, anche da account limitato, ad esempio sfruttando l’API GetAsyncKeyState() che può essere eseguita senza privilegi amministrativi. In Linux viene in aiuto a questo scopo il gestore grafico X Window System, che si occupa tra l’altro di fornire l’interfaccia verso tastiera e mouse. Una sua funzione in particolare, XQueryKeymap(), svolgerebbe lo stesso identico lavoro della sua equivalente funzione in Windows precedentemente citata, e tutto questo ovviamente anche da account limitato.

In altre parole un trojan, quale ad esempio il famigerato SpyEye, che già è in grado di colpire Windows anche da account limitato compromettendo il funzionamento di Firefox al fine di intercettare ciò che passa per il browser, sarebbe facilmente portabile in ambiente Linux.

Nasce qui la seconda obiezione: come ci arriva questo malware in un ambiente Linux? Obiezione alla quale è facile rispondere: tramite gli stessi canali utilizzati per la maggior parte in Windows, quindi ingegneria sociale, warez, peer 2 peer, falsi plugin per visualizzare video a luci rosse. Tutti vettori di infezione dove è l’utente spesso a fare la differenza (n.b. spesso, non sempre).

Il fatto che esistano dei repository ufficiali che semplificano la vita agli utenti Linux, i quali possono attingere direttamente a tali server e scaricare i software che vogliono in maniera sicura, non esclude il fatto che molti software e tool non siano presenti in tali repository, ma vengono scaricati dai siti ufficiali delle varie software house o dai siti web dei vari sviluppatori. Inoltre, anche in Linux esistono programmi a pagamento, e dove esistono programmi a pagamento molto facilmente esistono anche crack e keygen – un esempio può essere VMWare workstation e relativi crack/keygen. Sicuramente ci sono anche alternative gratuite a tali prodotti, tuttavia lo stesso si può dire in ambito Windows, dove però gli utenti continuano spesso a preferire crack e keygen ad alternative free. Questo è uno dei potenziali vettori di infezione in ambito Linux, già ampiamente testato in ambito Windows.

Tornando però alla prima obiezione, cioè quella di non avere la password di root e quindi l’impossibilità di danneggiare l’integrità del sistema. Quante volte gli utenti desktop di Linux, ad esempio Ubuntu oppure OpenSuse, nell’effettuare delle installazioni software, oppure delle configurazioni del sistema, fare del testing, si trovano nella necessità di inserire la propria password di root al fine di poter eseguire tali operazioni come root? Può un eventuale malware, in azione nel sistema con privilegi limitati, intercettare tale password?

La risposta è sì. Nel momento in cui l’utente digita la propria password davanti alla richiesta ad esempio del comando su, sudo, oppure davanti alla richiesta di gksudo o kdesudo, gksu, kdesu, un eventuale malware con privilegi limitati che sta interrogando lo stato della tastiera tramite XQueryKeymap() può intercettare tale password, ottenendo quindi la chiave d’accesso al sistema. Nel momento in cui viene chiesta la password di root, tale richiesta non viene in alcun modo isolata dal sistema, o filtrata, permettendo dunque a qualunque software di intercettarla.

Microsoft, in Windows Vista e Windows 7, nell’implementazione dello User Account Control e del Mandatory Integrity Control, ha implementato una tecnologia denominata User Interface Privilege Isolation, o UIPI, capace di isolare le interfacce grafiche in base ai livelli di integrità di ogni processo in esecuzione. Dei livelli di integrità ne è stato parlato già in precedenza in questo blog specificandone meglio il loro funzionamento, che è comunque riassumibile in una sorta di ulteriore suddivisione dei privilegi e permessi all’interno di uno specifico account. Ogni processo viene eseguito con uno specifico livello di integrità che può essere in generale alto, medio, basso, con il livello standard che è il medio. Nessun processo può in alcun modo avere accesso ai processi eseguiti con un livello di integrità superiore a quello del processo in questione; inoltre, scendendo di livello, aumentano le restrizioni in termini di permessi che vengono applicate al processo eseguito. Grazie alla tecnologia UIPI nessun processo può comunicare di default con le interfacce grafiche dei processi eseguiti ad un livello di integrità superiore. Questa tecnologia, implementata principalmente per la prevenzione degli shatter attack, è utilissima anche per isolare finestre importanti. Eseguendo un programma come amministratore, ad esempio, tutto ciò che verrà scritto in tale finestra non può essere intercettato da un malware eseguito in modalità utente, anche all’interno della stessa sessione. Questo perché il malware verrebbe eseguito ad un livello di integrità medio, mentre l’eventuale programma eseguito come amministratore verrebbe eseguito con un livello di integrità alto. Cosa che non avviene invece in Ubuntu Linux, come dimostrato nel video sopra pubblicato.

Inoltre anche in Windows potrebbe essere necessario inserire la password di amministratore se si sta lavorando da un account limitato e si ha bisogno di effettuare qualche modifica o installazione di qualche specifico software. Anche in Windows verrà mostrata la finestra di inserimento password, così come mostrato nel video di Ubuntu, con una differenza fondamentale: in Windows Vista e Windows 7, la finestra viene totalmente isolata dal sistema: si tratta della modalità UAC Secure Desktop, una modalità in cui tutti quanti i processi del sistema vengono sospesi ad eccezione dei processi eseguiti da account SYSTEM – quindi tutti i processi utente vengono totalmente sospesi, rimangono solo i processi critici di Windows. La finestra viene quindi totalmente isolata, così da poter permettere all’utente di inserire la propria password in sicurezza senza che eventuali malware eseguiti in modalità utente possano intercettarla. Nel video mostrato qui sotto è possibile visualizzare il comportamento di un semplice keylogger in Windows Vista e Windows 7 nelle situazioni sopra descritte.

Questo problema, mostrato sopra in Ubuntu, non è un problema di Ubuntu in sé, quanto dell’implementazione di X in generale. Un problema che è conosciuto già da svariato tempo, tanto che uno sviluppatore Debian ha dichiarato lo scorso Ottobre 2010:

If you ever believed that there is *any* way to prevent a program having access to your session to obtain root access when you use the same session to do stuff as root, you have been abused [...] If there is a malicious program running in your session, you are completely screwed.

Stessa situazione verificabile anche su OpenSuse, come dimostrato nel video qui sotto:

In definitiva, sia Windows che Linux (nelle proprie incarnazioni delle varie distribuzioni) sono due ottimi sistemi operativi, entrambi con i propri pregi ed i propri difetti. Linux è da sempre un sistema rinomato per la sua solidità e stabilità; Windows, grazie al salto avanti fatto con Vista prima e 7 poi, è diventato un sistema operativo al passo con i tempi, estremamente valido e sicuro in termini tecnici. Nessuno dei due sistemi operativi è al sicuro da malware, entrambi sono ampiamente vulnerabili. Windows è maggiormente esposto, vero, paga dunque il pegno per essere il sistema operativo più diffuso al mondo. Linux è meno esposto in ambito desktop, se ne sta più tranquillo e al sicuro da potenziali attacchi di malware – non sarebbe redditizio in fondo focalizzarsi su un 1% circa di mercato e, a parte l’eventuale fama, non si avrebbe un rientro economico rapido. Ad oggi Linux è più al sicuro rispetto a Windows? A rigor di logica ovviamente sì. Linux è più sicuro di Windows? Come è possibile vedere, se si volesse attaccare il pinguino, ci sarebbero tutte le carte in regola per poterlo fare. Ad oggi, tuttavia, l’utilizzo di Linux è garanzia di una maggiore impermeabilità ai malware. L’importante è non farsi cogliere impreparati se il vento dovesse cambiare.

La prima variante di questo trojan, denominata MBRLock, salvava una copia del MBR originale in un altro settore del disco fisso e sovrascriveva il settore 0 con il proprio codice. Chiedeva poi una password di sblocco che si poteva ottenere pagando una specifica cifra online tramite una pagina web. Una mia analisi più dettagliata di questa prima variante è disponibile in inglese a questo indirizzo.

In questi giorni è stata isolata una nuova variante di questo trojan. Questa volta però non chiede più di effettuare un pagamento tramite pagine web, bensì di chiamare un numero telefonico per ottenere il codice di sblocco. Il trojan è criptato con un packer proprietario al fine di offuscare il codice originale del trojan, anche se decifrare il codice è un compito relativamente facile. I veicoli di infezione sono i soliti: siti di crack, warez e siti web contenenti exploit. Per poter essere eseguito richiede diritti di amministratore (in caso di Windows Vista/7, se l’UAC è abilitato, richiede l’accettazione del messaggio di avviso di Windows).

La particolarità di questo trojan è che non utilizza un singolo numero telefonico, ma contiene una lista di numeri telefonici a pagamento specifica per diverse nazioni. Il trojan analizza la lingua utilizzata dal sistema operativo che sta infettando utilizzando l’API di Windows GetUserDefaultUILanguage. Se il PC risulta essere localizzato in Italia, Austria, Belgio, Svizzera, il trojan contiene una lista di numeri a pagamento specifici per ognuna di queste nazioni. Se, altrimenti, si tratta di un altro stato, viene utilizzato un numero unico internazionale localizzato in Liechtenstein. Per quanto riguarda il numero italiano, si tratta di un numero 899, una numerazione a valore aggiunto.

Una volta che il trojan ha infettato il sistema operativo, attende due minuti ed effettua un riavvio forzato del sistema, così che l’utente si trova immediatamente davanti al seguente messaggio:

I numeri utilizzati sono i seguenti:

Italia
899 021 233

Svizzera
0906-000 172
0906-000 169
0906-000 173

Belgio
0907 480 52
0907 480 46

Austria
0930 823 833

Liechtenstein
+423 877 0158

Contrariamente a quanto scritto nel messaggio in inglese, i dati non sono stati in realtà criptati, né vi è un numero massimo di tentativi per sbloccare il computer. Anzi, la procedura di sblocco è molto più semplice del previsto poiché non vi è da parte del trojan un controllo preciso della password, bensì solamente della sua lunghezza. In altre parole, qualsiasi stringa di 14 caratteri andrà bene al fine di sbloccare il trojan, ad esempio “12345678901234“.

Una volta sbloccato, il trojan rimuoverà qualsiasi traccia di sé e permetterà l’avvio immediato del sistema così come era stato lasciato precedentemente all’infezione.

Grazie al pronto intervento del Centro Nazionale Anticrimine Informatico per la Protezione delle Infrastrutture Critiche e la collaborazione con la polizia internazionale, si sta procedendo alla chiusura di tali numeri telefonici.

E così, dopo ben dodici beta release e due release candidate, Firefox 4 arriva sui desktop degli utenti con diverse novità sul piatto. A dire il vero arriva un po in ritardo, considerando che il suo rivale Internet Explorer è giunto già da qualche giorno alla nona versione con una roadmap di due beta e una release candidate. Come un orologio svizzero, in tempo per sostituire la versione di Internet Explorer 8, rilasciata nel 2009 e con un tempo di vita – considerato ottimale – di due anni. Sembra inutile parlare di Chrome, il browser targato Google, che da circa tre anni ha iniziato la scalata alla vetta, guadagnandosi una sempre più ampia percentuale di consensi.

Firefox 4 arriva dunque leggermente in ritardo rispetto alle major release dei concorrenti, rilasciate già nelle scorse settimane. Arriva con delle novità che, in realtà, così tanto novità non sono agli occhi dei concorrenti. Arriva con un supporto all’HTML5, implementato già in Internet Explorer 9 (e in Chrome già da diverso tempo). Arriva con un plugin container, un processo separato dal browser che contiene i vari plugin – ad esempio Flash – al fine di prevenire la spiacevole situazione nella quale un plugin in crash possa bloccare l’intera navigazione. Soluzione adottata già da tempi immemori in Google Chrome. Arriva con l’accelerazione hardware, già implementata in Google Chrome e Internet Explorer 9. Migliora la capacità di individuare siti di phishing e siti potenzialmente nocivi, grazie all’utilizzo del servizio Google Safe Browsing, implementato anche in Google Chrome – Internet Explorer utilizza invece un servizio proprietario denominato SmartScreen.

Dove invece Firefox 4 potrebbe essere ritenuto deludente è nella sicurezza a livello di architettura del software. Da ciò che si evince, esce letteralmente già vecchio nella sua quarta versione, penalizzato da un’implementazione della sicurezza a livello software obsoleta e notoriamente insicura.

Le probabilità, durante la navigazione online, di incappare in qualche pagina web contenente exploit capaci di sfruttare dei bug – noti o non noti – dei browser stessi o dei plugin installati nei browser è molto alta, e da anni la percentuale continua ad alzarsi in maniera vertiginosa. Questo fenomeno pone l’accento sull’importanza della sicurezza del codice che viene scritto e sul fatto che, in progetti di dimensioni medio/grandi – quali possono essere browser web e plugin vari – è alquanto improbabile riuscire a scrivere del codice totalmente corretto senza lasciare spazio a nessun bug. Bug che, se scoperto, potrebbe permettere ad eventuali pirati informatici di eseguire del codice nel PC vittima senza alcun intervento dell’utente.

Per questo Google Chrome e Internet Explorer hanno deciso di implementare tecnologie di sandboxing, progettate in modo da tentare di arginare eventuali bug presenti nei propri prodotti. In parole più semplici, durante la navigazione in Internet, sia Google Chrome che Internet Explorer pongono la sessione di navigazione in una modalità protetta, limitata, separata dal resto del sistema – e con essa anche gli eventuali plugin utilizzati dal browser. Se, per qualsiasi motivo, l’utente, sua sfortuna, incappa in una pagina web capace di sfruttare qualche bug presente nel browser o nei plugin, e di conseguenza riesce a far eseguire del codice nocivo nel sistema, ecco che il codice nocivo non potrà arrecare alcun danno al sistema (o potrà fare dei danni molto limitati).

Internet Explorer basa la propria tecnologia di sandboxing esclusivamente sulle nuove tecnologie Microsoft implementate in Windows Vista e Windows 7, vale a dire lo User Account Control e il Mandatory Integrity Control. Google Chrome invece implementa una propria tecnologia di sandboxing basata sulla gestione dei privilegi degli utenti unita alla possibilità di aggiungere ulteriori restrizioni grazie ai job object di Windows. In altre parole un framework di sicurezza retrocompatibile con i più vetusti Windows – il tutto senza ovviamente disdegnare anche le nuove tecnologie implementate in Windows Vista e 7 ed utilizzate già da Internet Explorer.

Due browser fondamentalmente all’avanguardia, che necessitavano di una risposta adeguata da parte di Firefox. Una risposta che però è mancata e che tarda ad arrivare.

Il browser di Mozilla non è stato adattato alle nuove tecnologie di sicurezza fornite da Microsoft: sia il processo firefox.exe che il processo plugin-container.exe vengono eseguiti ad un livello di integrità medio, senza alcun tipo di restrizione se non la restrizione fornita dall’account limitato generico configurato in Windows – ammesso che l’utente stia utilizzando il sistema come utente limitato e non come amministratore.

Un esempio su tutti: è cosa ben nota come il plugin Flash di Adobe sia spesso vittima di attacchi da parte di pirati informatici. In Firefox un eventuale attacco a Flash potrebbe avere molto più successo rispetto ad un attacco subito su Chrome o Internet Explorer. La forza di Firefox, e la sua sicurezza, ad oggi – così come in passato – sta nella massiccia disponibilità di estensioni che possono mitigare il problema. La più famosa è l’estensione NoScript, una sorta di script firewall, capace di bloccare tutti gli script presenti nelle pagine web e di eseguire solo quelli presenti nella white list configurata dall’utente. Decisamente funzionale, ma non troppo comoda – soprattutto se si parla di un’utenza medio-bassa.

Sicuramente la rivalità tra i tre browser più in voga del momento si terrà nel campo delle performance, della personalizzazione, della compatibilità e della leggerezza sul sistema. Probabilmente non si terrà nel campo della sicurezza, dove purtroppo Firefox 4 è nato già vecchio.

Per maggiori informazioni tecniche sulle tecniche di sandboxing, rimando ad un articolo scritto in precedenza QUI.

UPDATE: Per meglio specificare, Mozilla ha in programma una sandbox da diverso tempo, concetto inserito in un progetto di più ampio respiro dedicato alla separazione in diversi processi delle varie tab di navigazione. Il progetto, denominato Electrolysis, sembra tuttavia in stallo. Diviso in quattro fasi principali, l’avanzamento del progetto sembra fermo alla fase due, con termine dello sviluppo previsto per Aprile 2010. Inoltre, le quattro fasi prevedono la separazione in più processi delle varie tab, quindi una riorganizzazione completa dell’architettura interna del browser. Solo successivamente è prevista l’implementazione di una sandbox di sicurezza, progetto per il quale però non è stata ancora definita – o non è stata aggiunta pubblicamente -alcuna roadmap.

Tutti i giornali australiani stanno in queste ore riportando la notizia, sottolineando come oltre dodici mila persone siano già sul piede di guerra, pronti ad una class action che ha tutto il sapore di un’amara sconfitta per la multinazionale della telefonia mobile.

Alla base della fuga di dati è probabilmente qualche dealer al quale è stata sottratta la password di accesso al database – oppure è stata volutamente condivisa, questo sarà tutto da accertare.

Ciò che ha dell’incredibile è però come la società sembra gestisse i dati sensibili di tutti i suoi clienti. Tutti i dati sono registrati in un database liberamente raggiungibile da Internet, accessibile tramite un’autenticazione da una pagina web protetta. Un database, insomma, potenzialmente aperto a tutti.

Un database al quale potevano accedervi tutti gli impiegati autorizzati e i vari dealer tramite qualsiasi computer poiché non situato in una rete interna Vodafone, ma semplicemente interrogabile via una form web sicura.

Il Sunday Morning Herald riporta addirittura un particolare inquietante: alcuni dealer hanno rivelato come spesso venga chiesto di condividere i propri dati di accesso per qualche genere di favore.

E, a quanto sembra, tutti i dealer che vendono prodotti Vodafone ottengono la password di accesso al database. Con l’accesso completo è possibile avere visione di tutti i dati personali dei clienti, effettuare modifiche, visualizzare bollette telefoniche e molto altro.

Riuscire ad intercettare password nei PC è un gioco da ragazzi tramite malware, gli attacchi man-in-the-browser sono delle tipologie di attacchi che vediamo applicate quotidianamente. E il fatto che il database sia raggiungibile da qualsiasi PC tramite internet significa che lo stesso PC utilizzato dai vari dealer può collegarsi direttamente ad internet, una politica di sicurezza fortemente opinabile se il terminale è utilizzato per trattare dati sensibili e dati personali.

Tutto ciò sta avvenendo ora in Australia.

La domanda che rivolgo pubblicamente, da cliente Vodafone, alla Vodafone Italia e ai loro dealer è la seguente: i dati personali e sensibili dei clienti Vodafone dove sono situati? Sono accessibili da Internet tramite qualche pagina web? Hanno i vari dealer accesso a questi dati?

Vodafone Italia dovrebbe chiarire questi punti al più presto, o rischia purtroppo di rimanere anch’essa vittima dell’onda d’urto generata dal terremoto australiano.

Nell’articolo viene detto come in Italia le istituzioni utilizzino ancora chiavi crittgrafiche RSA 128/1024 bit quando in tutto il mondo si sono già aggiornati ad utilizzare le più recenti e sicure tecnologie a 256/2048 bit. Viene inoltre spiegato come per la Posta Elettronica Certificata vengano utilizzate chiavi a 128 bit, definendola una protezione inadeguata poiché in rete circolano già miriadi di istruzioni per violare le difese a 128 bit.

Premetto di non essere un esperto di crittografia e crittoanalisi. Detto ciò mi sembra che l’articolo, le cui idee in linea generale sono valide, faccia però nella pratica molta confusione, dipingendo una verità che non corrisponde esattamente alla realtà.

Tracciamo, molto semplicemente – non me ne vogliano gli esperti del settore, come viene stabilita una sessione crittografata durante una connessione web.

Nel momento in cui un client si connette al server è necessario stabilire una password condivisa da entrambi per poter iniziare la connessione crittografata. Per fare ciò entra in gioco la crittografia asimmetrica. Il server, che possiede una coppia di chiavi, invia al client la propria chiave pubblica e tiene segreta la propria chiave privata. Il client, ricevuta la chiave pubblica, genera la chiave precondivisa che verrà utilizzata per la connessione e la cripta con la chiave pubblica del server. Il server riceve il dato e lo decripta con la propria chiave privata. Da questo momento sia server che client hanno la stessa password e possono stabilire una connessione criptata con un algoritmo di crittografia simmetrica – solitamente AES, 3DES o RC4.

Cominciamo a distinguere dunque le due fasi, la comunicazione della chiave precondivisa generata dal client e l’inizio della comunicazione vera e propria.

Nella prima fase viene utilizzato un algoritmo di crittografia asimmetrica, denominato RSA. Grazie a questo algoritmo è possibile generare una coppia di chiavi legate matematicamente tra di loro, tali che un qualsiasi dato criptato con una delle due chiavi può essere decriptato dall’altra chiave.

La coppia di chiavi generata è solitamente nell’ordine dei 1024, 2048 o 4096 bit, cioè rispettivamente 128,256,512 byte. Lo standard attuale nei certificati SSL è 2048 bit, sebbene sino ad oggi siano stati utilizzati – e ancora lo sono – certificati a 1024 bit.

La seconda fase vede lo stabilirsi di una connessione criptata per mezzo di un sistema di crittografia simmetrica quale può essere AES, 3DES o RC4, con uno stream nell’ordine di 128, 168 o 256 bit.

Fatto questo breve – molto striminzito e impreciso – preambolo, è possibile passare ad analizzare il contenuto dell’articolo in questione.

Si parla inizialmente di un sistema che vede l’Italia arretrata, con un utilizzo di chiavi a 128/1024 bit, e fin qui ci può anche stare. A cosa si riferisce quel 128? Alla dimensione in byte della chiave? A meno che nell’articolo non lo voglia riferire allo stream di dati, che è cosa ben diversa, ma comunque plausibile – non è chiara la cosa.

Una coppia di chiavi RSA 1024 è considerata ancora piuttosto sicura, sebbene siano stati dimostrati alcuni attacchi teorici in grado di forzarle – attacchi difficilmente praticabili nell’ottica di un’utenza comune. L’RSA-1024, ad oggi, non è stato ancora fattorizzato. Chiaramente un RSA 2048 è di gran lunga più sicuro, raddoppiando la lunghezza della chiave.

L’articolo afferma che le Certification Authority utilizzano chiavi a 128 bit per la Posta Elettronica Certificata. Andando a vedere però sul sito web del governo dedicato alla Posta Elettronica Certificata, si può vedere come venga utilizzata una chiave RSA a 1024 bit e uno stream di crittografia simmetrica AES a 256 bit.

Differente la situazione se si verifica la pagina web dedicata alla Posta Elettronica Certificata di Poste Italiane e di Aruba, dove viene utilizzata una chiave RSA a 1024 bit e uno stream di crittografia simmetrica RC4_128 a 128 bit.

Quindi, a questo punto, penso che i 128 bit di cui parla l’articolo siano riferiti alla chiave della crittografia simmetrica. Teoria che è avvalorata poi da un video, pubblicato nell’articolo, e relativo alla facilità con cui viene individuata una password a 128 bit in una connessione WEP.

Perché viene inserito questo video? Cosa ha in comune la tecnologia di crittografia utilizzata nelle reti wireless con il sistema di crittografia utilizzato dai siti di Poste Italiane e Aruba? La risposta è: l’algoritmo di crittografia RC4.

Questo algoritmo è stato forzato più volte ed è considerato ad oggi insicuro, tuttavia c’è una precisazione da fare: l’implementazione dell’algoritmo RC4 nel protocollo WEP è diversa dall’implementazione dell’algoritmo RC4 nell’SSL.

Cito direttamente dal sito dell’RSA:

Those who are using the RC4-based WEP or WEP2 protocols to provide confidentiality of their 802.11 communications should consider these protocols to be “broken”, and to plan remedial actions as necessary to mitigate the attendant risks. Actions to be considered should include using encryption at higher protocol layers and upgrading to improved 802.11 standards when these become available.

In protocols such as WEP, it is often necessary to generate different RC4 keys from different messages (or packets) from a common base key. A method frequently suggested to obtain the keys is to add or concatenate a counter to the base key. The key-scheduling algorithm of RC4 has been widely recognized to be rather lightweight for this purpose, particularly when the initial few bytes of plaintext are easily predictable.

RSA Security has discouraged such key derivation methods, recommending instead that users consider strengthening the key scheduling algorithm by pre-processing the base key and any counter or initialization vector by passing them through a hash function such as MD5.

….

RC4 is most commonly used to protect Internet traffic using the SSL (Secure Sockets Layer) protocol. Indeed, this use of RC4 may make RC4 the most widely-used stream cipher in the world.
There are two reasons why the new attacks do not apply to RC4-based SSL. First, SSL generates the encryption keys it uses for RC4 by hashing (using both MD5 and SHA1), so that different sessions have unrelated keys. Second, SSL does not re-key RC4 for each packet, but uses the RC4 algorithm state from the end of one packet to begin encryption with the next packet.

Come è possibile vedere, l’utilizzo dell’RC4 a 128 bit per le sessioni SSL è ancora considerato sicuro grazie all’utilizzo degli algoritmi di hashing MD5 o SHA1, non esistono ad oggi attacchi conosciuti capaci di forzare questo sistema di crittografia.

Comunque sia esistono plugin per alcuni browser – vedi Firefox – capaci di forzare il browser stesso a non utilizzare l’algoritmo di cifratura RC4 e di passare ad un più solito AES, sia esso a 128 che a 256 bit. Entrambi considerati ad oggi sicuri – cito a riguardo un passaggio del famosissimo criptoanalista Bruce Schneier:

And for new applications I suggest that people don’t use AES-256. AES-128 provides more than enough security margin for the forseeable future. But if you’re already using AES-256, there’s no reason to change.

Mostrare quindi un video per dimostrare come sia semplice riuscire a recuperare una chiave a 128 bit è, in questo caso, fuorviante perché non si sta parlando della stessa implementazione dell’algoritmo.

Utilizzare certificati basati su chiave RSA a 1024 bit è ancora sicuro, gli attacchi dimostrati sono stati al momento solo teorici e non applicabili facilmente su larga scala. Inoltre, come detto precedentemente, l’RSA-1024 non è stato ancora fattorizzato. È altrettanto ovvio che utilizzare delle chiavi RSA a 2048 bit sia più sicuro, raddoppiando la lunghezza delle chiavi.

Utilizzare uno stream dati a 128 bit, sebbene a 256 bit sia chiaramente più sicuro per i motivi immediatamente sopra evidenziati, non è ad oggi un problema perché dipende prima di tutto dall’algoritmo utilizzato.

Inoltre, se proprio dobbiamo dire che noi italiani siamo pecoroni, bisogna ammettere che almeno siamo in buona compagnia:

Di esempi, andando avanti, ce ne possono essere veramente tanti. Il punto è un altro.

Avevo già detto in passato come il governo avrebbe potuto spendere qualche soldo in più e utilizzare almeno un certificato EV SSL per garantire ancor di più la sicurezza dei propri cittadini, e sono tutt’ora convinto che le cose possano essere fatte in maniera di gran lunga migliore.

È giusto però cercare di chiarire alcuni punti di un articolo che, a mio avviso, rischia altrimenti di fomentare ancor più i caldi animi dei cittadini in un clima sempre più arroventato.

La tecnologia corre, fa passi da gigante, e quello che oggi può essere considerato sicuro domani non lo sarà più. È più che giusto cercare oggi di fornire le soluzioni più sicure sul mercato. Ma non è esatto dire che le soluzioni implementate oggi si possano forzare nel giro di pochissimi minuti. Non almeno senza una serie di pre-condizioni necessarie e non facilmente replicabili.

Microsoft ha corretto alcuni dei proprio software che erano vulnerabili ad una specifica falla scoperta pubblicamente lo scorso Agosto, relativa ad un’errata gestione del caricamento in runtime delle librerie di sistema. Ho già parlato in passato di questa vulnerabilità e avevo già detto come, a mio avviso, non si trattasse di una vulnerabilità del sistema operativo quanto piuttosto di un errore di programmazione dei singoli software.

Finalmente Microsoft ha corretto la tanto discussa e ben conosciuta falla nel Task Scheduler di Windows utilizzata dal malware Stuxnet per ottenere i privilegi amministrativi nel sistema infetto. Con quest’ultimo update tutte le falle 0day utilizzate da Stuxnet sono state definitivamente chiuse.

L’exploit del Task Scheduler di Windows era conosciuto già da Settembre e un proof of concept era stato rilasciato pubblicamente lo scorso Novembre, permettendo ai malware writer di poterlo utilizzare nelle proprie creazioni per evadere dagli account limitati ed account protetti da UAC.

In un blog post di Microsoft, scritto il 9 Dicembre 2010, Mike Reavey del Microsoft Security Response Center ha scritto che non ci sono tracce di utilizzo di questo exploit da parte di altri malware ad eccezione di Stuxnet. Al contrario, tuttavia, nei nostri laboratori abbiamo dettagliate analisi che il rootkit TDL4 ha iniziato ad utilizzare questo specifico exploit sin dai primi giorni di Dicembre (link in inglese). Comunque sia, ora che l’exploit è stato chiuso, anche il rootkit TDL4 dovrà trovare qualche altra via per poter elevare i propri privilegi una volta arrivato nel PC da infettare.

Con questo massiccio aggiornamento di sicurezza Microsoft ha corretto molte falle che potevano essere sfruttate dai malware. È tutto dunque? Non proprio. Questo aggiornamento massiccio lascia ancora aperta la porta ad una falla di sicurezza che permette l’elevazione di privilegi, la stessa falla di cui avevo parlato nel blog della mia società il mese scorso, relativa ad uno stack overflow nel win32k.sys.

Se ciò è già pericoloso di suo, diventa molto più grave a causa di un rilascio pubblico dell’exploit che sfrutta questa falla. Probabilmente bisognerà aspettarsi qualche malware che sfrutterà questa falla molto presto. Ora che la falla presente nel task scheduler di Windows è stata corretta, questo exploit sarà probabilmente al centro dell’attenzione fino a quando Microsoft non rilascerà un aggiornamento specifico.

Guardando il TDL4 rootkit e il suo trend di sviluppo, è possibile immaginare che gli autori del rootkit useranno questo exploit molto presto, dando di nuovo la possibilità al rootkit di bypassare UAC ed account limitati al fine di infettare sia i sistemi a 32 che a 64 bit.

Gli utenti Prevx sono già protetti da questo nuovo exploit, così anche coloro che hanno semplicemente installato Prevx free senza una licenza. Per cui, in attesa di una patch da parte di Microsoft, perché non provare Prevx per un pò e stare al sicuro da questo exploit?

BOULDER, Colo., Nov. 1, 2010 /PRNewswire/ — Webroot, the first Internet security service company, today announced it has acquired Prevx, provider of the world’s most scalable and effective cloud-based anti-malware solutions. Webroot will integrate Prevx’s technology into its cloud security services to deliver the industry’s most effective online protection for consumers and businesses.

Webroot and Prevx share a common vision for revolutionizing what we believe is a market in need of dramatic change,” said Dick Williams, CEO at Webroot. “Security vendors have expected customers to buy, install, maintain, and then manage security products that simply cannot keep pace with today’s cybercriminals. Prevx is the leader in cloud-based antivirus protection and behavior-based malware detection, which block threats before they can ever reach a PC or corporate network. This technology, combined with Webroot’s innovations, customer service and support, will make it easy for consumers to stay protected online wherever they go, and easy for businesses to protect their employees and their networks.”

…

Comunicato stampa

Un novembre ricco di novità, direi. E se il buongiorno si vede dal mattino…

Durante la navigazione online si corre spesso il rischio di imbattersi in pagine web fittizie, codici confezionati ad hoc per poter sfruttare qualche falla presente nel browser o presente nei plugin installati nel browser.

Si può parlare dei plugin Java, o dei plugin QuickTime, ma sicuramente il ruolo principale lo gioca Flash, l’ormai onnipresente player di Adobe necessario per poter visualizzare correttamente molti siti web che utilizzano animazioni e presentazioni grafiche. Il plugin Flash è continuamente al centro di polemiche per il numero di falle riscontrate nel proprio codice, falle che hanno permesso – e che permettono – a numerosi exploit di infettare i PC degli ignari utenti.

Proprio per evitare questo, o almeno per tentare arginare il problema quanto piu possibile, è stato più volte ribadito come sia necessario che l’utente verifichi costantemente sia la presenza di aggiornamenti del sistema operativo che dei software e plugin installati nel sistema.

I browser web Internet Explorer, Mozilla Firefox, Opera non vengono forniti di default di un plugin Flash, lasciando il compito dell’installazione all’utente. Seguendo la procedura di installazione fornita da Adobe, insieme al plugin viene solitamente installato un gestore di aggiornamenti che avvisa l’utente della presenza di eventuali nuovi aggiornamenti del plugin stesso. Discorso a parte va fatto per Google Chrome, il quale implementa al suo interno un plugin Flash scritto appositamente per poter girare all’interno della Chrome sandbox e che viene aggiornato costantemente da Google stessa.

Tutto questo parlando di Windows. Cosa succede invece su OS X, ad esempio sulla release OS X 10.6.4 Snow Leopard? Chi utilizza questo sistema operativo spesso ne sostiene la sicurezza globale, così come esce di fabbrica. Purtroppo questo è un modo sbagliato di approcciarsi al problema e ne avevo parlato già in passato in alcuni articoli.

Snow Leopard esce di fabbrica con un plugin Flash già integrato in Safari, per rendere la vita molto più semplice ai propri utilizzatori, i quali si troveranno già i siti web funzionanti senza necessità di installare nulla.

Si tratta veramente di un vantaggio? Proprio perché tutto tranquillamente funzionante, sono pochi gli utenti OS X che si preoccupano di aggiornare il proprio plugin Flash. E né Safari, né Snow Leopard, includono una gestione degli aggiornamenti del plugin di Flash.

Di fatto, la maggior parte degli utenti si preoccupa di installare gli aggiornamenti del sistema operativo tramite il sistema di Aggiornamento Software incluso in OS X. Procedura giustissima, sia chiaro, ma incompleta.

Allo stato attuale molti utilizzatori di Snow Leopard si trovano probabilmente con una versione di gran lunga obsoleta del plugin Flash, la 10.0.45.2, che è quella installata di default nell’ultimo aggiornamento di Snow Leopard 10.6.4. La versione corrente invece è la 10.1.85.3.

Si è parlato molto, ad esempio, dell’ultima falla 0day scoperta in Flash (WebNews). I fari sono stati puntati su Windows. Sono pochi però coloro che si focalizzano sul fatto che OS X, di default, utilizza una versione del plugin Flash vecchia di quasi un anno. Senza che l’utente se ne accorga – a meno che non sia un utente smaliziato, che va a controllare da solo spontaneamente la versione del plugin Flash utilizzata da Safari ed effettua, sempre manualmente, un eventuale update.

Si tratta di un problema? Purtroppo sì, visto che Flash è uno dei vettori principali di infezioni in Windows e, come tale, può tranquillamente diventarlo anche in OS X. Anzi, è ancor più un problema poiché – mentre Safari è un processo nativo a 64 bit – il plugin di Flash in Safari è un processo a 32 bit e, come tale, soffre di molte falle che rendono la vita veramente facile a possibili pirati informatici.

Purtroppo, in questo caso, non vengono in aiuto né il DEP integrato in Snow Leopard per la prevenzione di esecuzione di codice da stack e heap, né tantomeno l’ASLR per la randomizzazione degli indirizzi in memoria.

È stato dimostrato più volte come sia possibile superare in OS X il blocco imposto dal DEP, grazie ad un ASLR acerbo, di molto lontano dalla più completa e funzionale implementazione della stessa tecnologia in Windows Vista e 7.

L’Address Space Layout Randomization implementato in Snow Leopard, infatti, non randomizza né heap né stack, né tantomeno randomizza l’indirizzo in memoria del dynamic link loader (dyld), componente fondamentale per l’esecuzione dei processi, il quale viene caricato sempre all’indirizzo 0x8fe00000. Il dynamic link loader contiene al suo interno implementazioni delle funzioni principali, trattandosi di un processo standalone che non può dipendere da nient’altro. Conoscerne dunque il base address significa avere accesso a funzioni vitali per un eventuale exploit, quali ad esempio memcpy.

Conoscere a priori gli indirizzi di memoria fondamentali può permettere ad un potenziale pirata informatico di utilizzare attacchi basati su ROP – Return Oriented Programming – al fine di annullare la protezione messa in atto dalla tecnologia DEP.

Ecco che, dunque, diventa importante controllare non solo gli aggiornamenti del sistema operativo, ma anche di tutti i software installati in esso. E, nel caso del plugin Flash, si tratta di una cosa da fare con la massima urgenza, vista la possibile gravità nel lasciare il plugin non aggiornato. E gli utenti di Windows lo sanno bene cosa significhi avere un plugin Flash non aggiornato.

Per verificare quale versione del plugin Flash sia installata è possibile collegarsi a questa pagina. Eventualmente, per aggiornare il plugin, è necessario collegarsi a questa pagina.

Non importa utilizzare Windows o utilizzare OS X, ciò che è veramente necessario è tenere sempre sotto controllo ciò che è installato nel proprio PC e fare sempre attenzione a ciò che si fa. D’altronde, come è stato già detto da Charlie Miller, OS X è “safer, but less secure“.

Come avvenne la scoperta? Purtroppo nel peggiore dei casi, di fronte all’ormai avvenuta diffusione: un malware isolato dalla società di sicurezza informatica russa VirusBlokAda Ltd. stava utilizzando questa falla per infettare dispositivi USB rimovibili ed auto eseguirsi non appena il dispositivo infetto veniva collegato ad un sistema operativo Windows. La società informò Microsoft e allertò le altre società di sicurezza. Cercando meglio nella mole di dati che arrivano ogni giorno nei database delle varie società di antivirus, si è scoperto che questo malware, successivamente denominato Stuxnet, aveva già almeno un’altra variante. Entrambe le varianti di Stuxnet erano firmate digitalmente. O, per meglio precisare, coloro che avevano scritto Stuxnet erano riusciti a rubare certificati digitali appartenenti a Realtek e JMicron. Certificati che sono stati poi utilizzati per firmare i malware.

Ad un’analisi più tecnica del malware venne fuori che il codice nocivo attaccava sistemi Windows nei quali erano installati i prodotti Simatic WinCC e PCS 7, soluzioni Siemens per sistemi SCADA (controllo di supervisione e acquisizione dati) utilizzati al fine di monitoraggio elettronico di sistemi industriali. Un perfetto caso di spionaggio industriale, visto che il malware era in grado di penetrare i database del software Siemens installato e rubare informazioni segrete, quali ad esempio file di progetti.

Gli elementi che si avevano in mano due mesi fa erano, dunque, i seguenti: una vulnerabilità 0day in Windows, due certificati digitali rubati a terze aziende, una piattaforma industriale presa di mira, una conoscenza approfondita di tali software Siemens. Infatti, riguardo quest’ultimo punto, bisogna specificare che il malware era in possesso di una password “universale” per entrare nei database del software Siemens.

Decisamente troppi elementi per pensare che si trattasse di un attacco partito da un pirata informatico annoiato. L’odore di spionaggio industriale è nell’aria.

Torniamo però ai giorni nostri visto che, dopo due mesi di ulteriori indagini, sono venute fuori altre informazioni che ci permettono di fantasticare ancora un po. Microsoft ci informa che, analizzando attentamente il codice di Stuxnet, sono venute fuori sorprese ben più sgradite di quelle che fossero arrivate fino ad ora.

Stuxnet non ha utilizzato solo una falla 0day. Stuxnet utilizza per diffondersi un totale di quattro falle 0day, falle fino ad ora sconosciute. La prima, l’ormai famosa falla di Windows nella visualizzazione dei file collegamento – MS10-046. La seconda, MS10-061, è stata corretta con gli ultimi aggiornamenti di Settembre rilasciati da Microsoft. Il problema risiede nello spooler di stampa, il quale in determinate situazioni potrebbe permettere l’esecuzione di codice da remoto. Altre due falle 0day sono tutt’ora sconosciute, o meglio conosciute solo da Microsoft e ricercatori di terze parti che hanno analizzato il codice di Stuxnet. Queste due falle 0day sono falle EoP (Elevation of Privileges), cioè utilizzate per elevare i privilegi di un eventuale malware all’interno del sistema infetto.

In aggiunta a tutto ciò, Stuxnet utilizza anche l’ormai vetusta falla MS08-067, già utilizzata dal malware Conficker per diffondersi nelle aziende. Falla che, ovviamente, è stata già corretta da Microsoft da tempo.

Ancora: chi ha progettato Stuxnet ha anche un’ottima conoscenza del linguaggio di programmazione AWL di Siemens, linguaggio utilizzato per la programmazione di PLC S7. Infatti, nel codice del malware, è stato scoperto che una routine è dedicata appositamente ad iniettare codice nei PLC controllati dai sistemi SCADA infetti. In altre parole, Stuxnet è in grado di manipolare il codice che viene inviato dal sistema SCADA ai PLC, inserendo anche un rootkit specifico nel PLC capace di nascondere il codice alterato.

Infine, secondo statistiche rilasciate da Symantec, l’Iran è il paese più colpito da questo malware.

Ora è possibile rifare il punto della situazione sul caso Stuxnet:

Se prima l’idea era che si trattasse non di un semplice malware ma di un caso di spionaggio industriale, ora l’idea di spionaggio e sabotaggio industriale è sempre più forte e reale. Il team alle spalle di Stuxnet è un team altamente specializzato, che ha conoscenze specifiche sia di Windows e delle soluzioni Siemens, sia della vittima a cui il malware era destinato.

Ma chi può aver bisogno di fare ciò e chi potrebbe essere la vittima? Per chi ha letto fino ad ora, le idee potrebbero essere già chiare, ma forse è il caso di aggiungere altri particolari.

Siemens ha dichiarato a Gennaio 2010 di voler interrompere qualsiasi vendita di prodotti ordinati dall’Iran a causa della sospetta attività nucleare. Tuttavia, Siemens e Iran hanno da lungo tempo rapporti commerciali, tant’è che tutti gli ordini effettuati dall’Iran a Siemens prima del 2010 verranno comunque gestiti. Nel 1975 Siemens si era impegnata nella costruzione di una centrale nucleare vicino la città iraniana di Bushehr. Contratto poi interrotto nel 1979. Tuttavia, lo stesso progetto fu poi ripreso nel 1995 dalla Russia, che si impegnò nella costruzione della centrale. Progetto che è tuttora in fase di sviluppo, progetto chiaramente scomodo e mal visto da molti paesi, tra i quali Israele.

Israele che, da tempo, sta tenendo sotto controllo l’Iran anche sotto il punto di vista della sicurezza informatica, per possibili cyberwar. Guerre virtuali che sono tutt’altro che una mera ipotesi. Un articolo scritto da Reuters nel 2009 riportava proprio tale possibile ipotesi, un sabotaggio informatico da parte di Israele nei confronti dell’Iran. Citando l’articolo:

“To judge by my interaction with Israeli experts in various international forums, Israel can definitely be assumed to have advanced cyber-attack capabilities,” said Scott Borg, director of the U.S. Cyber Consequences Unit, which advises various Washington agencies on cyber security.
….
Asked to speculate about how Israel might target Iran, Borg said malware – a commonly used abbreviation for “malicious software” — could be inserted to corrupt, commandeer or crash the controls of sensitive sites like uranium enrichment plants
….
As Iran’s nuclear assets would probably be isolated from outside computers, hackers would be unable to access them directly, Borg said. Israeli agents would have to conceal the malware in software used by the Iranians or discreetly plant it on portable hardware brought in, unknowingly, by technicians.

“A contaminated USB stick would be enough,” Borg said.

A contaminated USB stick would be enough. La stessa “chiavetta” con cui Stuxnet ha iniziato la propria diffusione. Probabilmente la stessa chiavetta che l’ha tradito e l’ha portato alla luce.

Fanta-politica? Idee distanti dalla realtà?

La verità è che l’informatica fa parte del mondo di oggi, anzi è uno strumento diventato fondamentale, necessario per l’evolversi stesso della società. A causa di questo ruolo cruciale, tuttavia, la stessa informatica è diventata il campo di battaglia preferito. Un campo di battaglia dove non esistono regole, dove le leggi attuali stentano ad arrivare. Un campo di battaglia, però, che può diventare letale per un’intera nazione.

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.