Security Week 42: collisioni SHA-1, hackeraggio reale di router, Android/sicurezza/penombra

Konstantin Goncharov ci spiega nel Security Week di oggi i grandi epic fail dei giganti della tecnologia.

Quando ci si trova nell’occhio del ciclone, è difficile farsi un’idea chiara di ciò che sta accadendo realmente. Mentre siamo bloccati nel traffico, non sappiamo che il problema è 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é non abbiamo le informazioni sufficienti per valutare la situazione.

È quello che accade costantemente nel campo della sicurezza informatica, un ambito così complesso e pieno zeppo di dettagli e particolarità che, a volte, i risultati di una ricerca hanno un’effettiva applicazione solo dopo anni.

Quest’oggi 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 è possibile valutare l’importanza di alcuni eventi o si potrebbero perdere alcuni dettagli importanti.

Proverò il più possibile a spiegarvi con esempi quanto detto fino ad ora, anche se il contesto può rivelarsi vago e flessibile e può dare adito a diverse interpretazioni. Per cui sedetevi e godetevi questa nuovo Security Week; come sempre, il nostro team editoriale di Threatpost ha scelto le tre notizie più importanti e io le commenterò senza pietà. Trovate qui gli altri post.

La ricerca di collisioni SHA1 è ora molto più economica

La notizia. Le previsioni di Jesse Walker di tre anni fa. La nuova ricerca che ha ribaltato le opinioni sulla sicurezza di questo algoritmo

Chi ha esplorato Linux un po’ di più ed è andato oltre le impostazioni automatiche di Ubuntu sa che è assolutamente necessario leggere le istruzioni. Magari all’inizio 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.

Lo stesso accade in questa notizia: senza un minimo di orientamento, questo tema non è facile da comprendere. Anzi, oserei dire che si tratta dell’argomento più difficile mai trattato nei nostri Security Week. Proverò a spiegarmi con parole semplici.

Proverò qualcosa del genere

Proverò qualcosa del genere

SHA-1 è 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 è impossibile recuperare l’informazione dall’hash, come non si può recuperare una bistecca da pezzi di carne macinata.

Per la precisione, DOVREBBE essere impossibile, anche con una password sciocca tipo “123456”. Questi algoritmi hanno due caratteristiche: l’impossibilità di ottenere i dati iniziali solo con l’hash e l’impossibilità di farli coincidere con la matrice in modo che abbiano lo stesso hash.

Per essere precisi, ESISTE la possibilità 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à che la risposta è 42 ma per allora non ve ne potrà fregar di meno.

È questo il nodo del problema. I PC guadagnano sempre più in potenza e i ricercatori cercano costantemente di bypassare gli algoritmi crittografici. È più semplice trovare una collisione all’algoritmo crittografico che decifrare la matrice dati iniziale.

SHA-1 viene utilizzato in diversi sistemi di crittografia e soluzioni per le autorizzazioni d’accesso, e il suo compito è quello di assicurare che coincidano i dati di due agenti diversi. Se si scoprono due o più matrici con lo stesso hash mediante un processo meno lungo e problematico, l’algoritmo non è più affidabile.

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’algoritmo è in grado di trovare la collisione con minore sforzo che un metodo di forza bruta. O, per essere più precisi, ora stiamo parlando di un attacco di compleanno (sbagliato!)

Questa mia semplice spiegazione non lo è poi così tanto.

I ricercatori migliorano l’algoritmo 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ù due secoli ma due mesi, possiamo iniziare a preoccuparci.

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 211 anni- server (una stima originale che si basa su un server tipico).

Grazie a servizi su cloud come Amazon EC2 si può persino fare una stima di quanti soldi ci vogliono per craccare l’hash. Con 700 mila dollari in teoria si può falsificare una firma digitale in un tempo relativamente breve.

Questa stima risale al 2012; ciò vuol dire che già da allora SHA-1 non era così affidabile e solo i ricchi agenti governativi potevano permettersi di craccare l’algoritmo.

Ovviamente queste organizzazioni non avevano fretta di rendere pubblico il fatto di essere riusciti a battere la crittografia. Ora però 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 “strumento”.

