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.
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 è 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
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.
La cyberwar è ormai entrata nella conoscenza di tutti. Un argomento che prima era relegato su qualche tavolo militare, poi a conferenze e discussioni tra esperti del settore, ora è di pubblico dominio sui media generalisti e in qualche caso anche sulle trasmissioni televisive con largo pubblico di spettatori.
Casi molto grandi come nel 2007 l’attacco all’Estonia (forse il primo atto di cyberwar ripreso dai media generalisti), una delle nazioni europee più digitalizzate e con servizi disponibili online. Oppure l’attacco alle centrali nucleari iraniane tramite Stuxnet e recentemente i casi Assange e Snowden hanno portato all’attenzione dell’opinione pubblica un uso militare delle tecnologie informatiche da parte di Stati contro altri Stati (più o meno alleati, come nel caso di PRISM).
C’è sempre stato però, da parte degli stessi governi coinvolti, una specie di pubblica sottovalutazione del fenomeno. Questo avveniva principalmente per non fare troppa pubblicità, ma anche per non svelare apertamente tecniche di guerriglia informatica che comunque rientravano in quella forma di guerra (quasi)fredda moderna che è meglio non portare troppo alla luce.
Questo trend ha avuto una brusca interruzione recentemente.
È notizia di pochi giorni, tramite un’anticipazione fatta da ZDnet, che la NATO ha inserito gli atti di cyberwarfare, cioè le aggressioni ad una nazione tramite attacchi informatici, come riconducibili ad atti di guerra in conformità all’articolo 5 del Trattato Nord Atlantico.
Facciamo una piccola digressione per capire il contesto.
La NATO nasce successivamente alla Seconda Guerra Mondiale, e all’inizio della Guerra Fredda, come associazione di nazioni occidentali (principalmente gli alleati degli USA contro l’ex URSS) pronte ad agire in caso di terzo conflitto mondiale.
L’articolo 5 è quello che forse più di tutti rappresenta il senso del Trattato, dice così
Le parti convengono che un attacco armato contro una o più di esse in Europa o nell’America settentrionale sarà considerato come un attacco diretto contro tutte le parti, e di conseguenza convengono che se un tale attacco si producesse, ciascuna di esse, nell’esercizio del diritto di legittima difesa, individuale o collettiva, riconosciuto dall’ari. 51 dello Statuto delle Nazioni Unite, assisterà la parte o le parti così attaccate intraprendendo immediatamente, individualmente e di concerto con le altre parti, l’azione che giudicherà necessaria, ivi compreso l’uso della forza armata, per ristabilire e mantenere la sicurezza nella regione dell’Atlantico settentrionale. Ogni attacco armato di questo genere e tutte le misure prese in conseguenza di esso saranno immediatamente portate a conoscenza del Consiglio di Sicurezza. Queste misure termineranno allorché il Consiglio di Sicurezza avrà preso le misure necessarie per ristabilire e mantenere la pace e la sicurezza internazionali.
Quindi se una delle nazioni NATO viene attaccata, si presumeva da una nazione del Blocco Sovietico naturalmente, tutte le altre nazioni sono vincolate ad agire di conseguenza, esattamente come se fossero state attaccate loro.
La forza dissuasiva di questo articolo è evidente, una semplice schermaglia poteva essere interpretata come casus belli per un escalation potenzialmente devastante. E quindi fondamentalmente serviva a tenere tutti gli equilibri stabili.
La notizia quindi che gli atti di cyberwar contro una nazione NATO siano equiparabili ad un atto di guerra vero e proprio, con gli aerei e i carri armati, è la prima vera ammissione che questo tipo di attacchi stanno portando gravi problemi alle superpotenze mondiali.
Non solo, significa anche, come giustamente rimarca ZDNET, che questo tipo di attacchi è diventato standard in un conflitto tra due nazioni. Non serve più infatti bombardare gli obiettivi e le infrastrutture critiche di una nazione, quando le si può letteralmente spegnere (o peggio, distruggerle) standosene comodamente in caserma davanti ad un monitor.
Le infrastrutture degli Stati Uniti, ad esempio, sono costantemente sotto attacco informatico, presumibilmente da paesi come la Cina che hanno un fortissimo esercito di cybersoldati che lavorano intensamente per creare disservizi, problemi, perdita di informazioni e quant’altro a paesi non alleati, ma con i quali non sono nemmeno in guerra formale.
Probabilmente questa situazione di schermaglie digitali è stata anche peggiorata dalle dichiarazioni di Snowden. Proprio un articolo di Newsweek qualche mese fa ragionava sul fatto che dopo le dichiarazioni sui programmi di spionaggio dell’NSA, gli Stati Uniti non sono più un interlocutore credibile per la Cina per fermare gli attacchi informatici.
E a buon diritto, infatti la Cina è accusata di compiere attacchi più o meno nascosti, ma anche gli Stati Uniti non possono fare il ruolo della vittima, utilizzando questi metodi, vedi PRISM ma vedi soprattutto Stuxnet. Il virus infatti non ha una paternità ufficiale, ma è evidente che la sua attività di rallentamento del programma nucleare iraniano abbia giovato principalmente a USA e Israele, quindi in questo caso due indizi fanno sicuramente una prova.
Tornando in ambito Europeo/NATO, proprio un attacco come quello fatto all’Estonia, che è membro NATO dal 2004, avrebbe provocato una forte reazione da parte degli altri stati alleati, stavolta non contro la Cina ma contro la Russia, se l’articolo 5 fosse stato interpretato nel senso che gli si vuole dare ora.
Non per nulla l’Estonia stessa è stata, sia per l’attacco senza precedenti che ha subito, sia per la sua struttura di nazione digitale, usata dalla NATO come paese pilota per studiare questi attacchi (e una loro possibile difesa).
Dal 2008 infatti a Tallin è operativo il CCDCOE, NATO Cooperative Cyber Defence Centre of Excellence, che ha come scopo la ricerca, l’analisi e la condivisione delle informazioni all’interno del Patto Atlantico, sui temi della cyberwar.
Devo dire che il materiale prodotto e le persone che ci lavorano sono veramente di alto livello. Ho avuto occasione di incontrare un ufficiale dell’esercito italiano che lavora lì e penso meritino molta più visibilità di quanta non ne abbiano ora, anche all’interno degli esperti di settore.
Questa affermazione quindi è davvero importante, anche per chi si occupa del settore, visto che tutti i paesi NATO, Italia compresa, dovranno necessariamente tenere conto di questo riconoscimento. E dovranno tenerne conto non solo in caso di un evento di cyberwar verso un paese alleato, ma anche e soprattutto nel disegnare le capacità nazionali di identificazione e risposta a questo tipo di eventi, che in futuro saranno sempre e sempre più frequenti.
L’Italia, con qualche incongruenza ma con una velocità ed efficienza notevole per la nostra nazione, ha pubblicato la propria strategia e piano operativo per la cyber security.
Il Piano Nazionale contiene senza dubbio molti spunti interessanti e molti indirizzi strategici formulati correttamente, anche ascoltando chi da anni lavora nel settore e indica per lo meno il tracciato della strada da seguire.
Quindi ora che anche in ambito NATO è rafforzata questa necessità di protezione e risposta, è fondamentale utilizzare la stessa velocità ed efficienza per rendere realmente operative e realmente efficienti le strutture indicate nel piano nazionale.
A volte sembra che il mondo del crimine informatico, sia legato solo alle tecnologie, alla vendita di armi, droga e pedopornogrfia nel deep web.
Tutta roba più o meno da film, che ogni tanto emerge nella stampa mainstream, magari facendo di tutta l’erba un fascio per accusare tecnologie molto importanti che non si comprendono (successe qualche mese fa quando Tor fu accusato di ogni male possibile).
Però il cybercrime, essendo un’emanazione digitale del crimine organizzato fisico (cioè quello che ti brucia il negozio se non gli paghi il pizzo), è sempre molto aggiornato e, soprattutto, legato al mondo reale.
Vediamo quindi di analizzare un esempio molto concreto, partendo da una delle riforme più importanti fatte negli Stati Uniti negli ultimi anni: Obamacare.
Discutendo su LinkedIn, Luca di Abissi ha segnalato come nel deep web ci sia un gran movimento di mercato legato alla compravendita di identità con annesso profilo e informazioni mediche.
Questo è stato poi confermato da esperti nel settore del furto di identità come Robert Siciliano: Healthcare Data under Attack.
Siciliano, citando uno studio dell’Istituto Ponemon, spiega molto chiaramente la situazione
in the world of black market information, a medical record is considered more valuable than everything else
Il mercato delle identità digitali è sempre stato molto florido, in particolare con la facilità con cui è possibile recuperare informazioni in un web popolato di social network. Anzi comprare stock di profili reali, carte di credito o addirittura documenti, per chi frequenta dei market nemmeno tanto nascosti è un’attività facile e abbastanza economica.
Ora però l’asse si è spostato su qualcosa di più pregiato, ovvero le identità complete di una persona ma senza i dati finanziari, bensì quelli necessari a stipulare un’assicurazione medica.
La grande riforma di Obama, essendo fondamentalmente un filtro governativo a tante assicurazioni sanitarie private, ha aumentato a dismisura il valore di queste informazioni e quindi il loro mercato nero parallelo.
Questo accade per il solito fondamentale problema: la mancata protezione di dati personali da parte di chi li tratta.
Ma mentre una carta di credito si può bloccare con una telefonata, e se siamo assicurati riusciamo anche a ottenere un rimborso, con i dati sanitari la cosa cambia drasticamente. Anche perché i numeri di carte di credito nascono e muoiono in poco tempo, il profilo sanitario resta molto più a lungo.
Comprando un’identità sanitaria è possibile infatti presentarsi ad una struttura come se si fosse la persona derubata, e i dati saranno aggiornati su quel profilo.
Se quindi venisse fatto un trattamento ospedaliero particolare, o anche una banale analisi del sangue, i dati sarebbero riportati sul profilo della persona reale. Che ignara di tutto magari si presenterà dopo qualche mese in una struttura sanitaria, necessitando di cure, e potrebbe rischiare grosso qualora nessuno si accorgesse dei dati errati.
Anche potenzialmente la vita.
Questa storia quindi conferma il rischio che la nostra identità digitale, e quindi sempre più quella reale, siano facilmente trafugabili. È sempre più importante quindi porre estrema attenzione al trattamento di dati sensibili come quelli sanitari.
In USA la situazione è davvero a rischio, in Italia per fortuna il Codice Privacy prevede norme stringenti per questo tipo di dati. In ogni caso con la proliferazione di banche dati e dispositivi è fondamentale non perdere mai di vista i rischi che si corrono.
Questo esempio poi conferma anche la sovrapposizione tra crimine “vero” e cybercrime. Cosa che gli addetti ai lavori dicono da anni, ma che ora si sta manifestando sempre di più, minacciando elementi fondamentali della vita di ogni persona, come la salute.
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
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
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
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.
Glamis on Security 