Il difetto nel cuore di Internet

Dan Kaminsky, insolitamente, non era alla ricerca di bug all'inizio di quest'anno quando si è imbattuto in un difetto al centro di Internet. Il ricercatore di sicurezza stava usando la sua conoscenza dell'infrastruttura Internet per trovare un modo migliore per trasmettere i video agli utenti. L'esperienza di Kaminsky è nel sistema dei nomi di dominio di Internet (DNS), il protocollo responsabile della corrispondenza degli URL dei siti Web con gli indirizzi numerici dei server che li ospitano. Lo stesso contenuto può essere ospitato da più server con diversi indirizzi e Kaminsky ha pensato di avere un ottimo trucco per indirizzare gli utenti ai server più in grado di gestire le loro richieste in un dato momento.

Vedere i problemi: Il ricercatore di sicurezza Dan Kaminsky ha individuato per la prima volta una vulnerabilità di base in Internet lo scorso inverno.

Normalmente, il DNS è affidabile ma non agile. Quando un computer, ad esempio un server che aiuta a dirigere il traffico attraverso la rete di Comcast, richiede l'indirizzo numerico associato a un determinato URL, memorizza la risposta per un periodo di tempo noto come tempo di vita, che può variare da secondi a giorni. Questo aiuta a ridurre il numero di richieste che il server fa. L'idea di Kaminsky era di bypassare il tempo per vivere, consentendo al server di ottenere una nuova risposta ogni volta che voleva conoscere l'indirizzo di un sito. Di conseguenza, il traffico sulla rete di Comcast verrebbe inviato in ogni momento all'indirizzo ottimale, anziché a qualsiasi indirizzo già memorizzato. Kaminsky era sicuro che la strategia avrebbe potuto accelerare significativamente la distribuzione dei contenuti.

Fu solo in seguito, dopo aver parlato casualmente dell'idea con un amico, che Kaminsky si rese conto che il suo trucco poteva infrangere completamente la sicurezza del sistema dei nomi di dominio e, quindi, di Internet stessa. Il tempo per vivere, si scopre, era al centro della sicurezza DNS; essere in grado di aggirarlo consentiva un'ampia varietà di attacchi. Kaminsky ha scritto un piccolo codice per assicurarsi che la situazione fosse così grave come pensava che fosse. Una volta che l'ho visto funzionare, il mio stomaco è caduto, dice. Ho pensato: 'Cosa diavolo farò a riguardo? Questo influisce su tutto.'

La tecnica di Kaminsky potrebbe essere utilizzata per indirizzare i navigatori del Web a qualsiasi pagina Web scelta da un utente malintenzionato. L'uso più ovvio consiste nell'indirizzare le persone a siti di phishing (siti Web progettati per indurre le persone a inserire password bancarie e altre informazioni personali, consentendo a un utente malintenzionato di rubare le loro identità) o altre versioni false di pagine Web. Ma il pericolo è ancora peggiore: protocolli come quelli utilizzati per recapitare la posta elettronica o per comunicazioni sicure su Internet si basano in ultima analisi sul DNS. Un aggressore creativo potrebbe utilizzare la tecnica di Kaminsky per intercettare e-mail sensibili o per creare versioni contraffatte dei certificati che garantiscono transazioni sicure tra utenti e siti Web bancari. Ogni giorno trovo un altro domino, dice Kaminsky. Un'altra cosa cade se il DNS è cattivo. … Voglio dire, letteralmente, ti guardi intorno e vedi tutto ciò che utilizza una rete, tutto ciò che utilizza una rete e probabilmente utilizza DNS.

Multimedia

• Visualizza uno schema di un attacco di avvelenamento da cache.

Kaminsky ha chiamato Paul Vixie, presidente dell'Internet Systems Consortium, una società senza scopo di lucro che supporta diversi aspetti dell'infrastruttura Internet, incluso il software più comunemente utilizzato nel sistema dei nomi di dominio. Di solito, se qualcuno vuole segnalare un problema, ti aspetti che ci vorrà un bel po' di tempo per spiegarlo, forse una lavagna, forse un documento Word o due, dice Vixie. In questo caso, gli ci sono voluti 20 secondi per spiegare il problema e altri 20 secondi per rispondere alle mie obiezioni. Dopodiché, ho detto: 'Dan, ti sto parlando con un cellulare non sicuro. Per favore, non dire mai più a nessuno quello che mi hai appena detto su un cellulare non sicuro.'

