La sicurezza è un trade-off, anche in volo

scatola nera

Bureau d’Enquetes et d’Analyses, via Associated Press

Adoro la sicurezza aerea.

L’adoro perché la ritengo la massima espressione di metodologie e tecniche di sicurezza che l’umanità abbia (per ora) mai raggiunto.

Questo perché

  • lavora contro natura: volare è una delle poche cose che gli umani non possono fare, quindi farlo significa andare fondamentalmente contro la nostra natura,
  • salva realmente delle vite: se un aereo cade, muoiono tutti (non sempre,m ma chi vuole sfidare le probabilità?),
  • coinvolge tantissime persone: magari la sicurezza aerospaziale può essere migliore, ma di sicuro riguarda molte meno persone,
  • ha una capacità incredibile di trovare e applicare le lessons learned: gli investigatori di sicurezza aerea sono tra i migliori al mondo, sangue freddo, esperti reali e riconosciuti, e sempre mirati a trovare la causa del perché si è verificato un incidente,
  • è pragmatica: il focus è sempre risolvere il problema nel modo più rapido possibile, e trovare la soluzione migliore affinché l’incidente non si ripeta mai più,
  • ha conseguenze enormemente visibili: tutti odiano la sicurezza aeroportuale, no?

Ma, come tutte le metodologie di sicurezza nel mondo, implica sempre un trade-off.
Necessita sempre di trovare un equilibrio.

Continua a leggere

Annunci

L’intelligence italiana usa FinFisher?

Torno a parlare dell’attività dei nostri servizi di intelligence, sempre in seguito a leak di informazioni.

L’altra volta si trattava della pubblicazione di indirizzi non proprio nascosti, ma nemmeno tanto pubblici, usati per ricercare fonti OSINT e poi divenuti OSINT loro stessi.

Stavolta si tratta di cose molto più serie, come seria è la fonte: Wikileaks.

Continua a leggere

I pericoli della localizzazione

Sviluppare una buona applicazione è già di per se un lavoro molto complesso, localizzarla ancora di più.

Nella migliore tradizione del tradurre è sempre un po’ tradire è possibile commettere degli errori, più o meno gravi, specialmente quando si fanno le cose in fretta o senza riflettere troppo.

Uno di quelli più famigerati (e che ancora oggi provocano danni) è senza dubbio la localizzazione errata fatta da Microsoft in Outlook dei prefissi delle email di risposta.

Tanto per essere chiari è il motivo per cui alcune mail (in Italia) hanno nel subject una fila di R: RE: R: RE: RE: FW: I: RE: e così via. In altri paesi ci sono ancora altri prefissi. La storia è molto complessa, qui MailMate fa un ottimo excursus (visto che si parla anche di prefissi latini).

In questo caso però un problema di localizzazione ha provocato solo il classico fastidio dovuto all’evidente impossibilità di interoperare, se non si trova un linguaggio comune. Che nell’informatica è l’inglese, punto.

A volte però la localizzazione potrebbe provocare problemi più gravi di fastidi lessicali, potrebbe provocare problemi di sicurezza.

Per analizzare un caso reale, prendiamo il popolare lettore di PDF Foxit Reader.

foxit reader

Foxit è il principale concorrente di Adobe Reader, e uscì sul mercato qualche anno fa puntando proprio su una sua maggiore leggerezza rispetto al mammuth di Adobe, e su una sua maggiore sicurezza nel gestire i PDF.

È bene sempre ricordare che i PDF sono la fonte principale per la diffusione del malware, essendo un veicolo privilegiato, fragile ed efficiente, per far girare codice malevolo sul computer bersaglio dell’attacco. Vanno quindi sempre trattati con prudenza e se non si conosce il mittente non vanno mai aperti. Anzi, se usate servizi di webmail come Gmail è sempre bene visualizzarli prima col browser e non scaricarli se c’è qualcosa che non va.

Proprio per questo motivo è necessario che le applicazioni che li leggono siano aggiornate costantemente, per evitare possibili attacchi. E il reader di Foxit, così come quello di Adobe, non sono da meno.

E qui vengono i problemi. Perché Foxit Reader, partito solo in inglese, per espandere i suoi utenti è ora disponibile in più lingue.

Se lo andiamo a scaricare, vediamo questa finestra

Foxit Reader Inglese

