venerdì 14 dicembre 2018

HTTPS: dettagli sulla autenticazione del server

Ho ricevuto una domanda sui certificati, in vista della provetta di fine corso "Reti di Calcolatori". Domanda che coinvolge alcuni dei molti (molti, molti...) aspetti e problemi che purtroppo non è stato possibile approfondire nel corso e quindi non fanno parte del programma di esame. Aspetti e problemi che comunque sono, secondo me, interessanti...pertanto ho deciso di discuterli qui.

Sono proprietaria di un sito il cui nome è stato realizzato con il non custom domain, mi faccio certificare da una Certification Authority la quale mi da una chiave pubblica, una privata e il certificato in cui associa il mio DNS name a tale chiave pubblica.

Dopo qualche tempo decido di passare alla versione di webhosting che mi consente di scegliere il nome che desidero per il mio sito.

Se faccio ciò vuol dire che dovrò tornare dalla CA per farmi dare un nuovo certificato, cambierà anche la chiave pubblica associata a questo nuovo nome? Oppure posso comunque tenere quella precedente?

La risposta è intricata.

In generale, ogni volta che un SubjectFisico desidera un nuovo certificato occorre che acquisisca una nuova coppia di chiavi. Abbiamo visto a lezione: le chiavi sono costruite e rilasciate dalla CA, non dal SubjectFisico. Quindi se la domanda è "quando un sito cambia nome può usare le stesse chiavi di prima?" allora la risposta è "no".

Cosa accade con i non custom domain dipende dalla forma del nome.

In Google Sites con non custom domain il nome è lo stesso per tutti i siti del mondo:

sites.google.com/....
.

Nella vecchia versione di Google Sites era disponibile solo http, in quella nuova è disponibile solo https. Se andate su un sito Google Sites nuova versione, trovate quindi lo stesso certificato per tutti i siti (non ho nessuno sottomano da indicarvi: il mio sito personale è su Google Sites nuova versione ma ha un custom domain; il sito del Machine Learning Lab è su Google Sites vecchia versione).

La gestione più comune dei non custom domain, comunque, è quella della forma usata, ad esempio, da Blogger, cioè da questo sito che state leggendo:

https://bartoli-alberto.blogspot.com/

La parte in blu è diversa per ogni sito ospitato da Blogger. E' un non custom domain perché la struttura è la stessa per tutti i siti ospitati da Blogger.

A questo punto la cosa si complica. Il sito è https ma io non sono andato da nessuna CA e non ho nessuna coppia chiave pubblica-chiave privata.

Quindi Blogger crea automaticamente una coppia di chiavi diversa per ogni sito che ospita? No. Blogger usa la stessa coppia di chiavi per tutti i siti che ospita.

Allora su Blogger ci sono tanti certificati diversi (uno per ogni sito ospitato) che hanno Subject diverso e stessa chiave pubblica? No. C'è un solo certificato valido per tutti i siti: il Subject di quel certificato ha una forma particolare:

*.blogspot.com
.

dove '*' viene interpretato dal browser come "qualsiasi sequenza di caratteri" (ok, non chiediamoci "e se io volessi usare come nome proprio *?"). Pertanto, quando il browser riceve il certificato e verifica che il Subject contenga lo stesso DNS name che trova nell'URL, la verifica ha successo. Quindi quel certificato, e la corrispondente singola coppia di chiavi che è stata messa una volta per tutte sul web server di Blogger, vale per tutti i siti ospitati su Blogger.

Bello e semplice....solo che la cosa si complica ulteriormente.

Andando a vedere il certificato inviato dal web server , si scopre che il Subject non ha nulla a che vedere con blogspot.com:

E allora? I certificati ed il procedimento di verifica prevedono la presenza di un ulteriore campo che si chiama SubjectAltName ed il cui valore contiene altri nomi che possono essere associati a quel certificato (cioè nomi DNS che possono essere usati dai server che presentano quel certificato). In quel certificato si trovano molti nomi tra i quali, appunto, "*.blogspot.com".


Piccole riflessioni finali.
  • Spero siate ancora più convinti del fatto che tra lo strumento "crittografia" e le sue applicazioni reali c'è una distanza enorme: "Whenever anyone says that a problem is easily solved by cryptography, it shows that he doesn’t understand it".
  • Alla fine del corso, il significato del post "Come organizzo lo studio di Internet" acquista forse un nuovo significato.

giovedì 6 dicembre 2018

Esperienza con la PEC: com'è andata a finire

Nel post precedente avevo descritto una "Esperienza (poco consolante) con la PEC". Concludevo in questo modo:

Vedo due possibili spiegazioni per questa vicenda:
  1. Non è un tentativo di attacco. Al contrario di quanto mi è stato detto dall'assistenza, il rinnovo del mio abbonamento PEC ha provocato l'invio automatico di un allegato PDF (magari a causa dell'adeguamento di Aruba alla GDPR) e questo invio è stato catalogato erroneamente come mia richiesta di assistenza.
  2. E' un tentativo di attacco.
Non ho elementi sufficienti per affermare con ragionevole certezza se siamo nel caso 1 o nel caso 2.

Posso però affermare con certezza che se siamo nel caso 1 allora l'assistenza clienti ed il processo di gestione di queste tematiche da parte di Aruba lascia molto a desiderare (eufemismo).

Successivamente alla pubblicazione del mio post ci sono state varie interazioni che hanno chiarito la vicenda.

In breve: eravamo nel caso 1: il mail sospetto non era un attacco. L'assistenza clienti si era sbagliata ripetutamente: era un email inviatomi veramente da Aruba (per un motivo che non c'entrava nulla con la PEC). Il chiarimento telefonico avvenuto il giorno successivo al mio post ha chiarito tutto, sottolineando che la loro assistenza clienti non aveva gestito la pratica in modo appropriato. Hanno anche suggerito, in maniera molto pacata ed educata, che io avrei potuto accorgermi della legittimità del messaggio email. Su questo non sono d'accordo (chi vuole legga più sotto), ma sono rimasto completamente soddisfatto dalla cortesia e dalla chiarezza della persona che mi ha contattato.

Ciò premesso, segue la descrizione dettagliata di cosa è accaduto per chi è interessato.

Il giorno 12 Novembre, dopo avere rinnovato la PEC con Aruba, ricevo un credito da spendere sul sito "pratiche.it". Ad un'occhiata superficiale mi è sembrato interessante quindi mi sono iscritto ed ho inserito i miei dati personali. Dopo un'occhiata più approfondita mi sono reso conto che il servizio non faceva per me. Invece di dimenticarmi semplicemente del sito, ho deciso di cancellare il mio account. Lasciare i miei dati personali in un sito che serve per chiedere certificati, visure etc ha senso se ho intenzione di usarlo; se non ho intenzione di usarlo è una cosa da non fare. Ho quindi deciso di cancellare il mio account seguendo le istruzioni indicate: cioè inviando un email a "info@pratiche.it".

Questi mi hanno risposto dicendo "deve inviare una mail a questi indirizzi: privacy@staff.aruba.it e dpo@staff.aruba.it". Al che mi sono un pò irritato ed ho risposto in questo modo:


C'è stato un breve ping-pong via email ("so che non dipende da lei, ma allora scrivete sul sito "inviate due email agli indirizzi X e Y", non "inviate un email all'indirizzo Z"".) ma mi sono arreso rapidamente perché non ci capivamo. Ho quindi inviato gli email richiesti:


Questo il 12 Novembre. Il mail sospetto è arrivato il 20 Novembre.

Ovviamente tra il 12 e il 20 ho fatto molte cose e "pratiche.it" (nota bene: pratiche.it, non Aruba) non era in cima ai miei pensieri. Ormai lo avevo rimosso dalla testa, per ovvi motivi. In quell'intervallo di tempo ho ricevuto circa 180 (centoottanta) email. Ovviamente non posso ricordare gli indirizzi email di tutti quelli che mi scrivono. Quando invio un email da cui attendo risposta ho un meccanismo per controllare periodicamente se la risposta è arrivata. Nel caso di pratiche.it non avevo attivato questo meccanismo. Non mi è sembrato indispensabile, lo ammetto. E, lo ammetto, non ricordavo che mi sarebbe dovuta arrivare una risposta da due indirizzi email di Aruba.

A questo punto il 19 Novembre c'è una intrusione massiva nella PEC di un provider non specificato (che comunque pare non essere il mio).

Il 20 Novembre ricevo un email dal mio provider PEC in cui, senza fare minimamente cenno a pratiche.it, mi viene detto "per verificare la sua richiesta relativa ad Informazioni commerciali su: Reclami / altro...deve riempire il file PDF in allegato". Non essendo dotato di capacità telepatiche (e non immaginando minimamente quanto fosse difficile togliere da pratiche.it dati che sono così semplici da inserire; per inserirli non mi hanno fatto riempire nessun modulo PDF) mi sono insospettito e mi sono comportato come ho descritto nel post precedente.

Alla fine tutto si è tradotto principalmente in una perdita di tempo.


lunedì 3 dicembre 2018

Esperienza (poco consolante) con la PEC

Il 20 Novembre ricevo un email da Aruba, il provider della mia PEC personale.

Caso da manuale di email da trattare con attenzione, perché:
  1. Non avevo inviato nessuna richiesta ad Aruba.
  2. Mi invitava ad aprire un allegato PDF.