Di recente, un gruppo di ricercatori provenienti dalle università 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à Amazon) e ci vorrebbero solamente 49 giorni.

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 Legge di Moore, lasciando da parte i miglioramenti dell’algoritmo di attacco (come se si usasse solo GPU per il calcolo per via della disponibilità e la potenza). È impossibile fare una stima accurata degli effetti dell’ottimizzazione dell’algoritmo.

E qui arriva la domanda fondamentale: tutti questi calcoli costituiscono una vera minaccia? Non necessariamente. Come queste vulnerabilità possono essere sfruttate in the wild? Vi propongo un buon esempio basato sull’algoritmo 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.

Si tratta di esempi di vita reale? Flame, 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 è stata falsificata ma gli hash coincidevano. Stime indipendenti hanno dimostrato che questo trucchetto, che ha sfruttato un algoritmo ancor meno affidabile, sarebbe costato dai 200 mila ai 2 milioni di dollari, costosissimo!

Cosa dire allora di SHA-1?  L’algoritmo è in vigore dal 1995. Già dal2005 era chiaro che non si trattasse dell’algoritmo più affidabile in assoluto. In base alle ultime stime, gli exploit di collisione SHA-1 sono ancora lontani e nel frattempo SHA-1 verrà poco a poco eliminato e sostituito da algoritmi hash più affidabili.

Per il 2017 i principali sviluppatori di browser accantoneranno SHA-1, ma è 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à da qui a un anno?

La ricerca sulle vulnerabilità SHA-1 ha un valore puramente scientifico; immaginare le potenziali conseguenze è così vago come scoprire che un uomo ha viaggiato nello spazio basandosi su una sola notizia che dice “Il 12 aprile 1961, 250 tonnellate di combustibile per navicelle spaziali è bruciato sul deserto del Kazakhstan”. Insomma, chi vivrà vedrà.

Una nota curiosa: il vero nome di ciò che chiamiamo “hash” in realtà è “digest” o “message digest”. Quindi voi state leggendo un digest su un digest. Grandi!

Una vulnerabilità nei router Netgear può essere sfruttata per davvero

La notizia. La descrizione della vulnerabilità

È stata individuata una vulnerabilità nei router Netgear N300. Un’altra falla in un router, diversa sì ma alla fine è sempre la stessa storia. Abbiamo già parlato in altri Security Week di un paio di bug presenti nei router Belkin . Tuttavia, per quanto riguarda Netgear la situazione è davvero preoccupante.

