{"id":6836,"date":"2015-10-19T09:28:35","date_gmt":"2015-10-19T09:28:35","guid":{"rendered":"https:\/\/kasperskydaily.com\/italy\/?p=6836"},"modified":"2017-11-13T17:06:11","modified_gmt":"2017-11-13T15:06:11","slug":"security-week-42","status":"publish","type":"post","link":"https:\/\/www.kaspersky.it\/blog\/security-week-42\/6836\/","title":{"rendered":"Security Week 42: collisioni SHA-1, hackeraggio reale di router, Android\/sicurezza\/penombra"},"content":{"rendered":"<p>Quando ci si trova nell\u2019occhio del ciclone, \u00e8 difficile farsi un\u2019idea chiara di ci\u00f2 che sta accadendo realmente. Mentre siamo bloccati nel traffico, non sappiamo che il problema \u00e8 dovuto a un incidente fino a quando non arriviamo al punto esatto e vediamo due macchine in mezzo alla strada che occupano due corsie. Questo perch\u00e9 non abbiamo le informazioni sufficienti per valutare la situazione.<\/p>\n<p>\u00c8 quello che accade costantemente nel campo della sicurezza informatica, un ambito cos\u00ec complesso e pieno zeppo di dettagli e particolarit\u00e0 che, a volte, i risultati di una ricerca hanno un\u2019effettiva applicazione solo dopo anni.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/89\/2015\/10\/05233127\/security-week-42-FB.jpg\" alt=\"\" width=\"1600\" height=\"1600\"><\/p>\n<p>Quest\u2019oggi le nostre tre notizie sulla sicurezza hanno in comune tra loro un sub-contesto di un certo valore. Quando non si ha esperienza in questo settore, non \u00e8 possibile valutare l\u2019importanza di alcuni eventi o si potrebbero perdere alcuni dettagli importanti.<\/p>\n<p>Prover\u00f2 il pi\u00f9 possibile a spiegarvi con esempi quanto detto fino ad ora, anche se il contesto pu\u00f2 rivelarsi vago e flessibile e pu\u00f2 dare adito a diverse interpretazioni. Per cui sedetevi e godetevi questa nuovo Security Week; come sempre, il nostro team editoriale di <a href=\"https:\/\/threatpost.com\/\" target=\"_blank\" rel=\"noopener nofollow\">Threatpost<\/a> ha scelto le tre notizie pi\u00f9 importanti e io le commenter\u00f2 senza piet\u00e0. Trovate qui gli altri <a href=\"https:\/\/www.kaspersky.it\/blog\/?s=security+week&amp;submit=Search\" target=\"_blank\" rel=\"noopener\">post<\/a>.<\/p>\n<h3><strong>La ricerca di collisioni SHA1 \u00e8 ora molto pi\u00f9 economica<\/strong><\/h3>\n<p>La <a href=\"https:\/\/threatpost.com\/practical-sha-1-collision-months-not-years-away\/114979\/\" target=\"_blank\" rel=\"noopener nofollow\">notizia<\/a>. Le <a href=\"https:\/\/www.schneier.com\/blog\/archives\/2012\/10\/when_will_we_se.html\" target=\"_blank\" rel=\"noopener nofollow\">previsioni<\/a> di Jesse Walker di tre anni fa. <a href=\"https:\/\/www.schneier.com\/blog\/archives\/2015\/10\/sha-1_freestart.html\" target=\"_blank\" rel=\"noopener nofollow\">La nuova ricerca<\/a> che ha ribaltato le opinioni sulla sicurezza di questo algoritmo<\/p>\n<p>Chi ha esplorato Linux un po\u2019 di pi\u00f9 ed \u00e8 andato oltre le impostazioni automatiche di Ubuntu sa che \u00e8 assolutamente necessario leggere le istruzioni. Magari all\u2019inizio si potrebbe tentare di cercare su Google un documento con la sequenza di comandi ma in alcuni casi succede che smette di funzionare tutto e siamo fritti.<\/p>\n<p>Lo stesso accade in questa notizia: senza un minimo di orientamento, questo tema non \u00e8 facile da comprendere. Anzi, oserei dire che si tratta dell\u2019argomento pi\u00f9 difficile mai trattato nei nostri Security Week. Prover\u00f2 a spiegarmi con parole semplici.<\/p>\n<div style=\"width: 330px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/89\/2015\/10\/05233127\/security-week-42-cat-jumps.gif\" alt=\"Prover\u00f2 qualcosa del genere\" width=\"320\" height=\"291\"><p class=\"wp-caption-text\">Prover\u00f2 qualcosa del genere<\/p><\/div>\n<p>SHA-1 \u00e8 un algoritmo crittografico di hash. Si tratta di un algoritmo dalla sequenza illimitata e che produce un messaggio di 160 bit per identificare la matrice iniziale dei dati. Se non si possiede questa matrice iniziale \u00e8 impossibile recuperare l\u2019informazione dall\u2019hash, come non si pu\u00f2 recuperare una bistecca da pezzi di carne macinata.<\/p>\n<p>Per la precisione, DOVREBBE essere impossibile, anche con una password sciocca tipo \u201c123456\u201d. Questi algoritmi hanno due caratteristiche: l\u2019impossibilit\u00e0 di ottenere i dati iniziali solo con l\u2019hash e l\u2019impossibilit\u00e0 di farli coincidere con la matrice in modo che abbiano lo stesso hash.<\/p>\n<p>Per essere precisi, ESISTE la possibilit\u00e0 di fare entrambe le cose ma ci vorrebbero delle risorse talmente potenti che non vale la pena provarci. Potreste comprare un supercomputer e dedicarlo al compito di rompere la cifratura. Poi, dopo 240 anni, vi dir\u00e0 che la risposta \u00e8 42 ma per allora non ve ne potr\u00e0 fregar di meno.<\/p>\n<p>\u00c8 questo il nodo del problema. I PC guadagnano sempre pi\u00f9 in potenza e i ricercatori cercano costantemente di bypassare gli algoritmi crittografici. \u00c8 pi\u00f9 semplice trovare una collisione all\u2019algoritmo crittografico che decifrare la matrice dati iniziale.<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">Practical SHA-1 Collision Months, Not Years, Away via <a href=\"https:\/\/twitter.com\/threatpost?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">@threatpost<\/a> <a href=\"https:\/\/t.co\/fU5VQUjLI4\" target=\"_blank\" rel=\"noopener nofollow\">https:\/\/t.co\/fU5VQUjLI4<\/a><\/p>\n<p>\u2014 Kaspersky (@kaspersky) <a href=\"https:\/\/twitter.com\/kaspersky\/status\/652502642850144256?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">October 9, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>SHA-1 viene utilizzato in diversi sistemi di crittografia e soluzioni per le autorizzazioni d\u2019accesso, e il suo compito \u00e8 quello di assicurare che coincidano i dati di due agenti diversi. Se si scoprono due o pi\u00f9 matrici con lo stesso hash mediante un processo meno lungo e problematico, l\u2019algoritmo non \u00e8 pi\u00f9 affidabile.<\/p>\n<p>Mi fermo qui e vi risparmio una lezione improponibile di calcolo. Vi faccio un breve riassunto: i ricercatori compilano un algoritmo alla ricerca di una collisione e l\u2019algoritmo \u00e8 in grado di trovare la collisione con minore sforzo che un metodo di forza bruta. O, per essere pi\u00f9 precisi, ora stiamo parlando di un attacco di <a href=\"https:\/\/it.wikipedia.org\/wiki\/Attacco_del_compleanno\" target=\"_blank\" rel=\"noopener nofollow\">compleanno<\/a> (sbagliato!)<\/p>\n<p><em>Questa mia semplice spiegazione non lo \u00e8 poi cos\u00ec tanto. <\/em><\/p>\n<p>I ricercatori migliorano l\u2019algoritmo e riducono il numero di operazioni di cifratura. Come risultato, un attacco per il quale ci sarebbero voluti 240 anni, potrebbe riuscire in 120 anni, e poi in 12 anni e alla fine in soli 2 anni. Quando per portare a termine un attacco ci vorranno non pi\u00f9 due secoli ma due mesi, possiamo iniziare a preoccuparci.<\/p>\n<p>E ora passiamo alla notizia. Tre anni fa Jesse Walker, un crittografico di Intel ha fatto una stima e ha affermato che nel 2015 per portare a termine un attacco di collisione SHA-1 ci vorrebbero 2<sup>11<\/sup> anni- server (una stima originale che si basa su un server tipico).<\/p>\n<p>Grazie a servizi su cloud come Amazon EC2 si pu\u00f2 persino fare una stima di quanti soldi ci vogliono per craccare l\u2019hash. Con 700 mila dollari in teoria si pu\u00f2 falsificare una firma digitale in un tempo relativamente breve.<\/p>\n<p>Questa stima risale al 2012; ci\u00f2 vuol dire che gi\u00e0 da allora SHA-1 non era cos\u00ec affidabile e solo i ricchi agenti governativi potevano permettersi di craccare l\u2019algoritmo.<\/p>\n<p>Ovviamente queste organizzazioni non avevano fretta di rendere pubblico il fatto di essere riusciti a battere la crittografia. Ora per\u00f2 possiamo fare una stima di quanto tempo ci metteranno i cybrcriminali, sempre in cerca di modi per far soldi, a mettere le mani su questo \u201cstrumento\u201d.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/89\/2015\/10\/05233125\/security-week-42-dog.jpg\" alt=\"\" width=\"1280\" height=\"686\"><\/p>\n<p>Di recente, un gruppo di ricercatori provenienti dalle universit\u00e0 di Olanda, Singapore e Francia ha pubblicato un white paper dove si specificano i metodi per ottimizzare il processo di calcolo della collisione. Se un cybercriminale venisse in possesso di queste scoperte, un attacco di collisione pratico costerebbe solo 75 mila dollari (in unit\u00e0 Amazon) e ci vorrebbero solamente 49 giorni.<\/p>\n<p>E con le risorse economiche adeguate, ci potrebbe volere anche meno tempo. Bruce Schneier, crittografo rinomato, ritiene che le stime fatte nel 2012 prendevano in considerazione solo la <a href=\"https:\/\/it.wikipedia.org\/wiki\/Legge_di_Moore\" target=\"_blank\" rel=\"noopener nofollow\">Legge di Moore<\/a>, lasciando da parte i miglioramenti dell\u2019algoritmo di attacco (come se si usasse solo GPU per il calcolo per via della disponibilit\u00e0 e la potenza). \u00c8 impossibile fare una stima accurata degli effetti dell\u2019ottimizzazione dell\u2019algoritmo.<\/p>\n<p>E qui arriva la domanda fondamentale: tutti questi calcoli costituiscono una vera minaccia? Non necessariamente. Come queste vulnerabilit\u00e0 possono essere sfruttate in the wild? Vi propongo un buon <a href=\"http:\/\/www.theregister.co.uk\/2014\/11\/05\/md5_hash_collision\/\" target=\"_blank\" rel=\"noopener nofollow\">esempio<\/a> basato sull\u2019algoritmo MD5, meno sicuro: prendiamo due file differenti (tipo le foto di due rock star), facciamo una serie di modifiche su una delle due e poi otteniamo due hash assolutamente identici per due immagini diverse.<\/p>\n<p>Si tratta di esempi di vita reale? <a href=\"https:\/\/securelist.com\/blog\/incidents\/33002\/flame-replication-via-windows-update-mitm-proxy-server-18\/\" target=\"_blank\" rel=\"noopener\">Flame<\/a>, una nota campagna informatica, ha utilizzato questo metodo per firmare un file dannoso con un certificato digitale Microsoft, ai tempi valido. Per essere precisi, la firma \u00e8 stata falsificata ma gli hash coincidevano. <a href=\"https:\/\/threatpost.com\/what-have-we-learned-flame-malware-061512\/76701\/\" target=\"_blank\" rel=\"noopener nofollow\">Stime indipendenti<\/a> hanno dimostrato che questo trucchetto, che ha sfruttato un algoritmo ancor meno affidabile, sarebbe costato dai 200 mila ai 2 milioni di dollari, costosissimo!<\/p>\n<p>Cosa dire allora di SHA-1?\u00a0 L\u2019algoritmo \u00e8 in vigore dal 1995. Gi\u00e0 dal2005 era chiaro che non si trattasse dell\u2019algoritmo pi\u00f9 affidabile in assoluto. In base alle ultime stime, gli exploit di collisione SHA-1 sono ancora lontani e nel frattempo SHA-1 verr\u00e0 poco a poco eliminato e sostituito da algoritmi hash pi\u00f9 affidabili.<\/p>\n<p>Per il 2017 i principali sviluppatori di browser accantoneranno SHA-1, ma \u00e8 meglio che facciano in fretta: se i costi di un potenziale attacco di collisione sono scesi da 2 milioni 770 mila dollari a 100 mila dollari in tre anni, cosa succeder\u00e0 da qui a un anno?<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\"><a href=\"https:\/\/twitter.com\/hashtag\/Security?src=hash&amp;ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">#Security<\/a> Experts Urge Web Owners to Upgrade From Insecure <a href=\"https:\/\/twitter.com\/hashtag\/SHA1?src=hash&amp;ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">#SHA1<\/a> Algorithm: <a href=\"http:\/\/t.co\/K9jq9bITlC\" target=\"_blank\" rel=\"noopener nofollow\">http:\/\/t.co\/K9jq9bITlC<\/a> <a href=\"https:\/\/twitter.com\/hashtag\/SSL?src=hash&amp;ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">#SSL<\/a> <a href=\"https:\/\/twitter.com\/hashtag\/infosec?src=hash&amp;ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">#infosec<\/a> <a href=\"http:\/\/t.co\/ZDCZUYlwD7\" target=\"_blank\" rel=\"noopener nofollow\">pic.twitter.com\/ZDCZUYlwD7<\/a><\/p>\n<p>\u2014 AT&amp;T Cybersecurity (@attcyber) <a href=\"https:\/\/twitter.com\/attcyber\/status\/653942042805051392?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">October 13, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>La ricerca sulle vulnerabilit\u00e0 SHA-1 ha un valore puramente scientifico; immaginare le potenziali conseguenze \u00e8 cos\u00ec vago come scoprire che un uomo ha viaggiato nello spazio basandosi su una sola notizia che dice \u201cIl 12 aprile 1961, 250 tonnellate di combustibile per navicelle spaziali \u00e8 bruciato sul deserto del Kazakhstan\u201d. Insomma, chi vivr\u00e0 vedr\u00e0.<\/p>\n<p>Una nota curiosa: il vero nome di ci\u00f2 che chiamiamo \u201chash\u201d in realt\u00e0 \u00e8 \u201cdigest\u201d o \u201cmessage digest\u201d. Quindi voi state leggendo un digest su un digest. Grandi!<\/p>\n<h3><strong>Una vulnerabilit\u00e0 nei router Netgear pu\u00f2 essere sfruttata per davvero<\/strong><\/h3>\n<p>La <a href=\"https:\/\/threatpost.com\/disclosed-netgear-router-vulnerability-under-attack\/114960\/\" target=\"_blank\" rel=\"noopener nofollow\">notizia<\/a>. La <a href=\"http:\/\/seclists.org\/fulldisclosure\/2015\/Oct\/29\" target=\"_blank\" rel=\"noopener nofollow\">descrizione<\/a> della vulnerabilit\u00e0<\/p>\n<p>\u00c8 stata individuata una vulnerabilit\u00e0 nei router Netgear N300. Un\u2019altra falla in un router, diversa s\u00ec ma alla fine \u00e8 sempre la stessa storia. Abbiamo gi\u00e0 parlato in altri <a href=\"https:\/\/www.kaspersky.it\/blog\/security-week-36\/6559\/\" target=\"_blank\" rel=\"noopener\">Security Week<\/a> di un paio di bug presenti nei router Belkin . Tuttavia, per quanto riguarda Netgear la situazione \u00e8 davvero preoccupante.<\/p>\n<p>Facciamo un esempio. Apriamo l\u2019interfaccia web del router e digitiamo la password (una sbagliata, non \u00e8 il nostro router e non la sappiamo). Veniamo reindirizzati alla pagina di Accesso Negato. Se proviamo aprire la pagina BRS_netgear_success.htm non veniamo reindirizzati da nessuna parte. Ma se ci proviamo per un paio di volte\u2026 s\u00ec che qualcosa succede.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/89\/2015\/10\/05233125\/security-week-42-netgear.jpg\" alt=\"\" width=\"800\" height=\"600\"><\/p>\n<p>Naturalmente meglio essere connessi alla rete locale che rende il tutto pi\u00f9 difficile. Se invece il router \u00e8 collegato a una rete Wi-Fi pubblica, \u00e8 facile entrare. E se all\u2019improvviso il proprietario del router decidesse di dare accesso libero all\u2019interfaccia web, allora \u00e8 un gioco da ragazzi.<\/p>\n<p>Comunque sia, perch\u00e9 l\u2019accesso web dovrebbe essere aperto a tutti? E parliamo di un accesso al router e non alla rete locale. Non c\u2019\u00e8 alcuna ragione per farlo e molte ragioni per NON farlo.<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">Disclosed <a href=\"https:\/\/twitter.com\/NETGEAR?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">@Netgear<\/a> Router Vulnerability Under Attack: <a href=\"https:\/\/t.co\/P5s6uItTjn\" target=\"_blank\" rel=\"noopener nofollow\">https:\/\/t.co\/P5s6uItTjn<\/a> via <a href=\"https:\/\/twitter.com\/threatpost?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">@threatpost<\/a> <a href=\"http:\/\/t.co\/RgFM9SGSGu\" target=\"_blank\" rel=\"noopener nofollow\">pic.twitter.com\/RgFM9SGSGu<\/a><\/p>\n<p>\u2014 Kaspersky (@kaspersky) <a href=\"https:\/\/twitter.com\/kaspersky\/status\/652184022597169153?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">October 8, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>La situazione del router Belkin \u00e8 andata avanti nella maniera giusta: il vendor \u00e8 stato avvisato e nel giro di due mesi l\u2019azienda ha pubblicato una versione beta del nuovo firmware. Sembrava che andasse tutto bene, poi \u00e8 arrivata la cattiva notizia: la vulnerabilit\u00e0 era gi\u00e0 stata sfruttata in the wild.<\/p>\n<p>La compagnia di sicurezza svizzera Compass Security ha scoperto un falso router con le impostazioni modificate: il server DSN non apparteneva a un provider del servizio ma a non si sa chi.\u00a0 L\u2019agente sconosciuto ha ricevuto tutte le richieste DNS. Il server si \u00e8 occupato di oltre 10 mila router hackerati.<\/p>\n<p>https:\/\/twitter.com\/NETGEARhelp\/status\/653682920540999680<\/p>\n<p>Un dato divertente: Compass Security ha cercato di mettersi in contatto pi\u00f9 volte con Netgear. Quando finalmente ci sono riusciti, la compagnia ha persino ricevuto una versione beta del nuovo firmware per effettuare dei test. Ma poi \u00e8 entrato in scena un nuovo attore, una compagnia chiamata Shellshock Labs, che ha pubblicato la propria ricerca senza avvisare nessuno (molto male).<\/p>\n<p>Ovviamente, \u00e8 bello ribattezzare una compagnia di ricerca con il nome di un\u2019importante <a href=\"https:\/\/www.kaspersky.it\/blog\/che-cose-la-vulnerabilita-di-bash-e-come-ci-puo-colpire\/4856\/\" target=\"_blank\" rel=\"noopener\">vulnerabilit\u00e0 bash<\/a>, ma sarebbe ancora meglio se non si facesse torto a nessuno. In ogni caso, la ricerca degli \u201cshellshoker\u201d ha aiutato a capire da dove provenisse il bug. Il codice firmware ha permesso solo una volta di accedere all\u2019interfaccia web senza la password e al primo tentativo. Per disattivare questa opzione ci sarebbe dovuta essere una flag, ma non c\u2019era.\u00a0 E poi alla fine il firmware \u00e8 stato <a href=\"https:\/\/threatpost.com\/netgear-publishes-patched-firmware-for-routers-under-attack\/115006\/\" target=\"_blank\" rel=\"noopener nofollow\">aggiornato<\/a>.<\/p>\n<h3><strong>L\u201987% dei dispositivi Android non \u00e8 sicuro<\/strong><\/h3>\n<p>La <a href=\"https:\/\/threatpost.com\/researchers-find-85-percent-of-android-devices-insecure\/115030\/\" target=\"_blank\" rel=\"noopener nofollow\">notizia.<\/a> <a href=\"http:\/\/androidvulnerabilities.org\/\" target=\"_blank\" rel=\"noopener nofollow\">Il sito Internet dei ricercatori<\/a>, compresa la classifica dei dispositivi suddivisa per vendor<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/89\/2015\/10\/05233124\/security-week-42-lemur.jpg\" alt=\"\" width=\"800\" height=\"800\"><\/p>\n<p>Non \u00e8 possibile! Non \u00e8 mai successo prima ed ecco che ci risiamo! Stiamo parlando di un\u2019altra ricerca scientifica (per fortuna, non cos\u00ec tecnica come quella sull\u2019SHA-1). I ricercatori dell\u2019Universit\u00e0 di Cambridge hanno condotto un esperimento interessante: hanno raccolto i dati su 32 importanti vulnerabilit\u00e0 Android, hanno selezionato le 13 pi\u00f9 pericolose e hanno verificato se i dispositivi delle pi\u00f9 svariate marche fossero protetti da queste vulnerabilit\u00e0.<\/p>\n<p>Ecco come hanno fatto: hanno sviluppato l\u2019<a href=\"https:\/\/play.google.com\/store\/apps\/details?id=uk.ac.cam.deviceanalyzer\" target=\"_blank\" rel=\"noopener nofollow\">app<\/a> Device Analyzer per raccogliere i dati telemetrici dai dispositivi che hanno preso parte all\u2019esperimento, dati come la versione del sistema operativo e il numero di fabbrica. I ricercatori hanno raccolto i dati di oltre 20 mila smartphone.<\/p>\n<p>Facendo il confronto tra la versione del sistema operativo e i dati della vulnerabilit\u00e0, i ricercatori sono riusciti a tirare le somme. Ecco cosa ne \u00e8 venuto fuori.<\/p>\n<p>I risultati normalizzati hanno dimostrato che l\u201987% dei dispositivi era soggetto ad almeno una delle vulnerabilit\u00e0 critiche. Dobbiamo aggiungere l\u2019avverbio \u201cpotenzialmente\u201d: come abbiamo potuto vedere nel caso di <a href=\"https:\/\/threatpost.com\/android-stagefright-flaws-put-950-million-devices-at-risk\/113960\/\" target=\"_blank\" rel=\"noopener nofollow\">Stagefright<\/a>, anche la vulnerabilit\u00e0 pi\u00f9 pericolosa pu\u00f2 non avere le ripercussioni pi\u00f9 gravi prospettate a causa delle limitazioni pratiche.<\/p>\n<p>I ricercatori sono andati oltre e hanno stilato un parametro, il punteggio FUM, per valutare il livello di \u201cpericolosit\u00e0\u201d insito nei vari dispositivi. Si basa sul tempo che il vendor impiega a individuare un nuovo bug e a pubblicare la patch definitiva.<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">Researchers find 85% of <a href=\"https:\/\/twitter.com\/hashtag\/Android?src=hash&amp;ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">#Android<\/a> devices insecure: <a href=\"https:\/\/t.co\/YNbAdZKAAv\" target=\"_blank\" rel=\"noopener nofollow\">https:\/\/t.co\/YNbAdZKAAv<\/a> <a href=\"http:\/\/t.co\/1dYfutssgh\" target=\"_blank\" rel=\"noopener nofollow\">pic.twitter.com\/1dYfutssgh<\/a><\/p>\n<p>\u2014 Eugene Kaspersky (@e_kaspersky) <a href=\"https:\/\/twitter.com\/e_kaspersky\/status\/654692215587864577?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">October 15, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>I migliori, naturalmente, sono stati i dispositivi Nexus, che ricevono le patch prima degli altri. LG occupa la seconda posizione e al terzo gradino del podio troviamo Motorola. In realt\u00e0 non dovremmo parlare di vincitori, qui ci sono solo vinti.<\/p>\n<p>Il punteggio \u00e8 stato ricavato prendendo in considerazione il numero di dispositivi aggiornati con le patch; sappiamo bene che il vendor pubblica le patch ma poi spetta all\u2019utente aggiornare il dispositivo. La situazione peggiora quanto pi\u00f9 \u00e8 datato il dispositivo: i punteggi ottenuti dai dispositivi vecchi di 2-3 anni sono imbarazzanti. Qual \u00e8 la motivazione? I rispettivi proprietari non li aggiornano ma continuano a utilizzarli.<\/p>\n<p>L\u2019approccio adottato per l\u2019esperimento ha un paio di punti che potrebbero essere opinabili; in ogni caso, questi risultati non sono una sorpresa. I ricercatori hanno dichiarato che uno degli obiettivi della ricerca era spronare i vendor a migliorare il meccanismo d\u2019invio delle patch. Dobbiamo comunque accettare l\u2019idea che si tratta di un ecosistema che non sar\u00e0 mai sicuro al 100%.<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">New study suggests 85% of Android devices exposed to at least one critical vulnerability: <a href=\"http:\/\/t.co\/vZAtW8JhiS\" target=\"_blank\" rel=\"noopener nofollow\">http:\/\/t.co\/vZAtW8JhiS<\/a><\/p>\n<p>\u2014 Gizmodo (@Gizmodo) <a href=\"https:\/\/twitter.com\/Gizmodo\/status\/654627155771527169?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">October 15, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>Finch\u00e9 Android rimarr\u00e0 cos\u00ec segmentato, si tratter\u00e0 sempre di un ecosistema poco sicuro. Possiamo rimanere fedeli all\u2019idea che iOS sia pi\u00f9 affidabile da questo punto di vista ma la prima notizia di questo post dimostra che, per questioni di budget, nessun ecosistema pu\u00f2 considerarsi immune. Una variabile da considerare quando si elabora una strategia nel settore della sicurezza informatica.<\/p>\n<h3><strong>Cos\u2019altro?<\/strong><\/h3>\n<p>Apple ha eliminato alcune applicazioni dallo Store che aiutavano gli hacker a intercettare e modificare il traffico criptato attraverso l\u2019installazione dei certificati root (per il blocco di adware o cose ancora peggiori). Da quanto ne sappiamo, non ci sono nuove app con le stesse funzionalit\u00e0. Come \u00e8 stato possibile prima allora?<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">Apple Removes Apps That Expose Encrypted Traffic <a href=\"https:\/\/t.co\/fHQiLSCypy\" target=\"_blank\" rel=\"noopener nofollow\">https:\/\/t.co\/fHQiLSCypy<\/a> via <a href=\"https:\/\/twitter.com\/threatpost?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">@threatpost<\/a> <a href=\"http:\/\/t.co\/np2fFUmvc8\" target=\"_blank\" rel=\"noopener nofollow\">pic.twitter.com\/np2fFUmvc8<\/a><\/p>\n<p>\u2014 Kaspersky (@kaspersky) <a href=\"https:\/\/twitter.com\/kaspersky\/status\/652558957429567490?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">October 9, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>La European Aviation Security Agency (EASA) <a href=\"https:\/\/threatpost.com\/european-aviation-agency-warns-of-aircraft-hacking\/114987\/\" target=\"_blank\" rel=\"noopener nofollow\">ha fatto luce<\/a> su un bug in <a href=\"https:\/\/it.wikipedia.org\/wiki\/ACARS\" target=\"_blank\" rel=\"noopener nofollow\">ACARS<\/a>, sistema utilizzato per lo scambio di dati tra aeromobili e stazioni di terra. Sembra piuttosto semplice inviare un falso messaggio mediante il sistema, che non richiede nessun tipo di verifica.<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">European Aviation Agency Warns of Aircraft Hacking: <a href=\"https:\/\/t.co\/PDcT6J5ENg\" target=\"_blank\" rel=\"noopener nofollow\">https:\/\/t.co\/PDcT6J5ENg<\/a> via <a href=\"https:\/\/twitter.com\/threatpost?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">@threatpost<\/a> <a href=\"https:\/\/twitter.com\/hashtag\/planehack?src=hash&amp;ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">#planehack<\/a> <a href=\"http:\/\/t.co\/nC1x5JLR0p\" target=\"_blank\" rel=\"noopener nofollow\">pic.twitter.com\/nC1x5JLR0p<\/a><\/p>\n<p>\u2014 Kaspersky (@kaspersky) <a href=\"https:\/\/twitter.com\/kaspersky\/status\/652509465900658696?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">October 9, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>Questa vulnerabilit\u00e0 non consente di dirottare i comandi di volo ma pu\u00f2 essere utilizzata per inviare messaggi contraddittori ai piloti. Il bug di ACARS <a href=\"https:\/\/conference.hitb.org\/hitbsecconf2013ams\/materials\/D1T1%2520-%2520Hugo%2520Teso%2520-%2520Aircraft%2520Hacking%2520-%2520Practical%2520Aero%2520Series.pdf\" target=\"_blank\" rel=\"noopener nofollow\">\u00e8 oggetto di dibattito<\/a> (in alcuni file PDF) fin dal 2013 ma solo da parte dei ricercatori di sicurezza. La buona notizia \u00e8 che adesso un organismo ufficiale ha sollevato finalmente il problema!<\/p>\n<h3><strong>Oldies<\/strong><\/h3>\n<p>Indicator-734<\/p>\n<p>Resident virus molto pericoloso. Infetta i file .COM caricati sulla memoria. Il virus cripta la prima parte del file utilizzano 10h byte di BIOS. Ci\u00f2 vuol dire che i file possono essere decifrati e avviati sono su un computer con la stessa versione di BIOS. Se la parte iniziale del file non pu\u00f2 essere decifrata, il virus blocca le operazioni del file (int 20h), avendo gi\u00e0 avviato il counter. A seconda dello stato di quest\u2019ultimo (approssimativamente una volta ogni ora), il virus disegna una croce rossa sullo schermo con al centro la parola \u201cVINDICATOR\u201d. Il virus intercetta int 1Ch, 21h.<\/p>\n<p><em>Citazione da \u201cComputer viruses in MS-DOS\u201d di Eugene Kaspersky, 1992, p.70<\/em><\/p>\n<p><em>Dichiarazione di non responsabilit\u00e0: questo articolo riflette la persona opinione dell\u2019autore. Pu\u00f2 coincidere o no con la posizione di Kaspersky Lab.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Konstantin Goncharov ci spiega nel Security Week di oggi i grandi epic fail dei giganti della tecnologia.<\/p>\n","protected":false},"author":53,"featured_media":6838,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2641,12],"tags":[3,1649,736,1580,1002,45],"class_list":{"0":"post-6836","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-threats","8":"category-news","9":"tag-apple","10":"tag-digest","11":"tag-router","12":"tag-security-week","13":"tag-sha-1","14":"tag-sicurezza"},"hreflang":[{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/security-week-42\/6836\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/security-week-42\/6148\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/security-week-42\/6345\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/security-week-42\/6325\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/security-week-42\/7108\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/security-week-42\/9370\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/security-week-42\/10278\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/security-week-42\/6284\/"},{"hreflang":"ja","url":"https:\/\/blog.kaspersky.co.jp\/security-week-42\/9276\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/security-week-42\/9370\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/security-week-42\/10278\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/security-week-42\/10278\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.it\/blog\/tag\/apple\/","name":"apple"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/6836","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/users\/53"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/comments?post=6836"}],"version-history":[{"count":1,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/6836\/revisions"}],"predecessor-version":[{"id":11336,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/6836\/revisions\/11336"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media\/6838"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media?parent=6836"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/categories?post=6836"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/tags?post=6836"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}