Ovviamente mi sono comportato come dico sempre di fare nei corsi di sensibilizzazione sulla sicurezza informatica: non ho scaricato l'allegato e mi sono collegato alla mia area personale Aruba (senza seguire nessun link nell'email). Se il messaggio fosse stato autentico, infatti, nella mia area personale ci sarebbe stata una copia della richiesta.

Come mi aspettavo, nella mia area personale non c'era nessuna richiesta da parte mia. 

Visto che neanche 24 ore prima era stata resa pubblica una intrusione molto grave in un provider PEC, invece di archiviare l'email e segnalarlo come spam ho speso qualche minuto per approfondire. Ho analizzato gli header del messaggio email per verificare il cammino seguito dal messaggio (informazioni normalmente non visibili): da una analisi superficiale il messaggio email sembrava inviato effettivamente da Aruba. Il che ha fatto diventare la faccenda molto interessante (o molto preoccupante, dipende dai punti di vista). Abbiamo infatti un messaggio email che:
  • Invita ad aprire un allegato PDF per risolvere un problema inesistente.
  • Ha aspetto identico a quelli inviati da Aruba.
  • Non viene rilevato come spam da Gmail.
  • Appare inviato da Aruba.
Il tutto neanche 24 ore dopo che è stata resa pubblica una intrusione gravissima in un provider PEC. Ci sono elementi più che sufficienti per temere un tentativo di attacco.

L'unico dubbio che mi rimaneva era che pochi giorni prima avevo rinnovato l'abbonamento annuale per la mia casella PEC. Il messaggio avrebbe potuto forse essere stato inviato automaticamente dalla procedura di rinnovo e, per un qualche errore software, essere stato catalogato come un "Reclami - Altro" dai sistemi Aruba.

Ho fatto quindi il mio dovere di bravo cittadino: mi sono collegato al servizio di assistenza Aruba per segnalare il problema: "Ho ricevuto un email apparentemente inviato da voi in cui vengo invitato ad aprire un allegato PDF per la gestione di una mia richiesta. Richiesta che non ho mai fatto...Ho analizzato rapidamente gli header dell'email e gli header Received sembrano legittimi (cioè sembrano essere associati a voi). Cosa devo fare? Spero che questo email sia veramente un tentativo di attacco e non un email legittimo provocato dalla mia richiesta di rinnovo annuale PEC (questo secondo caso sarebbe, a mio parere, un pessimo modo di gestire queste pratiche).".

La risposta è stata, per me, sconsolante: "...a seguito di verifiche le comunico che la segnalazione di cui ci invia il numero non risulta esser presente sui nostri terminali e di conseguenza la invito a ritenerla nulla. Per ciò che concerne il rinnovo da lei richiesto risulta normalmente eseguito senza problemi di sorta...". In altre parole, non hanno neanche capito il problema.

Ho insistito, ancora con l'illusione di compiere un servizio: "OK, per me non ci sono problemi. Ma a mio parere non dovreste trascurare il fatto che si verifichino attacchi a vostri utenti (a questo punto è evidente che sono stato fatto oggetto di un tentativo di attacco) con email che sfuggono ai filtri antispam di Google ed i cui header indicano che sono stati inviati da voi. Specialmente se tali attacchi si verificano il giorno successivo ad un incidente molto grave ad un provider di PEC italiano. Il tentativo di attacco e la vostra gestione non mi tranquillizzano molto.".

Nessuna risposta. Insisto dopo 5 giorni. Ancora nessuna risposta, solo una notifica che "sono necessarie alcune verifiche ma cercheremo di risponderti nel più breve tempo possibile".

Sto ancora aspettando (3 Dicembre ore 12.35).

