Security Week 34: le difficoltà delle patch

Ci sono tanti motivi per cui un bug non viene risolto immediatamente, o forse mai. In ogni caso, bisogna pur sempre trovare una soluzione.

security-week-34

Settimana burrascosa per la sicurezza informatica; dopo un’altra settimana di nuovi bug, zero-day e altre interessanti curiosità, ecco che tutto ciò si fa reale e arrivano ai software vulnerabili. Aspetto importante ma che a volte può risultare noioso se troppo frequente. Il nostro blog Threatpost ci fornisce notizie fresche fresche riguardanti la sicurezza informatica; in questo caso abbiamo tre casi interessanti sulle patch.

security-week-34-featuredL’argomento “patch” è abbastanza delicato. Dopo aver individuato una vulnerabilità, la parte più difficile arriva quando bisogna creare una patch che risolva il problema senza però compromettere tutto il resto. Ci sono tanti motivi per cui un bug non viene risolto immediatamente, a volte passa un bel po’ di tempo o addirittura rimane tutto così com’è! In ogni caso, bisogna pur sempre trovare una soluzione.

Nel post di oggi abbiamo tre storie di bug rimasti irrisolti. Ricordiamo brevemente le regole di questo post: ogni settimana, il team di Threatpost seleziona le tre notizie più rilevanti e che io consiglio caldamente di leggere. Tutte le precedenti edizioni della nostra rubrica si trovano a questo link.

Un altro bug su Android, stavolta tocca a Google Admin

La notizia su Threatpost, Ricerca condotta da MWR

Cosa è stato trovato?

Avete notato che ultimamente si susseguono notizie su notizie di bug? Ad esempio, c’è un’auto hackerata? Ecco che vengono trovati decine di nuovi bug nelle smart car! Lo stesso sta accadendo con Android. Siamo partiti con Stagefright, poi siamo passati a un paio di bug più piccoli, ora è la volta di Google Admin e della redenzione di Shawshank delle maniere di raggirare la sandbox.

security-week-34-kidGoogle Admin, una delle app di Android a livello di sistema, può accettare URL da altre app; sembra che qualsiasi URL possa andare bene, anche quelle che cominciano per “file: //”. In questo modo, anche il download di pagine web potrebbe trasformarsi in un file manager. Ma tutte le app di Android non dovrebbero essere isolate le une dalle altre? Mmm, sembrerebbe di no, Google Admin gode di grandi privilegi e, per il fatto che passano per URL anche cose che non lo sono, fa sì che alcune app possano eludere la sandbox e accedere a dati privati.

In che modo si è risolto il problema?

Innanzitutto vediamo brevemente come alcuni ricercatori indipendenti siano riusciti a individuare questa vulnerabilità. Dobbiamo ritornare al marzo scorso e a un report inviato a Google. Cinque mesi dopo, i ricercatori hanno verificato come si stava evolvendo la situazione e si sono resi conto che per il bug non era stata creata alcuna patch. Il 13 agosto il bug è stato reso pubblico, costringendo Google a porvi rimedio.

Ricordiamo che Google dispone di un team di ricerca interno che utilizza tempo e risorse per individuare i bug e non solo sui propri software. ProjectZero di Google ha di solito 90 giorni di margine di anticipo prima che il bug venga reso noto all’opinione pubblica, ma a questo punto ci domandiamo se Google sia in grado di creare patch adeguate in 90 giorni.

Nel caso Google Admin è andato tutto storto; innanzitutto, l’intera situazione è stata gestita nel modo sbagliato e, in secondo luogo, sappiamo benissimo che anche quando la patch c’è, non è detto che arrivi a tutti i dispositivi Android vulnerabili. Cosa dire degli aggiornamenti di sicurezza mensili? Perché a questo punto non li facciamo ogni sei mesi? Dai, andiamo…

security-week-34-kitten Vulnerabilità aperta su SCADA di Schneider Electric

La notizia su Threatpost, ICS-CERT Advisory

Benvenuti nell’affascinante mondo delle infrastrutture critiche! Vi preghiamo di prendere posto, di mettervi comodi e di non toccare quel famoso pulsante rosso o quel groviglio di cavi che fuoriescono a proposito. È tutto ok, sono lì da secoli. Se li toccate, siamo fritti.

I sistemi SCADA fanno parte delle infrastrutture critiche che si occupano di gestire oggetti importanti, dalle caldaie nei nostri appartamenti alle centrali nucleari. Tali sistemi non possono essere spenti o resettati, non si può giocare con impostazioni o parametri, meglio non toccare nulla!

Nel caso aveste qualche domanda in merito, questo articolo fa al caso vostro. Purtroppo, però, è un dato di fatto che questi sistemi così importanti spesso siano gestiti su PC normali con il caro, vecchio Windows. A differenza di quanto accada nella maggior parte delle aziende, dove si aggiornano o sostituiscono hardware e software per lo meno ogni cinque anni, alcuni impianti industriali robotizzati che gestiscono sostanze chimiche anche pericolose, possono funzionare 24 ore al giorno tutto l’anno, e per decenni, con lo stesso hardware.

Cosa è stato trovato?

Ebbene, sono stati trovati non si sa quanti bug in uno di questi sistemi, la stazione PLC P34 CPU Modicon M340 di Scheider Electric. In sostanza, grazie a queste vulnerabilità si può prendere il controllo praticamente di tutto ciò che gestisce questo sistema. Una falla piuttosto diffusa (riscontrata anche in router e altri apparecchi appartenenti al mondo dell’IoT) riguarda le credenziali hard-coded.

