La notizia più importante sulla sicurezza informatica della scorsa settimana è quella relativa all’attacco contro Lastpass, il popolare (e consigliato da quasi tutti gli esperti del settore) password manager remoto.
Archivi tag: navigare in sicurezza
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
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
- c’è un buco sfruttabile (più o meno facilmente) su una marea di dispositivi
- 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.
Come attivare l’autenticazione a due fattori su LinkedIn e Twitter
Avevo già parlato sia del perché sia molto importante utilizzare un sistema di autenticazione a due fattori per i servizi web, in particolare i social network, sia del fatto che i recenti attacchi a Twitter e LinkedIn potevano essere evitati (o per lo meno mitigati) proprio attivando questa funzionalità. Che su quei due social network però mancava.
Dopo qualche mese dagli attacchi, per fortuna sia Twitter che LinkedIn hanno reso disponibile ai propri utenti un sistema di verifica dei login.
Praticamente usano lo stesso metodo: registrate un numero di cellulare e loro vi inviano un SMS con un codice da usare dopo aver inserito username e password.
Vediamo meglio come abilitare questa funzionalità.
Prima di tutto un consiglio: se avete già associato al vostro account Twitter un numero di cellulare rimuovetelo prima di attivare questo servizio. Sembra ci sia un bug, quindi si fa molto prima a togliere tutto e ricominciare da capo.
Abilitare il tutto è molto semplice, basta cliccare sull’ingranaggio in alto a destra, andare su Impostazioni, e selezionare l’opzione Richiedi un codice di verifica all’accesso
Dovrete quindi inserire un numero di telefono cellulare, verificarlo inviando un SMS a Twitter, e successivamente potrete abilitare l’invio del codice
Tutto abbastanza semplice.
Come già disponibile prima, inoltre, potrete selezionare quali avvisi ricevere sul vostro cellulare via SMS o se abilitare la funzionalità di SMS-twitting.
Anche su LinkedIn la procedura è simile.
Riporto qui la versione inglese del sito, uso quella perché la versione in Italiano ancora non ha recepito gli ultimi cambiamenti grafici.
Basta cliccare sul proprio account in alto a destra, andare su Privacy and Settings –>Account –>Manage security settings e arrivare a questa schermata
Oltre a poter abilitare l’SSL (e fatelo immediatamente, anzi installate HTTPS Everywhere) potrete attivare la funzionalità di invio del codice di verifica.
Va quindi registrato un numero di cellulare, ed è fatta.
E ora?
E ora basta!
Da questo momento ogni volta che vi loggherete in questi due servizi con username e password vi verrà inviato un codice via SMS
Ovviamente questo sistema non è esente né da rischi né da scomodità.
La scomodità principale è quella di avere copertura telefonica per ricevere, almeno in tempi brevissimi, l’SMS. E a volte, soprattutto all’estero, questo è un problema.
La speranza è quella che sia Twitter che LinkedIn seguano quanto fatto da Google e Facebook, utilizzando un generatore di codici all’interno magari delle loro app per smartphone.
In ogni caso è un primo passo, semplice ma molto importante, per essere un po’ più sicuri in rete su questi due servizi molto usati.
Bye!
Ancora su signorotti, vassalli e cloud
Lo scorso articolo, Se la sicurezza la garantisce il signorotto, ha iniziato un interessante dibattito, in particolare sul gruppo LinkedIn Italian Security Professonial (gruppo che consiglio a tutti gli addetti ai lavori perché ci sono sempre contenuti e discussioni molto interessanti).
In ogni caso vorrei chiarire qualche altro punto emerso dall’analisi che avevo fatto, continuando a leggere quello che hanno scritto Schneier e Morozov.
Sicuramente la filter bubble di un motore di ricerca fa subito storcere il naso, e contribuisce ad inquadrare il problema in tutta la sua gravità. Se non altro perché è una cosa che impatta immediatamente sulla nostra vita, visto che cerchiamo le cose su Google diverse volte al giorno.
Però il discorso, in particolare quello di Schneier è un po’ più ampio, e riguarda anche i servizi che i vari signorotti erogano “gratis”. Spesso sottovalutati, o usati marginalmente, sono poi in realtà il modo più forte che i provider hanno per applicare le loro regole ai loro clienti, sia come funzionalità che, soprattutto, come rischi di perdite di dati, lock-in e tutto quanto il resto.
Quindi i servizi cloud sono da evitare come la peste? Direi di no, come in tutte le cose c’è sempre un lato positivo, o in questo caso utile. Basta ovviamente ragionare e avere consapevolezza di dove si vanno a mettere i propri dati.
Continua infatti Bruce:
Feudalism is good for the individual, for small startups, and for medium-sized businesses that can’t afford to hire their own in-house or specialized expertise. Being a vassal has its advantages, after all.
Ed ha ragione. Non dimentichiamo che la forza di tante piccole startup, o aziende che tentano di aggredire nuovi settori di mercato, è proprio quella di azzerare (o quasi) i costi dei servizi IT. Perché con un abbonamento light o addirittura free a Google Apps, Salesforce, Dropbox o similari, si hanno comunque servizi efficienti, disponibili ovunque e, soprattutto, rapidi.
La rapidità di risposta e di azione è infatti la chiave del successo per una startup, e i servizi cloud possono supportarla in maniera eccellente. Se n’è accorto anche Forbes, che l’anno scorso nell’articolo How Cloud Computing is Fueling the Next Startup Boom scrive:
There was a time when launching a serious startup required serious capital. Seed money was required for hiring talent, marketing and promotion, office space, and for technology to make it all happen. The technology portion of the equation is suddenly diminishing, dramatically. Thanks to cloud computing and social networking resources, it now costs virtually pennies to secure and get the infrastructure needed up and running to get a new venture off the ground.
Ecco, questo è il punto di forza dei signorotti. E mi sembra chiaro che alla fine i conti non possono che essere a loro vantaggio, proprio perché gestire gli stessi servizi in proprio è fuori dal budget di una startup. Senza contare che oltre a soldi, un’infrastruttura IT in grado di supportare una grossa azienda è lenta nell’adeguarsi ai cambiamenti di mercato, spesso dipende da tante diverse componenti aziendali in contrasto tra loro e per questo non sempre è di ausilio al business, anzi…
Ovvio che, tornando al tema principale, non tutto è rose e fiori. Scheier dice appunto che:
Yet feudal security isn’t without its risks.
E i rischi sono proprio quelli che vanno considerati per primi e come quelli più importanti, perché visto che non c’è trattativa col signorotto, lui fa come vuole per “proteggere” i propri vassalli, anche contro la loro volontà.
Schneier infatti cita il caso in cui Amazon ha segato l’account Kindle di un cliente per un problema di residenza, o la brutta storia di come Matt Honan fu colpito da cybercriminali che hanno proprio sfruttato le vulnerabilità incrociate dei vari signorotti.
The very four digits that Amazon considers unimportant enough to display in the clear on the Web are precisely the same ones that Apple considers secure enough to perform identity verification.
Proprio come il sistema feudale, l’unico proprietario di tutto (prima erano le nostre vite, ora sono i nostri dati) è il signorotto. Che agisce ovviamente nel suo unico interesse, a maggior ragione perché ora queste sono entità commerciali, quindi lo scopo non è tanto allargarsi su quello o quel terreno per arrivare alla corona.
Lo scopo che loro hanno è far soldi.
E magari se gli serve possono anche venderli, i loro vassalli. Bruce cita un paio di casi ma io mi rifaccio ad un bell’articolo di Matteo Flora, Non usate Google se siete una ONG, in cui fa due osservazioni non di poco conto:
- Google collabora nel 95% dei casi con le autorità americane, ma solo nel 60% con quelle italiane
- Se avete le vostre mail su Google sappiate che la tutela italiana (con ordine di un magistrato) non conta nulla e che potreste essere sottoposti a controllo senza che nemmeno lo sappiate
Ecco queste sono cose da sapere, prima di affidarsi alle amorevoli cure del signorotto. Sono discorsi molto complessi, lo ammetto, però sono necessari a coltivare una consapevolezza nell’uso degli strumenti (chiamiamoli cloud, web2.0 o come volete).
Perché si fa presto a fare un bel filmato di marketing e mostrare come è facile usare questo o quel servizio, solo che dopo possono insorgere insidie inaspettate, sulle quali la vostra ragione non verrà quasi mai considerata valida.
Molte cose non si possono conoscere a priori certo, Morozov da come improbabile la pubblicazione di certi metodi di filtraggio o di certi algoritmi, ma si augura che vengano almeno mostrati ai chi è incaricato di arbitrare la situazione:
Silicon Valley wouldn’t have to disclose its proprietary algorithms, only share them with the auditors. A drastic measure? Perhaps. But it’s one that is proportional to the growing clout technology companies have in reshaping not only our economy but also our culture.
Mentre la chiosa finale di Schneier è un po’ più drastica, soprattutto sul ruolo di controllo e bilanciamento delle forze che dovrebbero avere i governi in questo campo (che poi però sono i primi a cui fa comodo una corsia preferenziale di controllo sui contenuti ospitati dai signorotti):
But these days, government has largely abdicated its role in cyberspace, and the result is a return to the feudal relationships of yore.
Schneier conclude ripetendo che la sicurezza è un trade-off. Chi lavora in questo settore lo sa da sempre, come sa che non esiste un sistema 100% sicuro. Ed è per questo che molte aziende non firmano contratti con provider di questo tipo a cuor leggero, preferendo magari sistemi sviluppati in casa, sui cui si ha il pieno controllo. Anche a costo di sacrificare soldi e velocità nel seguire i flussi di business.
Questione di scelte certo. Ma fare una scelta presuppone avere gli strumenti, le conoscenze e la consapevolezza di farle.
Non tutti ce l’hanno, soprattutto in questi tempi in cui tutto è a disposizione “gratis”.
Io penso comunque che si sta sviluppando una consapevolezza di questo tipo, un awareness rispetto a chi ci offre qualcosa facendoci vedere solo quanto è bella e armata la cittadella fortificata, quanto sono organizzate le guardie e quanto è ricco il mercato dentro. Senza dirci però che, una volta dentro, non possiamo più uscire.
In fondo una parte di questa consapevolezza di come stanno le cose, buona o cattiva che sia, si chiama hacktivistm.
Bye!
Se la sicurezza la garantisce il signorotto…
… poi decide lui cosa fare e cosa non fare.
Recentemente sono usciti due articoli che analizzano le modalità con cui viene erogata oggi la sicurezza sul web, e la riconducono ad un sistema medievale di gestione.
Il primo articolo è di Bruce Schneier, e si intitola appunto Feudal Security.
Il secondo è di un altro osservatore molto attento della rete e dei suoi meccanismi, Evgeny Morozov, e tratta più o meno lo stesso concetto ma focalizzato più sui rischi reali, si intitola You Can’t Say That on the Internet.
Andiamo con ordine e cominciamo con il pezzo di Schneier.
Fondamentalmente lui paragona lo stato attuale della sicurezza in rete con quello che succedeva nel medioevo. Cioè che le persone, i vassalli, per essere sicuri in un tempo e luogo che presentava altissimi pericoli, si alleavano al signorotto locale e andavano nella sua cittadella, o territorio a seconda della forza.
La cittadella era ben chiusa da mura resistenti e difesa da corpi di guardia armati fino ai denti, dentro tutto era tranquillo e ognuno poteva vivere la sua vita senza preoccuparsi di briganti, assassini, ladri o altro (almeno fino alla prossima guerra).
Feudalism provides security. Classical medieval feudalism depended on overlapping, complex, hierarchical relationships. There were oaths and obligations: a series of rights and privileges. A critical aspect of this system was protection: vassals would pledge their allegiance to a lord, and in return, that lord would protect them from harm.
Già vediamo qualcosa che non ci piace. I vassalli infatti dovevano giurare alleanza al signorotto che gli offriva protezione. Dovevano sottostare ai suoi obblighi ed alle sue regole.
Certo, in cambio avevano una sicurezza imbattibile per l’epoca. Ma avevano scelta? No.
Non potevano fare a meno di porsi gerarchicamente sotto al signorotto, e accettare le sue regole e i suoi obblighi senza fiatare. Perché è lui che decide. Dai vassalli in giù ci sono solo sottoposti, che non hanno nessun titolo per parlare o decidere alcunché.
Questo modello, trasportato pari pari alla situazione attuale, è rimasto pressoché immutato.
Some of us have pledged our allegiance to Google: We have Gmail accounts, we use Google Calendar and Google Docs, and we have Android phones. Others have pledged allegiance to Apple: We have Macintosh laptops, iPhones, and iPads; and we let iCloud automatically synchronize and back up everything. Still others of us let Microsoft do it all. Or we buy our music and e-books from Amazon, which keeps records of what we own and allows downloading to a Kindle, computer, or phone. Some of us have pretty much abandoned e-mail altogether … for Facebook.
Tutti sono diventati vassalli di qualche signorotto, tutti permettono che lui decida cosa possono o non possono usare, scaricare, leggere e sentire. Lui decide come erogare i servizi e come cambiarli a suo piacimento. Solo lui conosce e applica le sue regole e gli obblighi verso gli utenti. Non c’è confronto, non c’è democrazia, non c’è scelta.
In cambio, tutti hanno sicurezza, affidabilità, servizi “gratuiti” ovunque nel mondo.
Ma una volta non era così, una volta la sicurezza era scelta e applicata dall’utente.
Traditional computer security centered around users. Users had to purchase and install anti-virus software and firewalls, ensure their operating system and network were configured properly, update their software, and generally manage their own security.
Questo modello non è più attuale secondo Schneier, il mondo è diviso in due grossi filoni di signorotti che offrono servizi, e relativi vassalli:
- i dispositivi che portiamo con noi, di cui il signorotto ha pieno controllo, sia hardware che software (Apple, Amazon);
- i servizi online che tengono i nostri dati, senza che noi sappiamo dove o come (Google, Yahoo!, Dropbox).
In pratica abbiamo delegato il controllo sui nostri dati (e anche su un pezzo delle nostre vite) ad altri. Siamo il vassallo che si affida anima e corpo al signorotto, che compra il suo hardware proprietario, che non può toccare il suo software, che non sa come funzionano i suoi servizi. E lì vive la propria vita affidando ad altri la propria sicurezza.
E qui entra in campo l’analisi fatta da Morozov.
Che spiega in cosa consiste questa delega in bianco. Consiste nel fatto che il signorotto fa quello che vuole per proteggerci.
Sembra scontato, ma non lo è quando poi ci troviamo di fronte a casi reali.
Apple, too, has strayed from its iconoclastic roots. When Naomi Wolf’s latest book, “Vagina: A New Biography,” went on sale in its iBooks store, Apple turned “Vagina” into “V****a.” After numerous complaints, Apple restored the title, but who knows how many other books are still affected?
The proliferation of the Autocomplete function on popular Web sites is a case in point. Nominally, all it does is complete your search query — on YouTube, on Google, on Amazon — before you’ve finished typing, using an algorithm to predict what you’re most likely typing. A nifty feature — but it, too, reinforces primness.
Chiaro? Gli strumenti che usano i signorotti per proteggerci (Morozov cita Impermium) lo stanno davvero facendo? O stanno forse racchiudendo l’utente in una bolla, una sandbox in cui non può farsi male nessuno, non ci sono rischi né tantomeno pericoli.
Ma solo perché l’utente fa quello che vuole il signorotto. Vede solo quello che decide lui e come lo decide lui. Senza che nessuno possa dire nulla, o decidere più nulla.
Until recently, even the word “bisexual” wouldn’t autocomplete at Google; it’s only this past August that Google, after many complaints, began to autocomplete some, but not all, queries for that term. In 2010, the hacker magazine 2600 published a long blacklist of similar words. While I didn’t verify all 400 of them on Google, a few that I did try — like “swastika” and “Lolita” — failed to autocomplete. Is Nabokov not trending in Mountain View? Alas, these algorithms are not particularly bright: unable to distinguish between Nabokov’s novel and child pornography, they assume you want the latter.
Il signorotto è il nostro guardiano. Lui decide cosa dobbiamo cercare e in che modo e, visto che noi gli abbiamo giurato alleanza, non potremo che non trovare più quello che cerchiamo veramente.
O magari lo troviamo, ma per quanto tempo ancora?
Google potrebbe decidere che la funzione di autocompletamento non è abbastanza sicura per noi. Potrebbe escludere del tutto il risultato dalla ricerca. E non troveremmo mai più Nabokov, come oggi i cinesi non trovano più informazioni sui fatti di piazza Tien An Men.
Ma la Cina è un cattivo regime dittatoriale. Noi no, noi viviamo in democrazia…
Bye!
Aggiornamento: la seconda parte di questo post la trovate qui.
Glamis on Security 