Archivi tag: ios

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.

Vulnerabilità vere e presunte: un esempio

Una delle attività più complesse che un professionista della sicurezza informatica deve fare, soprattutto in un periodo come questo in cui siamo sommersi da informazioni e segnalazioni, è mantenere la capacità di ragionare.

Detta così sembra una banalità, e infatti lo è. Come tutte le cose banali però viene spesso accantonata, dimenticata e sacrificata in nome della fretta, del correre dietro all’ultima patch o di trovare una difesa appropriata all’ultima novità in campo hacker.

Purtroppo questa situazione è fin troppo spesso alimentata dai vendor, che approfittano dell’onda di emergenze, buzzword, articoli improvvisati ma con grande eco della stampa generalista, per vendere l’ultimo prodotto. Che spesso però non serve.

Facciamo un esempio di questa situazione, prendendo spunto da una notizia che si è sparsa parecchio negli ultimi giorni.

Si tratta di un nuova “vulnerabilità” di iOS, che permette di disabilitare il servizio Trova il mio iPhone. C’è anche un video che spiega bene come funziona

Detta così sembra ovviamente molto critica, visto che si tratta di una delle principali funzionalità di sicurezza fornite con iOS. E visto che la notizia ha avuto parecchia eco e grande diffusione sui social (come del resto tutte le notizie di sicurezza che riguardano prodotti Apple) è la tipica notizia che viene sfruttata per creare l’effetto FUD (avevo già parlato del rischio di questo effetto), e magari pubblicizzare il proprio prodotto di gestione di cellulari.

Perché dico sembra? Perché bisogna ragionare, e capire esattamente cosa abbiamo di fronte, e quali rischi reali stiamo correndo. Guardate il video. Come comincia?

Con un iPhone sbloccato.

Ora, ragionando con calma e lucidità (capacità che ogni esperto di sicurezza dovrebbe sviluppare e mantenere costantemente affilate), già questo punto annulla qualsiasi altra vulnerabilità.

Anche senza scomodare la gestione aziendale dei dispositivi mobili, il primo passo indispensabile per mettere in sicurezza il proprio cellulare è attivare il codice di sblocco. Tanto più che si tratta di un iPhone, dove c’è anche la comodità del Touch ID.

Già semplicemente vedendo il primo fotogramma del video abbiamo ridimensionato il tutto, visto che non ha senso parlare di altro, se un ladro che ruba il telefono può avere accesso a tutti i dati e impostazioni senza problema.

Cosa ci insegna questo esempio? Che tutto il rumore fatto da una notizia del genere, si basa su una carenza di sicurezza molto più grande e rischiosa. La vulnerabilità c’è, senza dubbio, ed è anche grave ma non ha senso vedere solo quella, quando si lascia il proprio smartphone alla disponibilità del primo che passa.

Questo esempio è indicativo del modo di ragionare che bisogna sempre mantenere, quello di capire i rischi reali e valutare il contesto. In ambito personale è sempre buona cosa farlo, ma nella sicurezza informatica aziendale è indispensabile ragionare in questo modo.

Anche perché non solo applicheremo un po’ di spirito critico che non fa mai male, ma risparmieremo un bel po’ di soldi per prodotti inutili che, come un caso come questo insegna, non avrebbe comunque risolto il problema di base.