Per ovvie ragioni non possiamo sapere cosa viene codificato in questo modo nel sistema SCADA, tuttavia possiamo dedurre che si tratta di alcune credenziali di accesso di default che il vendor offre per rendere più agevoli alcune operazioni o semplicemente per le quali il vendor ha dimenticato di effettuare il test delle password fuori dal codice. O qualsiasi altra scusa, non lo sappiamo.

In che modo si è risolto il problema?

Semplicemente non è stato risolto. Sono passate ben due settimane da quando il ricercatore Aditya Sood ha presentato questa vulnerabilità al DEF CON, ma non c’è ancora nessuna patch in vista. È abbastanza comprensibile del resto: un vendor deve gestire una situazione difficile, il compito di creare una patch per un software vulnerabile diventa ancora più complicato poiché fermare questi sistemi comporta delle gravi perdite per il cliente, semplicemente sono sistemi il cui funzionamento non può essere fermato temporaneamente.

Quanto tempo ci vuole per applicare la patch? Per quanto tempo bisogna sospendere l’uso del sistema? E poi funzionerà bene di nuovo? Sono state prese in considerazioni tutte le caratteristiche dei dispositivi endpoint? In ogni caso si tratta di scuse inutili per non creare le patch ed è stato già dimostrato che disconnettere una infrastruttura critica da Internet o proteggerla con un firewall non è assolutamente una soluzione.

Gli sviluppatori durante la presentazione

Bug non risolto su Mac OS X

La notizia su Threatpost

Tocchiamo nuovamente la questione di come rendere pubblici i bug in maniera responsabile. Per quanto riguarda il bug di Google, i ricercatori hanno aspettato 5 mesi prima di renderlo pubblico, anche se Google stessa limita questo tempo a 90 giorni. Quanto si dovrebbe aspettare allora? Per quanto tempo gli sviluppatori dovrebbero chiudere un occhio?

Dare tempo non rende più pigri gli sviluppatori che continuano a rimandare il più possibile la creazione della patch? La pubblicazione immediata della vulnerabilità potrebbe spingere gli sviluppatori a essere più solerti nella creazione delle patch? Non ci sono linee guida precise in questo senso, tuttavia tutti sono d’accordo sul fatto che rendere noto un bug senza prima avvisare gli sviluppatori non sia un comportamento corretto.

Cosa è stato trovato?

Si tratta di un caso tipico in cui gli sviluppatori non sono stati avvisati o solo con breve anticipo per cui non hanno avuto il tempo di reagire… Il ricercatore 18 enne Luca Todesco ha pubblicato le info di un’importante vulnerabilità presente in Mac OS Yosemite e Mavericks (10.9.5 — 10.10.5), che consentirebbe ai cybercriminali di ottenere l’accesso root ai dispositivi colpiti.

Il bug non può essere sfruttato in remoto: il cybercriminale dovrebbe convincere l’utente a scaricare e a eseguire un exploit (cosa comunque fattibile). È disponibile anche un proof of concept, da prendere e usare.

In che modo si è risolto il problema?

Bene, non è finita qui. In base a quanto dice il ricercatore, ha provato a mettersi in contatto molte volte con Apple ma non ha ricevuto risposta. Non lo preoccupa il fatto di aver pubblicato una vulnerabilità così importante: dice di aver soltanto provato un nuovo modo di fare jailbreak, nulla dell’altro mondo.

Un paragone che non sta molto in piedi: il jailbreak è un’attività che gli utenti, ben consapevoli di ciò che stanno facendo, decidono di compiere. Non si può eseguire il jailbrake a insaputa, è l’utente che decide. Non è sempre il caso del bug scoperto da Todesco. Non ci meravigliamo che abbia ricevuto dure critiche:

Non è ancora chiaro se questo bug appena scoperto riguardi anche il nuovo Mac OS X El Capitan. Non vedo l’ora che esca la patch.

Cos’altro?

Microsoft ha pubblicato la patch per un bug su Internet Explorer (per lo meno qualcuno fa qualcosa), una misura straordinaria (la seconda questo mese).

I dati personali del sito di incontri per persone sposate Ashley Madison, rubati tempo fa dagli hacker, ora sono online, come preannunciato dal gruppo responsabile dell’attacco.

Kaspersky Lab ha scoperto Blue Termite, un’importante campagna di cyberintelligence che ha colpito molti utenti in Giappone. Non è passato inosservato che le spie informatiche, operative da oltre due anni, abbiano intensificato la propria attività quest’estate, quando hanno avuto tra le mani un exploit per Flash rubato da The Hacking Team.

Oldies infosec-digest-32-book

“Justice”

Piuttosto pericoloso, colpisce i file .COM quando chiamati dalle funzioni DOS 43h, 4Bh, 3Dh, 56h. Il malware viene scritto alla fine del file e altera 5 byte dell’inizio del codice (NOP; NOP; JMP Loc_Virus). Il metodo, che compromette COMMAND.COM, è lo stesso usato con il virus Lehigh. Si appropria regolarmente di dati scritti sul drive e li scrive in un settore diverso. E poi contiene il testo “AND JUSTICE FOR ALL”. Effettua l’hijack di int 13h e int 21h.

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

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

Consigli