Vedo due possibili spiegazioni per questa vicenda:
  1. Non è un tentativo di attacco. Al contrario di quanto mi è stato detto dall'assistenza, il rinnovo del mio abbonamento PEC ha provocato l'invio automatico di un allegato PDF (magari a causa dell'adeguamento di Aruba alla GDPR) e questo invio è stato catalogato erroneamente come mia richiesta di assistenza.
  2. E' un tentativo di attacco.
Non ho elementi sufficienti per affermare con ragionevole certezza se siamo nel caso 1 o nel caso 2.

Posso però affermare con certezza che se siamo nel caso 1 allora l'assistenza clienti ed il processo di gestione di queste tematiche da parte di Aruba lascia molto a desiderare (eufemismo).

Cosa interessante da notare: il "messaggio sospetto" è visualizzato da Gmail in modo leggermente diverso dai messaggi legittimi, cioè da quelli effettivamente provocati da mie interazioni con l'assistenza:

(interazione reale con l'assistenza)

(messaggio sospetto)





martedì 20 novembre 2018

Qualche considerazione sull'attacco informatico ai tribunali

"Un grande attacco hacker ha colpito nei giorni scorsi circa 3mila soggetti, sia pubblici che privati, in Italia. Sono oltre 30mila i domini violati, e circa 500mila le caselle postali coinvolte: di queste, 98mila delle quali di persone appartenenti alla Pubblica amministrazione. L'azione ha mandato in tilt i tribunali, con la sottrazione di dati personali delle Pec di magistrati ed il conseguente blocco dei servizi delle Corti d'appello di tutto il Paese, ma sono stati interessati anche i ministeri di Esteri, Interno, Difesa, Economia, Sviluppo economico."

https://tg24.sky.it/cronaca/2018/11/20/attacco-hacker-tribunali-password-pec.html

""CAMBIATE subito la password". Roberto Baldoni, il responsabile della cybersicurezza italiana presso la Presidenza del Consiglio dei Ministri, è categorico. L'invito, rivolto a tutto il paese, è la conseguenza di un gravissimo attacco informatico che ha esposto 500.000 caselle di posta elettronica certificata causata dalla violazione dei server di un noto fornitore del servizio. Secondo le prime e parziali indagini adesso gli hacker hanno in mano gli identificativi Pec di 98.000 utenti tra magistrati, militari e funzionari del Cisr, il Comitato Interministeriale per la sicurezza della Repubblica che comprende appunto i ministeri della Giustizia, degli Interni, della Difesa, degli Esteri, dell'Economia e dello Sviluppo Economico, la stessa Presidenza del consiglio dei ministri e dell'Autorità delegata". 

https://www.repubblica.it/tecnologia/sicurezza/2018/11/19/news/dopo_l_attacco_hacker_ai_tribunali_cambiate_subito_la_password_della_vostra_pec_-212086305/

Pochissime considerazioni:
  • Come ho scritto pochi giorni fa, questo è un esempio lampante del perché occorre scegliere una password difficile da indovinare (e diversa per ogni sito).
  • La conferenza stampa c'è stata ieri sera. Stamattina ne parlano solo alcuni giornali. Neanche con grande evidenza.
  • Cose di questo genere succedono. Purtroppo chi non si occupa di queste faccende pensa che accadano solo agli americani, solo nei film, sono fissazioni-di-bartoli, etc.
  • I server di posta elettronica certificata (PEC) sono un bersaglio di grande interesse strategico ed economico. Non c'è da stupirsi che siano stati attaccati. Non c'è da stupirsi troppo che (almeno) questo attacco abbia avuto successo. Possiamo essere contenti del fatto che il successo di (almeno) questo attacco sia stato rilevato e sia stato rilevato rapidamente.
Last but not least:
  • Una bella famiglia di bersagli il cui interesse strategico ed economico è almeno pari a quello dei server PEC è la famiglia degli identity provider SPID. Questi server memorizzano username e password di milioni di persone e permettono di accedere a servizi con validità legale.
  • Penso non occorra aggiungere altro.

lunedì 5 novembre 2018

Perché la password deve essere difficile da indovinare...

In questi giorni Anonymous sta effettuando numerosi attacchi a pubbliche amministrazioni italiane (basta cercare "anon-italy #FifthOfNovember" su Google). Questi attacchi mi hanno motivato a scrivere questo post.

Negli ultimi anni mi è capitato spesso di dare suggerimenti di sicurezza informatica "terra-terra", in particolare sull'uso di email e password: i due aspetti di gran lunga più importanti nella stragrandissima maggioranza dei casi (questa pagina contiene le slide di un corso che ho tenuto più volte per persone senza competenze tecniche specifiche).

Uno dei suggerimenti relativi alla scelta delle password è questo: "non deve essere indovinabile facilmente".

PARENTESI IMPORTANTE: il suggerimento non è proprio questo, è più circostanziato; inoltre, non è il suggerimento più importante sulle password: quello più importante è "non usare la stessa password su più siti diversi"; vedi le slide sopra citate. CHIUSA PARENTESI.

Nel corso introduttivo e nelle slide non approfondisco il motivo per cui una password "non deve essere indovinabile facilmente". Il motivo che lascio intuire è questo: è facile realizzare attacchi automatizzati in cui si prova una sequenza predefinita di password fino a trovare la password giusta. Se il sito non rileva attacchi di questo genere, il che è purtroppo molto più frequente di quanto si immagini, allora c'è il rischio che l'attaccante riesca nel proprio intento. Quindi niente nomi, niente cognomi, niente nome del cane o del gatto, niente nome dei figli etc.

In realtà il motivo vero è un altro. Motivo che ometto completamente nel corso introduttivo onde non complicare le cose.  Cerco di riassumerlo di seguito.

Gli attacchi come quello sopra descritto esistono veramente. Ma sono poco frequenti. Il rischio maggiore non deriva da attacchi di quel genere, bensì da situazioni in cui un attaccante penetra in un server, estrae il database contenente username e password" di tutti gli utenti e fa circolare il database in rete (esattamente ciò che sta succedendo in questo giorni con le utenze di varie Regioni, Province, aziende sanitarie, dipartimenti universitari, associazioni professionali e molto altro).

Se il database è strutturato in maniera corretta, allora le password non sono utilizzabili immediatamente. Il database infatti non contiene la password bensì una funzione non invertibile della password. Ad esempio:

efaa7c4436f92367bf878da1d0c9fb61:PPlC4Xun3a2lcDYhPVUdF4pvulSIvZEM).

Per potere utilizzare una password nel database, quindi, un attaccante deve provare una possibile password, calcolare la funzione non invertibile, vedere se il risultato è identico alla password nel database e poi continuare per tante altre password possibili sperando di trovare prima o poi la password giusta.

Avere scelto una password "non indovinabile facilmente" serve proprio per tentare di difendersi da situazioni di questo genere. Situazioni che purtroppo si verificano relativamente spesso.

Detto questo, uno si chiede "e che succede se il database non è strutturato in maniera corretta?". Quello che succede è che le password sono memorizzate, come si dice, "in chiaro". Quindi sono immediatamente visibili ed utilizzabili.

Io sono un pessimista di natura, ma spesso la realtà supera il mio pessimismo. Mai e poi mai mi sarei aspettato di vedere password in chiaro nei database pubblicati da Anonymous (ripeto: Regioni, Province, etc.).

Vorrei tanto mettere qui una schermata, perché solo una schermata rende pienamente l'idea. Ma non posso diffondere informazioni così delicate. Vi suggerisco però caldamente di immaginare una bella tabella con colonna username (da cui si risale in maniera pressoché immediata al nome ed al cognome) ed accanto la colonna password perfettamente leggibile.


Una schermata del genere fa capire anche un altro motivo per cui bisogna scegliere "una password non indovinabile facilmente": Che figura ci fa uno, o una, che sul proprio posto di lavoro sceglie come password il proprio nome, o il proprio cognome o qualche altra stupidaggine del genere?

Messaggio finale per chi ha responsabilità di amministratore di sistema: che figura ci fa un amministratore di sistema che gestisce le password in questo modo?

martedì 30 ottobre 2018

"Internet per influenzare la società"

Mi è stato chiesto qualche link per "approfondire l'uso della rete internet per influenzare la società".

Interpreto questa domanda nel senso di richiesta di informazioni su "campagne organizzate per manipolare in modo consapevole le opinioni delle persone". E' ovvio infatti che Internet ha una influenza enorme sulla società per il solo fatto di esistere.

Questo tema è molto ampio, molto importante, con implicazioni enormi che, a mio parere, nessuno è ancora in grado di comprendere fino in fondo. Riporto qui sotto alcuni link che io ho trovato molto interessanti e molto utili. Come premessa generale, l'esistenza di campagne organizzate per manipolare le opinioni delle persone è ormai un dato di fatto.

Un documento importantissimo è un discorso tenuto lo scorso anno dal Commissario Europeo per l'Unione della Sicurezza presso lo NCSC UK (il National Cyber Security Center del Regno Unito, un'organizzazione di altissimo livello il cui sito web è una risorsa di valore enorme per chiunque si occupi seriamente di sicurezza informatica). In questo discorso, basato ovviamente su dati e notizie che non possono essere resi pubblici, sono stati trattati i rischi nei sistemi elettorali: "Now is a good time to reflect on what we have learned from recent elections and to try to determine where the threats might lie in future...The risks fall into two main categories: those based on systems and those based on behaviours. In terms of the first we are looking at cyber-attacks that manipulate the electoral process or voting technology to change the number of voters or the number of votes...   The second category of threat is much more subtle and pernicious. Threats that manipulate the voting behaviour of voters."
https://ec.europa.eu/commission/commissioners/2014-2019/king/announcements/commissioner-kings-speech-national-cybersecurity-centre-london_en

