Per Apple la vulnerabilità stavolta è vera, e grave

Qualche giorno fa avevo parlato di vulnerabilità vere e presunte. Vere sì, perché difatti era reale, presunte perché dipendenti da una vulnerabilità ancora più grave.

Questo era appunto un esempio per dire che nel campo della sicurezza informatica, purtroppo, si tende troppo spesso a guardare il dito e non la luna luminosa che c’è dietro.

Stavolta le cose non stanno così, anzi, la luna è molto ben vistosa e minacciosa.

Apple venerdì sera (notte in Italia), ha rilasciato un aggiornamento per iOS che risolveva alcuni problemi con SSL/TLS.

Citare il protocollo TLS in un aggiornamento di sicurezza fa (meglio: dovrebbe) tremare qualsiasi esperto, visto che è uno dei mattoni fondamentali della sicurezza della navigazione e dell’utilizzo dei servizi di internet. È quello che, per chi è poco esperto, fa chiudere il lucchetto del browser e ci conferma che il sito

È quello che stabilisce e garantisce il trust tra noi e il servizio che stiamo utilizzando, e in tempi come questi dove la fiducia in rete è ai minimi, è essenziale che i rischi su questo fronte siano i più bassi possibili.

Sempre collegandomi al post scorso, proprio la capacità di ragionare di un esperto di sicurezza dovrebbe farlo saltare sulla sedia quando si leggono vulnerabilità che permettono di attaccare il rapporto di fiducia tra utente e servizio.

Molti in effetti sono saltati, anche se ho letto su Twitter parecchie ingiurie verso Apple proprio per l’orario di pubblicazione di questa patch: venerdì pomeriggio. Immagino come saranno stati contenti i gestori di un parco dispositivi iOS aziendali, magari con migliaia di iPhone e iPad, che si ritrovano all’inizio del weekend con un deploy enorme e urgentissimo.

Come in ogni errore o vicenda di notevole gravità, si può sempre imparare qualcosa. In questo caso possiamo capire meglio due cose: quale è stato il problema e perché era urgente risolverlo.

Il problema è un “banale” errore nel codice. Questa forse è la cosa più disarmante, visto che si tratta, letteralmente, di due righe.

Lo spiega bene ImperialViolet, analizzando il codice pubblicato da Apple.
Il problema è questo

Apple sslKeyExchange.c

Il problema sono quelle due goto fail una dietro l’altra.

Semplificando molto, il bug sta nel fatto che il codice di verifica SSL/TLS può consentire lo stabilirsi di una connessione “sicura” (il lucchetto chiuso, per intenderci) anche se il server che stiamo contattando non da la prova di avere la chiave privata di quel certificato di cifratura.

Quando si stabilisce una connessione di questo tipo infatti dopo la prima richiesta ad esempio a https://www.lamiabancaonlain.it, il server manda al browser un certificato SSL e una chiave pubblica firmata. Il browser verifica il certificato sia emesso da una autorità riconosciuta, poi con la firma controlla se il server possiede effettivamente la chiave privata di quel certificato, per poter stabilire una connessione cifrata tra le due parti.

Con quei due goto fail, i dispositivi iOS saltano il secondo passaggio, è possibile quindi creare un sito fake, con il certificato corretto, ma con una firma sbagliata o addirittura senza alcuna firma, e il browser chiuderà comunque il lucchetto.

Imperia Violet ha anche messo a disposizione un sito di test per vedere se si è colpiti da questa vulnerabilità. Se si va qui infatti con un dispositivo vulnerabile il lucchetto si chiuderà.

Se invece ci andiamo con Firefox comparirà, correttamente, questo messaggio di errore

SSL ERROR

Ovviamente il bug è gravissimo, e bene ha fatto Apple a far uscire quanto prima un aggiornamento, che va installato il prima possibile. Tra l’altro pare che i Mac siano ancora vulnerabili a questo rischio.

Dicevo che la seconda lezione è che è urgente risolverlo quanto prima, anche di venerdì sera di quello che era un tranquillo fine settimana di febbraio.

Il motivo lo abbiamo appena visto, un attacco al trust va risolto quanto prima perché è uno dei punti più critici dell’uso di internet.

Il problema però è anche che una volta che questo tipo di vulnerabilità sono note a tutti, cioè esce la patch, diventa esponenzialmente più rischiosa.