foxit english

 Foxit Reader Italiano

foxit italian

Foxit Reader Francese

foxit french

La vedete la differenza? Esatto la versione nelle altre lingue è inferiore. E questo significa automaticamente che è più vulnerabile.

Quindi vuol dire che se una persona non inglese sta usando (come è comprensibile) Foxit Reader nella propria lingua madre è più vulnerabile.

Tra l’altro non so se notate ma le versioni localizzate sono un po’ più pesanti di quella in inglese, il che deriva probabilmente dai file di localizzazione.

Quindi il lavoro è stato fatto bene, il “core” dell’applicazione resta stabile e per localizzarla si usano file specifici, con i dizionari ad hoc, richiamati poi dinamicamente. In questo modo non solo è facile tradurre in qualsiasi lingua, ma non si fa l’errore di rendere hardcoded un qualcosa di dinamico.

Da quello che sembra quindi il ritardo non è tanto nell’aggiornamento del codice base di Foxit, quanto del packaging delle versioni localizzate. Ma per l’utente finale cambia poco, sempre a rischio è.

Ricordo uno scenario simile anche per le prime installazioni di WordPress.org. Quando usciva una nuova release (e ne uscivano parecchie man mano che diventava più popolare, quindi più attaccato), chi aveva installato la versione di WordPress Italy doveva aspettare che uscisse la versione localizzata.

Con il rischio naturalmente di essere colpiti per primi.

Con l’evoluzione del codice i dizionari di localizzazione sono stati sempre più spostati fuori dal codice base del programma, rendendo molto più immediato un suo patching.

Firefox ad esempio fa uscire le nuove release contemporaneamente in tutte le 80 e più lingue supportate. Perché appunto ha una gestione dei language pack molto ben fatta.

Senza dubbio è importante che una software house aggiorni costantemente i propri prodotti. E non annoiatevi quando vi si chiede di fare un update, fatelo è per la vostra sicurezza.

Non è corretto però che la software house, specialmente se punta proprio sulla sicurezza, lasci i suoi utenti non anglofoni in balia di possibili rischi. Non importa se per pochi giorni o per poche ore, il rischio c’è sempre.

Il consiglio quindi è ancora quello di aggiornare tutto appena possibile ma, più importante, usare i software solo in inglese.

Se questo vi da noia, e se chi pubblica il vostro programma preferito non aggiorna tutto allo stesso momento, cambiate programma.

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.

La roba Microsoft é la più bucata! Ehm… quasi

Leggevo con colpevole ritardo il report degli NSS labs sull’andamento delle vulnerabilità (qui il PDF).

Molto interessante è questa tabella (cliccate per ingrandire) che riporta i vendor maggiormente colpiti da CVE, facilmente exploitabili nello scorso anno.

Top Vulnerabilities

Top 10 vendors with highly critical, easy to exploit vulnerabilities – Fonte NSS Labs

La prima cosa che salta subito agli occhi è che, come riportato dal titolo, il software Microsoft è solo decima in classifica. E per giunta è colpita solo dall’1% di tutti i CVE emessi nel 2012.

Sfatiamo subito un mito quindi, un luogo comune un po’ datato ma ancora in voga. Purtroppo anche tra i professionisti e gli addetti ai lavori.

La seconda cosa che risulta guardando l’analisi di NSS è che i sistemi operativi non sono i più colpiti. I primi posti della classifica sono infatti coperti da software ordinario, middleware o plug-in di altri programmi.

Queste due cose messe insieme (il mito di Windows colabrodo e il fatto che siano più facilmente vulnerabili browser e plug-in) provocano un effetto devastante nella gestione ordinaria della sicurezza delle nostre postazioni di lavoro. Sia a casa che, soprattutto, in azienda.

Addirittura devastante come effetto? Eh sì.

Sì perché le informazioni e i dati sono un innesco fondamentale per definire le policy e le azioni legate alla sicurezza informatica, sia essa aziendale o personale.

Partire quindi da pregiudizi, o ancora peggio da informazioni totalmente sbagliate causa delle politiche di sicurezza altrettanto sbagliate, e questo a sua volta apre dei buchi nella nostra (già fin troppo fragile) linea di difesa.

Abbattere il pregiudizio guardando quella tabella non solo è essenziale per rimettere le cose in carreggiata, ma soprattutto per focalizzare la nostra attenzione sui posti dove veramente abbiamo un problema.