Facciamo un esempio. Apriamo l’interfaccia web del router e digitiamo la password (una sbagliata, non è 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… sì che qualcosa succede.

Naturalmente meglio essere connessi alla rete locale che rende il tutto più difficile. Se invece il router è collegato a una rete Wi-Fi pubblica, è facile entrare. E se all’improvviso il proprietario del router decidesse di dare accesso libero all’interfaccia web, allora è un gioco da ragazzi.

Comunque sia, perché l’accesso web dovrebbe essere aperto a tutti? E parliamo di un accesso al router e non alla rete locale. Non c’è alcuna ragione per farlo e molte ragioni per NON farlo.

La situazione del router Belkin è andata avanti nella maniera giusta: il vendor è stato avvisato e nel giro di due mesi l’azienda ha pubblicato una versione beta del nuovo firmware. Sembrava che andasse tutto bene, poi è arrivata la cattiva notizia: la vulnerabilità era già stata sfruttata in the wild.

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.  L’agente sconosciuto ha ricevuto tutte le richieste DNS. Il server si è occupato di oltre 10 mila router hackerati.

https://twitter.com/NETGEARhelp/status/653682920540999680

Un dato divertente: Compass Security ha cercato di mettersi in contatto più 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 è entrato in scena un nuovo attore, una compagnia chiamata Shellshock Labs, che ha pubblicato la propria ricerca senza avvisare nessuno (molto male).

Ovviamente, è bello ribattezzare una compagnia di ricerca con il nome di un’importante vulnerabilità bash, ma sarebbe ancora meglio se non si facesse torto a nessuno. In ogni caso, la ricerca degli “shellshoker” ha aiutato a capire da dove provenisse il bug. Il codice firmware ha permesso solo una volta di accedere all’interfaccia web senza la password e al primo tentativo. Per disattivare questa opzione ci sarebbe dovuta essere una flag, ma non c’era.  E poi alla fine il firmware è stato aggiornato.

L’87% dei dispositivi Android non è sicuro

La notizia. Il sito Internet dei ricercatori, compresa la classifica dei dispositivi suddivisa per vendor

Non è possibile! Non è mai successo prima ed ecco che ci risiamo! Stiamo parlando di un’altra ricerca scientifica (per fortuna, non così tecnica come quella sull’SHA-1). I ricercatori dell’Università di Cambridge hanno condotto un esperimento interessante: hanno raccolto i dati su 32 importanti vulnerabilità Android, hanno selezionato le 13 più pericolose e hanno verificato se i dispositivi delle più svariate marche fossero protetti da queste vulnerabilità.

Ecco come hanno fatto: hanno sviluppato l’app Device Analyzer per raccogliere i dati telemetrici dai dispositivi che hanno preso parte all’esperimento, dati come la versione del sistema operativo e il numero di fabbrica. I ricercatori hanno raccolto i dati di oltre 20 mila smartphone.

Facendo il confronto tra la versione del sistema operativo e i dati della vulnerabilità, i ricercatori sono riusciti a tirare le somme. Ecco cosa ne è venuto fuori.

I risultati normalizzati hanno dimostrato che l’87% dei dispositivi era soggetto ad almeno una delle vulnerabilità critiche. Dobbiamo aggiungere l’avverbio “potenzialmente”: come abbiamo potuto vedere nel caso di Stagefright, anche la vulnerabilità più pericolosa può non avere le ripercussioni più gravi prospettate a causa delle limitazioni pratiche.

I ricercatori sono andati oltre e hanno stilato un parametro, il punteggio FUM, per valutare il livello di “pericolosità” insito nei vari dispositivi. Si basa sul tempo che il vendor impiega a individuare un nuovo bug e a pubblicare la patch definitiva.

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à non dovremmo parlare di vincitori, qui ci sono solo vinti.

Il punteggio è 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’utente aggiornare il dispositivo. La situazione peggiora quanto più è datato il dispositivo: i punteggi ottenuti dai dispositivi vecchi di 2-3 anni sono imbarazzanti. Qual è la motivazione? I rispettivi proprietari non li aggiornano ma continuano a utilizzarli.

L’approccio adottato per l’esperimento 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’invio delle patch. Dobbiamo comunque accettare l’idea che si tratta di un ecosistema che non sarà mai sicuro al 100%.

Finché Android rimarrà così segmentato, si tratterà sempre di un ecosistema poco sicuro. Possiamo rimanere fedeli all’idea che iOS sia più affidabile da questo punto di vista ma la prima notizia di questo post dimostra che, per questioni di budget, nessun ecosistema può considerarsi immune. Una variabile da considerare quando si elabora una strategia nel settore della sicurezza informatica.

Cos’altro?

Apple ha eliminato alcune applicazioni dallo Store che aiutavano gli hacker a intercettare e modificare il traffico criptato attraverso l’installazione 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à. Come è stato possibile prima allora?

La European Aviation Security Agency (EASA) ha fatto luce su un bug in ACARS, 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.

Questa vulnerabilità non consente di dirottare i comandi di volo ma può essere utilizzata per inviare messaggi contraddittori ai piloti. Il bug di ACARS è oggetto di dibattito (in alcuni file PDF) fin dal 2013 ma solo da parte dei ricercatori di sicurezza. La buona notizia è che adesso un organismo ufficiale ha sollevato finalmente il problema!

Oldies

Indicator-734

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ò 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ò essere decifrata, il virus blocca le operazioni del file (int 20h), avendo già avviato il counter. A seconda dello stato di quest’ultimo (approssimativamente una volta ogni ora), il virus disegna una croce rossa sullo schermo con al centro la parola “VINDICATOR”. Il virus intercetta int 1Ch, 21h.

Citazione da “Computer viruses in MS-DOS” di Eugene Kaspersky, 1992, p.70

Dichiarazione di non responsabilità: questo articolo riflette la persona opinione dell’autore. Può coincidere o no con la posizione di Kaspersky Lab.

Consigli
Iscriviti per ricevere le nostre notizie via e-mail
  • Tutti gli altri paesi