Mentre prima infatti era uno zero day noto a un numero ignote di persone, potenzialmente da nessuno al di fuori di Apple a tutta la comunità di cyber criminali mondiali.

La pubblicazione della patch però rende del tutto pubblica la vulnerabilità, anche a chi non era interessato a conoscerla (o a comprarla). Questo genera un aumento di rischio perché chi ha cattive intenzioni sa che

  1. c’è un buco sfruttabile (più o meno facilmente) su una marea di dispositivi
  2. gran parte di quei dispositivi sono ancora vulnerabili all’attacco

Praticamente la situazione ideale sia per gli hacker professionisti sia per gli script kiddie che si scaricheranno il tool o il modulo di Metasploit.

Tanto è vero che il giorno dopo il Patch Tuesday di Microsoft, quando appunto un gran numero di vulnerabilità viene pubblicato, c’è il giorno gergalmente chiamato Bloody Thursday dove vengono sfruttate selvaggiamente (in the wild) tutte le debolezze di tanti sistemi che sicuramente non avranno ancora installato la patch.

E questo è valido in particolare per le strutture aziendali, dove necessariamente le patch hanno un ciclo di approvazione e controllo.

Paradossalmente sono più deboli di un dispositivo personale come il mio, che ho aggiornato qualche minuto dopo l’uscita dell’aggiornamento.

Sempre mantenendo quindi la capacità di ragionare, vanno attivate comunque delle contromisure rapide, e installata la patch il prima possibile.

Soprattutto se, come in questo caso, il rischio sta alla base di tutto: il trust.

P.S. da oggi Glamis on Security cambia tema, aggiornando la grafica per più leggerezza e semplicità di lettura. Spero vi piaccia.

Annunci

Non è andata come solito…

Del Pwn2Own avevo parlato giusto un anno fa, ma si è appena conclusa l’edizione 2012. Ci sono delle novità, anche se nel segno del discorso che avevo affrontato lo scorso anno.

Con una grossa sorpresa però. Ma andiamo con ordine.

Stavolta il primo a cadere è stato Chrome (ad opera dei soliti Vupen).
Ma quella che potrebbe apparire come una notizia disarmante (e infatti c’è stata parecchia ironia da parte della stampa non specialistica), in realtà rientra in una specifica strategia che Google ha adottato di recente. E lo ha fatto anche con lanci abbastanza clamorosi, come promettere un milione di dollari (in totale) come ricompensa per trovare delle falle di, appunto, Chrome. La ricompensa era inserita nella cosiddetta “Pwnium challenge“, un evento collaterale al Pwn2Own vero e proprio, dovuto principalmente ad un cambio di regole della competizione “ufficiale” che ha creato qualche rosicata polemica con qualche partecipante storico, che infatti non si è presentato.

In ogni caso, analogamente a quanto detto per Microsoft lo scorso anno, Google ha riproposto la stessa attenzione verso la scena hacker, considerando i ricercatori di sicurezza una risorsa, non una minaccia.

Per la cronaca Vupen ha bucato anche IE9, e Firefox è caduto per uno zero-day a cui ha lavorato anche un ricercatore italiano Vincenzo Iozzo, e mi sembra giusto segnalarlo.

Ma ho parlato di una sorpresa prima, già.
La sorpresa è che nessuno ha provato a bucare Safari.

Già, proprio così. Sarà stato il cambio delle regole, sarà stata la taglia messa in campo da Google, chissà. Fatto è che nessuno aveva pronto un attacco per il browser della mela.

Dopo quanto detto questo cosa vuol dire? Diverse cose.
Che nessuno aveva tempo per trovare uno 0day per Safari. Trovare queste vulnerabilità non è facile, richiede tempo e fatica. Oppure che la versione attuale è davvero sicura? Ovvio che no, niente è abbastanza sicuro da resistere a lungo, e prima o poi i buchi escono fuori.

Il mio parere è che la strategia di Apple, in merito a come gestire la sicurezza dei suoi software (per quanto fatti bene), era e resta errata. Ma staremo a vedere…

Bye!

E alla fine caddero entrambi…

… ma Safari per primo.

Avevo parlato qualche giorno fa del pwn2own e della strategia di Microsoft, ora a evento concluso si possono analizzare i risultati, con un occhio di riguardo ad Apple.