Poche settimane fa negli Stati Uniti è stato deciso di mettere sotto processo una cittadina russa con l'imputazione di  avere seminato “division and discord in the U.S. political system, including by creating social and political polarization, undermining faith in democratic institutions, and influencing U.S elections.” Per fare questo "operated fictitious social media accounts, pages, and groups designed to amplify polarizing topics in the U.S." Ancora non sappiamo, ovviamente, quale sarà l'esito del processo, ma il fatto che siano stati raccolti indizi sufficienti per fare un processo è molto importante. Si tratta proprio di ciò che diceva il Commissario Europeo: un "threat that manipulates the voting behavior of voters".

Un articolo di qualche settimana fa sul New Yorker descrive, per così dire, la storia di Facebook. E' un articolo prolisso, lungo, noioso nella parte iniziale. E' però estremamente interessante per capire la dimensione e complessità del problema "rapporto tra Facebook ed opinioni delle persone".
https://www.newyorker.com/magazine/2018/09/17/can-mark-zuckerberg-fix-facebook-before-it-breaks-democracy

Tra le numerose analisi dei rischi nel rapporto tra Facebook e democrazia, una particolarmente interessante è questa (scritta nel periodo dello scandalo Cambridge Analytica):
https://www.nytimes.com/2018/03/19/opinion/facebook-cambridge-analytica.html