Fin troppo spesso infatti le politiche di aggiornamento dei vari asset aziendali spingono su patch di Windows, agent antimalware, agent personal firewall e chissà quale altra amenità.

Poi però abbiamo postazioni di lavoro e, peggio, server su cui gira Firefox 3.6.
Oppure utilizziamo ancora applicazioni che richiedono obbligatoriamente di usare una bella Java versione 5.0.

O, peggio ancora visto che sono i primi della lista, non abbiamo nessuna procedura che controlli l’aggiornamento costante di Flash o di Acrobat Reader. E il secondo è il posto dove passano tutti i PDF che arrivano, e i PDF sono un veicolo fondamentale per diffondere malware e altra robaccia.

L’analisi di questo tipo di rapporti, il leggere attentamente i numeri e i confronti, è e deve essere attività essenziale per chiunque si appresti a definire le proprie politiche di sicurezza. Siano quelle di una realtà con quattro PC o quelle di un’azienda con decine di migliaia di postazioni.

Purtroppo anche i professionisti più navigati cadono spesso in errori di questo tipo. Anzi, spezzo una lancia, in fondo se lo meritano, ci cadono proprio perché applicano ancora modelli non aggiornati alla realtà attuale, che prevede ulteriori fattori (come la facilità di esecuzione di un attacco) e contesti diversi (ad esempio l’uso o l’esposizione di rete di un certo asset o servizio).

I prodotti Microsoft, e Windows in particolare, hanno sì’ comunque un elevato grado di vulnerabilità e sono pesantemente attaccati. Guardiamo la tabella (cliccate per ingrandire) di confronto sulle vulnerabilità comprate dai programmi ZDI e VCP negli ultimi 10 anni.

Top 10 vendors

Top 10 vendors for which ZDI & VCP purchased vulnerabilities since 2001 – Fonte NSS Labs

Microsoft fa sicuramente la parte del leone in questo caso, ma questo dato mostra due cose principalmente:

  • la “facilità” di attacco dei suoi prodotti
  • l’elevato interesse che ricercatori e hacker hanno nei suoi riguardi (infatti la seconda è Apple).

Ma come usare questo dato allora? Non significa però necessariamente che tutte quelle vulnerabilità siano di elevata criticità, né che siano, come detto nella prima tabella, facilmente utilizzabili per bucare qualcosa.

Quindi è vero che i grandi numeri restano “onori” di alcuni vendor in particolare, ma guardare solo i numeri non serve.

Va sempre considerato il contesto, altrimenti richiamo di focalizzarci solo su un prodotto che ha sì un gran numero di vulnerabilità, ma magari di basso livello o molto difficili da sfruttare. Oppure ci sforziamo molto per proteggere sistemi già protetti da altre cose (come ad esempio i sistemi di protezione perimetrale, o il prodotto antimalware), mentre poi lasciamo utilizzare agli utenti degli altri software di uso quotidiano, mai aggiornati e con plug-in obsoleti e pericolosi.

E in più, in questo scenario già di per se inquietante, quegli stessi software sono estremamente facili da bucare. Basta andare su qualche forum e trovare dei programmi già pronti.

Ecco, la chiave di lettura di utilissimi report come quello di NSS deve essere appunto quella di prendere i numeri con grande spirito critico, mettere in dubbio costantemente le proprie certezze, e cercare di capire dove sta realmente il problema.

E potrebbe non essere il primo della lista, visto che, come diceva Indiana Jones

“X” never, ever marks the spot. 🙂

Bye!

P.S. Molto interessante è il fatto, notato anche dagli analisti degli NSS Labs che nella prima tabella compare anche Advantech, un produttore di sistemi industriali SCADA.

L’attenzione su questi sistemi è in crescita costante secondo NSS Labs infatti

ICS/SCADA vulnerability disclosures increased more than 600% since 2010 and almost doubled from 72 in 2011 to 124 in 2012.

Questo anche perché, come dicono loro stessi, sono emerse nel 2012 nuove tecniche e strumenti per permettere ai ricercatori di sicurezza (sia buoni che cattivi) di scovare meglio falle nei sistemi industriali.

Resta comunque un fronte aperto e pericolosamente in crescita, non solo per lo Stuxnet di cui ha tanto parlato la stampa generalista.