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.

Commenta il post!

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo di WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione /  Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione /  Modifica )

Connessione a %s...