Per approfondire gli aspetti tecnici e quantitativi di "How thousands of companies monitor, analyze, and influence the lives of billions Who are the main players in today’s digital tracking? What can they infer from our purchases, phone calls, web searches, and Facebook likes? How do online platforms, tech companies, and data brokers collect, trade, and make use of personal data?" c'è questo bellissimo report, purtroppo lungo e non banale:
http://crackedlabs.org/en/corporate-surveillance

Altre notizie relativamente interessanti:


venerdì 7 settembre 2018

Viste le ripetute amarezze...

...che mi ha provocato l'istituzione, sia nella sua incarnazione centrale sia in quella locale, desidero togliermi un sassolino dalla scarpa e scrivere cose che altrimenti non avrei mai scritto.

Io ed i miei collaboratori abbiamo appena ricevuto l'accettazione di un articolo sulle Communications of the ACM. Una delle riviste informatiche più prestigiose al mondo. Viene pubblicata dal 1958 (61 anni). L'articolo è un "viewpoint" (articolo breve che descrive "opinions and views that pertain to issues of broad interest to the computing community") e non un full research paper. E' comunque una grandissima soddisfazione perché il processo di revisione è estremamente selettivo e rigoroso.

Tanto per avere un'idea, ogni mese vengono pubblicati solo 2 viewpoint. Alcuni mesi 1, talvolta nessuno.

Nel 2018 sono stati pubblicati solo 2 viewpoint su temi di sicurezza informatica, come il nostro. Gli autori erano (i link sono alle pagine Wikipedia degli autori):
  • Eugene Spafford (Professor of computer science at Purdue University)
  • Fred Schneider (Samuel B. Eckert Professor of Computer Science and chair of the at Cornell University computer science department).