Sì perché anche stavolta il primo a cadere è stato il browser della mela, non sotto i colpi della coppia Miller/Dai Zovi, ma da parte del team di Vupen Security. Nonostante i disperati tentativi di Apple di inviare un gran numero di patch, Vupen scriveva sul suo Twitter:

Apple has just released Safari 5.0.4 and iOS 4.3 a few minutes before the pwn2own contest. This breaks some exploits but not all !!

Chiarisco una cosa. I browser vengono “freezati” qualche giorno prima della gara, questo per permettere ai partecipanti di avere una piattaforma certa su cui fare i test. Ora i rilasci massivi di patch non servono ovviamente ad impedire il pwn, ma piuttosto a far dire al produttore “ah, vedi, quello 0day l’ho già risolto ieri!“. Questa è ovviamente un’utopia, poiché un ricercatore ha diverse vulnerabilità nel caricatore, quindi alla fine riuscirà lo stesso a bucare il sistema. Magari ci metterà solo più tempo (o magari no, se usa subito quella buona). Quindi anche qui la corsa al fix è totalmente inutile, se non dannosa per l’immagine.

Per quanto riguarda la sicurezza infatti, Apple non è mai stata molto attenta aperta. Questo nasce principalmente dal fatto che fino a OS X, MacOS è stato un sistema molto chiuso e particolarmente sicuro. Anche perché non c’era molto hype attorno all’azienda di Cupertino.

Poi torna Jobs, c’è l’esplosione nel mercato consumer e tutti iniziano a sfoggiare il logo della mela argentata. E tutti iniziano ad interessarsi ai sistemi Apple, che nel frattempo sono diventati Unix-like, quindi più aperti, più a rischio…

Proprio i due ricercatori citati sopra, Charlie Miller e Dino Dai Zovi, vincitori dei tre precedenti pwn2own contro i sistemi Apple, hanno recentemente rilasciato una lunga e dettagliatissima intervista al sito The H Security, in cui partono subito dicendo:

From a targeted attack, however, it has been my experience that finding and exploiting vulnerabilities in Mac OS X is significantly easier than doing so in modern Windows systems (Vista and 7).

E questo è il primo problema. Perché magari è più “sicuro” Mac OS relativamente allo share di mercato inferiore a Windows, ma Microsoft ha fatto sicuramente più passi avanti nella sicurezza dei suoi software.

Parliamoci chiaro Apple dettaglia bene le falle di sicurezza coperte da un aggiornamento, però nel contempo, puntando come sempre a lanci di marketing, non riesce a trasmettere un immagine trasparente agli utenti. Non ci sono bollettini, non ci sono blog e comunità.
Questo porta spesso a pensare di essere più sicuri di quanto in realtà non sia, se poi aggiungiamo qualche passo falso dovuto a mancanza di strategia, appunto, la situazione non è delle migliori.

Il vivere di rendita spesso può provocare molti più danni di quanto non sembri, sia perché se si espongono troppe superfici di attacco prima o poi si viene bucati, sia perché cullarsi sugli allori spesso fa scordare che bisogna lavorare sempre duro.

La chiusura totale può tuttavia anche portare dei vantaggi. Penso all’AppStore ad esempio. Per accedere alla vetrina delle applicazioni per iOS bisogna sottoporre l’applicazione al vaglio di Apple, che ne certifica la bontà. Questa, parliamoci chiaro, è una feature di sicurezza, vedi quello che è successo all’Android Market. Certo, come al solito la chiusura di Apple ha portato numerosi problemi in passato (e molti malumori tra gli sviluppatori anche oggi), però come dicono gli stessi Miller/Dai Zovi:

Having a central location for applications that is monitored in some way by Apple makes it harder for malware authors to get their code out if users start only using the Mac App Store for downloads.

Certo, se poi andiamo di jailbreak e programmi craccati, allora fatti vostri… perché alla fine l’utente è sempre la minaccia più grave.

Quello che mi auguro di vedere da Apple è una maggiore apertura sui temi di sicurezza, perché l’obscurity, ha i suoi vantaggi, ma secondo me continua a dimostrare un timore di fondo nell’affrontare la materia. E questo è indice di scarsa maturità.

Bye!