Forse la cosa più spaventosa era che, poiché la vulnerabilità non si trovava in alcun hardware o software in particolare, ma nella progettazione del protocollo DNS stesso, non era chiaro come risolverla. In segreto, Kaminsky e Vixie hanno riunito alcuni dei migliori esperti DNS al mondo: persone del governo degli Stati Uniti e ingegneri di alto livello dei principali produttori di software e hardware DNS, tra cui Cisco e Microsoft. Hanno organizzato un incontro a marzo presso il campus di Microsoft a Redmond, WA. Gli accordi erano così segreti e frettolosi, dice Kaminsky, che c'erano persone sui jet di Microsoft che non sapevano nemmeno quale fosse il bug.

Una volta a Redmond, il gruppo ha cercato di determinare l'entità del difetto e di individuare una possibile soluzione. Hanno optato per una misura provvisoria che risolveva la maggior parte dei problemi, sarebbe stata relativamente facile da implementare e avrebbe mascherato l'esatta natura del difetto. Poiché gli aggressori identificano comunemente le falle di sicurezza mediante il reverse engineering di patch destinate a risolverle, il gruppo ha deciso che tutti i suoi membri dovevano rilasciare la patch contemporaneamente (la data di rilascio sarebbe stata l'8 luglio). Kaminsky ha anche chiesto ai ricercatori di sicurezza di non speculare pubblicamente sui dettagli del difetto per 30 giorni dopo il rilascio della patch, nel tentativo di dare alle aziende abbastanza tempo per proteggere i propri server.

Il 6 agosto, alla conferenza Black Hat, il raduno annuale degli esperti mondiali di sicurezza Internet, Kaminsky avrebbe rivelato pubblicamente quale fosse la falla e come potesse essere sfruttata.

In cerca di guai
Kaminsky non ha davvero scoperto un nuovo attacco. Invece, ha trovato un modo ingegnoso per dare vita a uno molto antico. In effetti, il difetto di base preso di mira dal suo attacco è anteriore a Internet stesso.

La fondazione del DNS è stata posta nel 1983 da Paul Mockapetris, allora alla University of Southern California, ai tempi di ARPAnet, il progetto di ricerca del Dipartimento della Difesa degli Stati Uniti che collegava i computer di un piccolo numero di università e istituti di ricerca e alla fine ha portato a Internet . Il sistema è progettato per funzionare come il servizio 411 di una compagnia telefonica: dato un nome, cerca i numeri che porteranno al portatore di quel nome. Il DNS è diventato necessario quando ARPAnet è cresciuto oltre la capacità di un individuo di tenere traccia degli indirizzi numerici nella rete. Mockapetris, che ora è presidente e capo scienziato di Nominum, un fornitore di software per infrastrutture con sede a Redwood, in California, ha progettato il DNS come una gerarchia. Quando qualcuno digita l'URL di una pagina Web in un browser o fa clic su un collegamento ipertestuale, una richiesta viene inviata a un server dei nomi gestito dal provider di servizi Internet (ISP) dell'utente. Il server dell'ISP memorizza gli indirizzi numerici degli URL che gestisce di frequente, almeno fino alla scadenza del loro tempo di vita. Ma se non riesce a trovare un indirizzo, interroga uno dei 13 root server DNS, che indirizza la richiesta a un name server responsabile di uno dei domini di primo livello, come .com o .edu. Quel server inoltra la richiesta a un server specifico per un singolo nome di dominio, come google.com o mit.edu. L'inoltro continua attraverso server con responsabilità sempre più specifiche –mail.google.com, o library.mit.edu– fino a quando la richiesta raggiunge un server che può fornire l'indirizzo numerico richiesto o rispondere che tale indirizzo non esiste. Man mano che Internet maturava, divenne chiaro che il DNS non era abbastanza sicuro. Il processo di trasferimento di una richiesta da un server all'altro offre agli aggressori molte opportunità di intervenire con risposte false e il sistema non disponeva di alcuna protezione per garantire che il server dei nomi che rispondeva a una richiesta fosse affidabile. Già nel 1989, afferma Mockapetris, c'erano casi di avvelenamento della cache, in cui un server dei nomi veniva indotto con l'inganno a memorizzare informazioni false sull'indirizzo numerico associato a un sito web.
Negli anni '90, il lavoro dell'avvelenatore era relativamente facile. I server dei nomi di livello inferiore sono generalmente gestiti da entità private: Amazon, ad esempio, controlla gli indirizzi forniti dal server dei nomi amazon.com. Se un server dei nomi di basso livello non riesce a trovare un indirizzo richiesto, indirizzerà il richiedente a un altro server dei nomi o dirà al richiedente che la pagina non esiste. Ma negli anni '90, il server di basso livello poteva anche fornire al richiedente l'indirizzo del server di livello superiore. Per avvelenare una cache, un utente malintenzionato doveva semplicemente falsificare quell'informazione. Se un utente malintenzionato ha ingannato, ad esempio, il server dei nomi di un ISP per memorizzare l'indirizzo sbagliato per il server .com, potrebbe dirottare la maggior parte del traffico che viaggia sulla rete dell'ISP. Mockapetris afferma che diverse funzionalità sono state successivamente aggiunte al DNS per proteggere il sistema. I server richiedenti hanno smesso di accettare indirizzi numerici di livello superiore da server di nomi di livello inferiore. Ma gli aggressori hanno trovato un modo per aggirare questa restrizione. Come prima, rimandano un richiedente, ad esempio, al server .com. Ma ora il richiedente doveva cercare da solo l'indirizzo del server .com. Richiederebbe l'indirizzo e l'attaccante si affretterebbe a rispondere con una risposta falsa prima che arrivasse la risposta vera. Anche contro questa strategia sono state aggiunte misure di sicurezza ad hoc. Ora, ogni richiesta a un server DNS porta un ID di transazione generato casualmente, uno dei 65.000 numeri possibili, che deve contenere anche la risposta. Un utente malintenzionato che corre per battere una risposta legittima dovrebbe anche indovinare l'ID della transazione corretto. Sfortunatamente, un computer può generare così tante false risposte così rapidamente che se ha abbastanza possibilità, è destinato a trovare l'ID corretto. Quindi il tempo per vivere, originariamente inteso per evitare che i server dei nomi venissero sovraccaricati da troppe richieste, è diventato un'altra caratteristica di sicurezza temporanea. Poiché il server richiedente memorizzerà una risposta per un certo periodo di tempo, l'attaccante ha solo poche possibilità di tentare una contraffazione. La maggior parte delle volte, quando il server ha bisogno di un indirizzo .com, consulta la sua cache invece di controllare con il server .com. Kaminsky ha trovato un modo per aggirare queste funzionalità di sicurezza ad hoc, la cosa più importante, il tempo da vivere. Ciò ha reso il sistema vulnerabile tanto quanto lo era quando è stato scoperto per la prima volta l'avvelenamento della cache. Usando la tecnica di Kaminsky, un attaccante ha un numero quasi infinito di possibilità di fornire un falso. Supponiamo che un utente malintenzionato voglia dirottare tutta la posta elettronica che un sito di social network come Facebook o MySpace invia agli account Gmail. Registra un account con il social network e quando gli viene richiesto un indirizzo e-mail, ne fornisce uno che punta a un dominio che controlla. Inizia ad accedere al social network ma afferma di aver dimenticato la password. Quando il sistema tenta di inviare una nuova password, esegue una ricerca DNS che conduce al dominio dell'attaccante. Ma il server dell'attaccante afferma che l'indirizzo richiesto non è valido. A questo punto, l'attaccante potrebbe indirizzare il richiedente ai server dei nomi di google.com e correre a fornire una risposta contraffatta. Ma poi avrebbe avuto solo una possibilità di decifrare l'ID della transazione. Quindi, invece, indirizza il richiedente ai domini inesistenti 1.google.com, quindi 2.google.com, quindi 3.google.com e così via, inviando una marea di risposte fasulle per ciascuno. Ogni volta, il server richiedente consulterà i server dei nomi di Google anziché la sua cache, poiché non avrà indirizzi memorizzati per nessuno degli URL fasulli. L'attacco scavalca completamente i limiti imposti dal tempo di vivere. Uno dei falsi dell'attaccante è destinato a passare. Quindi è semplice indirizzare tutto ciò che il server richiedente intende per Google ai server dell'attaccante, poiché l'attaccante sembra avere l'autorità per gli URL che terminano con google.com. Kaminsky afferma di essere stato in grado di eseguire attacchi di prova in appena 10 secondi.

Un attacco di avvelenamento da cache
L'avvelenamento della cache fa sì che un server richiedente memorizzi informazioni false sull'indirizzo numerico associato a un sito web. Una versione base dell'attacco, senza alcune delle tecniche più sofisticate impiegate da Kaminsky, è descritta di seguito. 1. Per iniziare, l'aggressore induce il server della vittima a contattare un dominio controllato dall'aggressore. L'aggressore potrebbe, ad esempio, affermare di aver dimenticato una password, spingendo la vittima a rispondere tramite e-mail.
2. La vittima esegue una ricerca DNS per scoprire dove inviare l'e-mail. Ma il server dei nomi dell'attaccante rimanda la vittima a un altro server, come quello di example.com. Poiché l'attaccante sa che la vittima ora avvierà una ricerca DNS per quel server, ha l'opportunità di tentare di avvelenare la sua cache. 3. L'attaccante cerca di fornire una risposta falsa prima che il server legittimo possa fornire quella reale. Se l'attaccante indovina il numero ID corretto, la vittima accetta la risposta indovinata, che avvelena la cache.
Nell'oscurità
L'8 luglio, Kaminsky ha tenuto la conferenza stampa promessa, annunciando il rilascio della patch e chiedendo ad altri ricercatori di non speculare sul difetto. I fornitori di hardware e software hanno optato per una patch che obbliga un utente malintenzionato a indovinare un ID di transazione più lungo. Kaminsky dice che prima della patch, l'attaccante ha dovuto fare decine di migliaia di tentativi per avvelenare con successo una cache. Dopo la patch, avrebbe dovuto guadagnare miliardi. La notizia del difetto è apparsa sul New York Times, sul sito web della BBC e in quasi tutte le pubblicazioni tecniche. Gli amministratori di sistema si sono dati da fare per far funzionare la patch nei loro sistemi prima che potessero essere attaccati. Ma poiché Kaminsky non è riuscito a fornire i dettagli del difetto, alcuni membri della comunità della sicurezza erano scettici. Thomas Ptacek, un ricercatore di Matasano Security, ha postato su Twitter: Dirlo prima qui: dubitare che ci sia davvero carne in questo annuncio di sicurezza DNS. Dino Dai Zovi, un ricercatore di sicurezza noto per aver trovato modi per fornire malware a un Macbook Pro completamente aggiornato, afferma: Ero decisamente scettico sulla natura della vulnerabilità, soprattutto a causa della quantità di clamore e attenzione rispetto alla bassa quantità di dettagli . Ogni volta che vedo qualcosa del genere, indosso immediatamente il mio cappello scettico, perché assomiglia molto a qualcuno con un interesse acquisito piuttosto che a qualcuno che cerca di sistemare qualcosa. Dai Zovi e altri hanno notato che il tempismo era perfetto per promuovere l'aspetto di Black Hat di Kaminsky, e si sono irritati alla richiesta di astenersi dalle speculazioni. La mancanza di informazioni è stata particolarmente controversa perché gli amministratori di sistema sono spesso responsabili della valutazione delle patch e della decisione se applicarle, soppesando il pericolo della falla di sicurezza rispetto all'interruzione che la patch causerà. Poiché il DNS è fondamentale per il funzionamento di qualsiasi organizzazione dipendente da Internet, modificarlo non è qualcosa da fare alla leggera. A peggiorare le cose, questa patch non funzionava correttamente con alcuni tipi di firewall aziendali. Molti professionisti IT hanno espresso frustrazione per la mancanza di dettagli, affermando di non essere stati in grado di valutare adeguatamente la patch quando così tanto è rimasto nascosto. Preoccupato dallo scetticismo sulle sue affermazioni, Kaminsky tenne una teleconferenza con Ptacek e Dai Zovi, sperando di far loro vedere quanto fosse pericoloso l'insetto. Entrambi sono usciti dalla chiamata convertiti. Ma anche se Dai Zovi nota che molto è cambiato dal momento in cui i produttori di hardware e software hanno affrontato i difetti semplicemente negando che i ricercatori della sicurezza avessero identificato problemi reali, dice anche: Non sappiamo cosa fare quando le vulnerabilità sono davvero grandi sistemi come DNS. I ricercatori devono affrontare un dilemma, dice: devono spiegare i difetti per convincere gli altri della loro gravità, ma una vulnerabilità come quella trovata da Kaminsky è così grave che rivelarne i dettagli potrebbe mettere in pericolo il pubblico. Halvar Flake, un ricercatore di sicurezza tedesco, era un osservatore che pensava che tacere fosse l'alternativa più dannosa. La speculazione pubblica è proprio ciò che serve, dice, per aiutare le persone a capire cosa potrebbe colpirle. Flake ha letto alcuni materiali di base, inclusa la voce di Wikipedia tedesca sul DNS, e ha scritto un articolo sul blog su ciò che pensava che Kaminsky potesse aver trovato. Dichiarando che la sua ipotesi era probabilmente sbagliata, invitò altri ricercatori a correggerlo. In qualche modo, tra il trambusto causato dal suo post nella comunità della sicurezza, una spiegazione dettagliata del difetto è apparsa su un sito ospitato dal datore di lavoro di Ptacek, Matasano Security. La spiegazione è stata rapidamente rimossa, ma non prima di aver proliferato su Internet. Seguì il caos. Kaminsky ha postato su Twitter, il bug DNS è pubblico. Devi applicare la patch o passare a OpenDNS [basato sul Web], PROPRIO ORA. In pochi giorni, Metasploit, un progetto di sicurezza informatica che progetta attacchi campione per aiutare nei test, ha rilasciato due moduli che sfruttano il difetto di Kaminsky. Poco dopo, uno dei primi attacchi basati sulla falla DNS è stato visto in natura. Ha preso il controllo di alcuni dei server di AT&T per presentare una falsa home page di Google, caricata con gli annunci dell'attaccante. Fuori i cookie
Trenta minuti prima che Kaminsky salisse sul palco del Black Hat per rivelare finalmente i dettagli del difetto, la gente iniziò ad inondare la sala da ballo del Caesar's Palace a Las Vegas. L'oratore che precedeva Kaminsky si affrettò a concludere. I posti si esaurirono e la gente sedeva a gambe incrociate su ogni centimetro quadrato di moquette. La nonna di Kaminsky, che era seduta in prima fila, aveva preparato 250 biscotti per l'evento. Non ce n'erano abbastanza. Kaminsky salì sul podio. C'è un sacco di gente là fuori, ha detto. Santo schifo. Kaminsky è alto e i suoi gesti sono un po' goffi. All'inizio di agosto, ha affermato, oltre 120 milioni di clienti a banda larga sono stati protetti, poiché i fornitori di servizi Internet hanno applicato le patch. Il settanta percento delle aziende Fortune 500 aveva patchato i propri sistemi e un ulteriore 15 percento ci stava lavorando. Tuttavia, ha aggiunto, dal 30 al 40 percento dei server dei nomi su Internet erano ancora privi di patch e vulnerabili al suo attacco di avvelenamento della cache di 10 secondi. Sul palco, ha oscillato tra la gioiosa descrizione delle possibilità oscure della sua scoperta e i tentativi di radunare la serietà appropriata alla loro gravità. Ha parlato per 75 minuti, diventando visibilmente più leggero mentre si liberava dei segreti di sette mesi. Alla fine del suo discorso, la folla si è avvicinata a lui ed è stato portato via da un giornalista dopo l'altro. Persino quegli esperti di sicurezza che concordavano sul fatto che la vulnerabilità fosse grave sono rimasti sorpresi dall'entusiasmo di Kaminsky per l'attenzione dei media e dal suo incessante sforzo di pubblicizzare il difetto. Più tardi quel giorno, Kaminsky ha ricevuto il premio Pwnie per il bug più pubblicizzato da un gruppo di ricercatori di sicurezza. (La parola pwn, che fa rima con proprio, è lo slang di Internet per dominare completamente. Il premio di Kaminsky è sottotitolato The Pwnie per pedinare i media.) Dai Zovi, presentando il premio, ha cercato di elencare le pubblicazioni che avevano portato la storia di Kaminsky. Ha rinunciato, dicendo: Cosa? non eri in?GQ! gridò qualcuno dal pubblico. Kaminsky salì sul palco e sputò due frasi: Alcune persone trovano degli insetti; alcune persone ottengono bug corretti. Sono felice di essere nella seconda categoria. Facendo oscillare il premio - un pony giocattolo d'oro - per i suoi capelli rosa brillante, percorse il lungo corridoio della sala da ballo e uscì dalla porta. Chi è il responsabile?
A seconda della tua prospettiva, il modo in cui Kaminsky ha gestito il difetto DNS e la sua patch è stato un pericoloso clamore che ha inutilmente richiamato l'attenzione del pubblico sulla vulnerabilità di Internet o, come lo vede Kaminsky, un hack multimediale necessario per attirare i riflettori sui pericoli del bug. In entrambi i casi, la storia indica la preoccupante assenza di qualsiasi processo per identificare e correggere i difetti critici in Internet. Poiché Internet è così decentralizzato, semplicemente non esiste una persona o un'organizzazione specifica incaricata di risolvere i suoi problemi. E sebbene il difetto di Kaminsky sia particolarmente grave, gli esperti dicono che probabilmente non è l'unico nell'infrastruttura di Internet. Molti protocolli Internet non sono stati progettati per gli usi a cui sono oggi destinati; molte delle sue funzionalità di sicurezza sono state attaccate e non affrontano le vulnerabilità sottostanti. A lungo termine, dal punto di vista architettonico, dobbiamo smettere di presumere che la rete sia amichevole com'è, dice Kaminsky. Siamo solo dipendenti dal trasferire informazioni sensibili su Internet in modo non sicuro. Possiamo fare di meglio. In effetti, in un'altra conferenza sulla sicurezza, pochi giorni dopo la presentazione di Kaminsky al Black Hat, un team di ricercatori ha tenuto un discorso illustrando gravi difetti nel protocollo di routing del gateway di confine di Internet. Come Kaminsky, i ricercatori avevano riscontrato problemi con la progettazione fondamentale di un protocollo Internet. Come il difetto DNS, il problema potrebbe consentire a un utente malintenzionato di ottenere un ampio accesso al traffico sensibile inviato su Internet.
Molti esperti affermano che ciò che è successo con il difetto DNS rappresenta lo scenario migliore. Mischel Kwon, direttore di US-CERT, una divisione del Department of Homeland Security che ha contribuito a far conoscere il bug DNS, spera che la rete di organizzazioni che hanno lavorato insieme in questo caso faccia lo stesso se emergono altri difetti. Sebbene non ci sia una gerarchia di autorità nel settore privato, afferma Kwon, ci sono forti connessioni tra aziende e organizzazioni con il potere di distribuire patch. Dice di essere sicura che, considerando i soldi e gli sforzi profusi per migliorare la sicurezza su Internet, i protocolli obsoleti verranno aggiornati. Ma quella fiducia non è fondata su una strategia ben ponderata. E se Kaminsky non avesse avuto ampie connessioni all'interno della comunità della sicurezza o, peggio, non si fosse impegnato a correggere il difetto in primo luogo? E se fosse stato un vero cappello nero deciso a sfruttare la vulnerabilità che aveva scoperto? E se la sua manipolazione apparentemente abile dei media fosse fallita e i dettagli del difetto fossero diventati noti prima che la patch fosse a posto? Inoltre, anche date le buone intenzioni di ricercatori come Kaminsky, correggere i difetti di base di Internet non è facile. Gli esperti concordano sul fatto che il problema DNS non fa eccezione. Diverse proposte sono sul tavolo per risolverlo con mezzi più affidabili di una patch, principalmente riducendo la fiducia che un server richiedente accorda a un name server. Le proposte vanno da correzioni relativamente semplici, come l'inclusione di informazioni ancora più casuali nelle richieste fatte ai server dei nomi, allo spostamento dell'intero sistema su una serie di protocolli che consentirebbero ai server dei nomi di firmare le proprie risposte in modo crittografico. Nel frattempo, sia Kaminsky che Vixie affermano che gli aggressori hanno iniziato a fare uso del difetto DNS e si aspettano che arriveranno altri problemi. Kaminsky osserva che il difetto diventa particolarmente pericoloso se sfruttato insieme ad altre vulnerabilità. Una di queste combinazioni, afferma, consentirebbe a un utente malintenzionato di rilevare gli aggiornamenti automatici che un fornitore di software invia ai propri clienti, sostituendoli con malware. Kaminsky afferma di aver trascorso gli ultimi mesi al telefono con aziende che sarebbero bersagli interessanti per quel tipo di attacco, come autorità di certificazione, social network e provider di servizi Internet, cercando di convincerle a riparare il prima possibile. La cosa spaventosa, dice Dai Zovi, è quanto sia fragile [Internet]. … E cosa ne faremo? Erica Naone è Assistant Editor presso Revisione della tecnologia.

nascondere