Tra gli autori degli altri viewpoint del 2018:
  • Harold Lawson (ACM, IEEE, and INCOSE Fellow, IEEE Charles Babbage Computer Pioneer, and INCOSE Systems Engineering Pioneer)
  • Margaret Martonosi (ACM Fellow, H.T. Adams '35 Professor of Computer Science and the Director of the Keller Center for Innovation in Engineering Education at Princeton University)
  • Sheldon Jacobson (Founder Professor in Computer Science at the University of Illinois at Urbana-Champaign)
  • Stephen Wicker (Professor of Electrical and Computer Engineering at Cornell University and a Fellow of the IEEE)
  • Shane Greenstein (Martin Marshall Professor of Business Administration and co-chair of the HBS Digital Initiative at Harvard University),
  • Illah Nourbakhsh (Professor of Robotics at The Robotics Institute, Carnegie Mellon University)
  • Julia Hirschberg (Percy K. and Vida L. W. Hudson Professor of Computer Science and Chair of the Computer Science Department at Columbia University).
Lungi da me (e dai miei collaboratori) l'intenzione di confrontarci con persone di questo calibro: al loro confronto noi siamo dei dilettanti. Comunque, ripeto, dopo le ripetute amarezze che mi ha provocato l'istituzione ci tenevo a fare questo post.



mercoledì 18 aprile 2018

Attacchi informatici al cervello

Si, avete letto bene.

Nulla di particolarmente sorprendente. Come spiegato qui, degli esperti in sicurezza informatica hanno analizzato dei "neurostimolatori", dispositivi da impiantare sotto la pelle e collegare direttamente al cervello per mitigare i sintomi di alcune malattie (dolori cronici, problemi di movimento come quelli provocati dal Parkinson). Ovviamente hanno trovato il modo di modificare in modo non autorizzato la configurazione di un neurostimolatore già impiantato. Il che "could prevent the patient from speaking or moving, cause irreversible damage to their brain, or even worse, be life-threatening". L'attacco non è particolarmente sofisticato: essenzialmente è bastato ricostruire il formato dei segnali con i quali è programmato il neurostimolatore ed osservare che il protocollo ha garanzie di autenticazione e riservatezza praticamente inesistenti.

Ho scritto che questo evento non è sorprendente perché problemi di questo genere sono frequentissimi nei dispositivi elettronici, anche in quelli biomedicali. Vedi ad esempio le pompe di insulina ed i pacemaker (si, i pacemaker).

Ciò accade per molti motivi, uno dei quali è il fatto che le aziende che realizzano dispositivi biomedicali di solito sono competenti in elettronica e biomedica, ma non sono competenti in sicurezza informatica. Nessuno farebbe realizzare i dischi dei freni di un'automobile ad un'azienda specializzata in costruzioni in cemento armato. Purtroppo la società non si è ancora resa conto che un dispositivo contenente un calcolatore non è un dispositivo arricchito con qualche nuova caratteristica; è qualcosa di radicalmente diverso. Per comprendere quell'oggetto non è sufficiente essere competenti "nel dispositivo"; purtroppo è indispensabile essere competenti anche in informatica, altrimenti si ottengono dispositivi come questi. Dispositivi dai quali dipendono la vita delle persone ma che sono realizzati con tecniche del tutto inadeguate dal punto di vista informatico.

Questo evento si allaccia ad un tema a cui ho accennato brevemente al termine della lezione di "Reti di Calcolatori II e Principi di Sicurezza Informatica" di ieri. Quando uno studia i problemi di sicurezza, spesso gli attacchi gli sembrano intricati, complicati, mere possibilità teoriche di scarso interesse pratico. Questo è un approccio sbagliatissimo. Non si deve pensare in termini di "cosa so fare io", ma nei termini di "cosa può fare uno con motivazioni e competenze adeguate". Ragionando in questi termini uno sarebbe portato a concludere che realizzare il Pantheon o l'Acquedotto di Segovia è intricato, complicato, di scarso interesse pratico (nessuno di noi sarebbe in grado di realizzarli, neanche coinvolgendo altre persone....).

Questo problema è frequentissimo, al punto che gli esperti di sicurezza hanno formulato una sorta di principio apparentemente scherzoso ma profondissimo: "chiunque è in grado di progettare un protocollo di sicurezza che lui non è in grado di aggirare". Quello del neurostimolatore è un esempio da manuale. Il problema è che un protocollo di sicurezza non deve essere progettato da "chiunque". Deve essere progettato dagli esperti. I quali esperti sanno perfettamente che è meglio scegliere uno dei protocolli già esistenti e consolidati senza progettarne di nuovi, perché farne uno nuovo è troppo complicato; si cade quasi sempre nella trappola di cui sopra (si inventa un protocollo apparentemente indistruttibile, poi lo analizza un altro esperto e lui lo aggira con poco sforzo).

PS Il blog  in cui ho trovato la notizia sulla vulnerabilità dei neurostimolatori è fantastico. Ogni giorno viene analizzato un articolo scientifico, nei settori informatici più disparati. La selezione dei lavori e soprattutto la capacità di sintesi di Adrian Colyer sono davvero eccezionali.

martedì 27 marzo 2018

La lezione di oggi e lo scandalo Cambridge Analytica vs Facebook

Oggi nel corso di "Reti di Calcolatori II e Principi di Sicurezza Informatica" abbiamo completato la discussione di OAuth2, un protocollo fondamentale nella nostra vita quotidiana.

Ho dimenticato di evidenziare che questa è proprio la tecnologia alla base dell'enorme scandalo di cui sta parlando mezzo mondo, cioè il caso Cambridge Analytica-Facebook. Il caso è stato sviscerato ampiamente quindi non c'è molto da aggiungere; forse due punti di vista interessanti sono questo (descrizione di come uno sviluppatore abbia ottenuto tonnellate di dati che non gli servivano e che non pensava neanche di ottenere) e questo (analisi più ampia e profonda dei rischi potenziali per la società).

Dal nostro punto di vista ed in estrema sintesi, il problema è che quando i RO (resource owners, cioè gli utenti) assegnano ai C (applications, ad esempio Cambridge Analytica) la delega ad operare sulle proprie risorse sugli RS (resource server, ad esempio Facebook), quasi sempre lo fanno senza rendersi conto esattamente di cosa stanno facendo. Non si rendono cioè conto di quali informazioni personali stanno rendendo disponibili e cosa sia possibile fare con quelle informazioni.

Nel caso specifico Cambridge Analytica in realtà è accaduta una cosa ancora più sottile. I RO hanno fornito la delega ad una applicazione C (si chiamava thisisyourdigitallife) che aveva un certo scopo dichiarato (costruire un profilo della personalità). Poi questa applicazione ha usato i dati estratti da RS per scopi diversi da quelli dichiarati: li hanno venduti ad una terza parte (cioè Cambridge Analytica), la quale ha usato quei dati per operazioni di carattere politico.

Il problema dei C che usano la delega per uno scopo diverso da quello dichiarato lo abbiamo menzionato proprio stamani, ma mi sono dimenticato di evidenziare questo importantissimo esempio.

mercoledì 10 gennaio 2018

Meltdown e Spectre Considerazioni sintetiche

La scorsa settimana sono state rese pubbliche delle vulnerabilità particolamente, diciamo così, "interessanti" in quanto sono dovute ai dispositivi hardware e sono diffuse pressoché ovunque.

Comprendere causa, impatto teorico, impatto pratico, conseguenze, difese è complicato. Più complicato che in alti casi.

Sperando di fare cosa utile, rendo pubbliche alcune considerazioni sintetiche. Scrivo quanto segue al meglio delle mie conoscenze. Se qualcuno rilevasse delle imprecisioni lo prego di segnalarmelo. Alla fine delle considerazioni sintetiche ci sono alcune mie brevissime riflessioni più generali.

1) Le vulnerabilità Meltdown e Spectre sono presenti nella stragrande maggioranza dei dispositivi prodotti negli ultimi anni, dagli smartphone ai server.

Sono quindi presenti in praticamente tutti i sistemi operativi ed ambienti di virtualizzazione più diffusi.

2) Tali vulnerabilità possono permettere a del codice maligno di leggere porzioni di memoria alle quali non dovrebbe avere la possibilità di accedere; memoria di altri processi o del sistema operativo (quindi non il disco).

Un codice maligno può quindi, ad esempio, leggere chiavi crittografiche utilizzate da altri processi (in sessioni HTTPS o VPN attive); leggere password o hash di password utilizzate da altri processi; ottenere informazioni sull'utilizzo della memoria sufficienti per neutralizzare altre difese dei sistemi operativi moderni.

3) Lo sfruttamento da remoto di Meltdown è molto difficile. Condizione "quasi necessaria" per sfruttare Meltdown è la presenza di codice maligno sulla macchina. Presenza che l'attaccante deve ottenere per altre vie, diverse da Meltdown.

4) Quanto sopra vale anche per Spectre, con una eccezione molto particolare e molto importante: i browser.

Poiché i browser caricano codici Javascript da remoto ed è di fatto impossibile garantire che questi codici non siano maligni (cioè non tentino di sfruttare vulnerabilità nel browser), Spectre può essere sfruttata da remoto su tutti i browser.

4-bis) L'effettivo sfruttamento di Spectre richiede che l'utente mantenga aperta la pagina ostile per molto tempo.

5) Tutte le organizzazioni di cui personalmente mi fido (no, non chiedetemi l'elenco) raccomandano di applicare le patch corrispondenti a queste vulnerabilità quanto prima. Patch che sono già state rilasciate o che lo saranno nei prossimi giorni. Tipicamente per i sistemi operativi. In alcuni casi anche per i firmware e per alcuni applicativi.

5-bis) In alcune distribuzioni di Linux le patch indispensabili sono già state rilasciate a partire dal mese di Ottobre 2017 e sono generalmente associate al nome KAISER o KPTI. 

La conoscenza di Meltdown e Spectre tra i ricercatori ed i fabbricanti di software ha infatti iniziato a diffondersi a partire dal mese di Giugno 2016 2017. Il disclose pubblico è stato fatto in anticipo rispetto a quanto pianificato perché molti hanno iniziato a rendersi conto che stava bollendo qualcosa di grosso in pentola. Ad esempio, non era chiaro il motivo delle patch KAISER.

5-tris) L'applicazione delle patch ai sistemi operativi/firmware è generalmente associata ad un calo di prestazioni. Quantificarlo è difficile anche perché dipende fortemente dal workload. Nei workload interattivi, non dovrebbe essere molto marcato.

5-quater) Per le macchine Windows, è indispensabile fare attenzione alla eventuale presenza di antivirus già installati. Alcuni antivirus, infatti, sono al momento incompatibili con tali patch e possono causare un "blue screen of death". 

Al link qui sotto c'è un elenco di compatibilità tra antivirus e patch Windows che dovrebbe essere aggiornato dinamicamente. Non posso garantirne la correttezza. E' fornito da una organizzazione di cui mi fido.

Riflessioni finali

A) Molto, molto spesso, sia le organizzazioni sia "i privati" hanno vulnerabilità che sono più facilmente sfruttabili e potenzialmente più "disruptive" di Meltdown e Spectre.

Questa affermazione non deve essere intesa come una sdrammatizzazione di Meltdown e Spectre. Al contrario, vuole essere un invito alla riflessione: se mezzo mondo è entrato in fibrillazione per vulnerabilità meno sfruttabili e meno disruptive di quelle che sono "tipicamente presenti" allora uno dovrebbe porsi qualche domanda.

B) La necessità di aggiornare i sistemi è, appunto, una necessità. Ormai è ampiamente dimostrato. Non può essere considerata come un caso eccezionale da affrontare ogni tanto quando si ha tempo o in emergenza. E' quindi indispensabile (sarebbe quindi indispensabile) organizzarsi di conseguenza.

C) Ogni volta che si verifica un incidente informatico particolarmente grave o viene scoperta una vulnerabilità particolarmente grave, c'è una costante: l'esortazione ad aggiornare i sistemi il prima possibile.