martedì 17 settembre 2019

Italia: Campione d'Europa (di dati sanitari liberamente accessibili su Internet)

Nelle scorse settimane una azienda specializzata tedesca ha condotto una analisi di circa 2300 "medical image archiving systems connected to the public internet". Per chi ha familiarità con il settore, si tratta di server PACS (Picture Archiving and Communication Systems) che usano il protocollo DICOM (Digital Imaging and Communications in Medicine).

Di questi 2300 server collegati ad Internet, ce ne sono 590 accessibili liberamente senza alcun tipo di protezione. Niente username, niente password, niente smartcard, controlli su indirizzo IP...niente di niente.

Ci si collega e si scarica quello che c'è, cioè i dati personali di 24 milioni di pazienti (compresi nome, cognome, data di nascita, data dell'esame clinico, finalità dell'esame, nome del medico, ..) e circa 400 milioni di immagini contenenti i veri e propri esami.

In Europa il nostro paese è quello con il maggior numero di sistemi accessibili su Internet senza nessuna protezione: 10. Il secondo ed il terzo paese ne hanno 7 e 6 rispettivamente.

Siamo anche il paese con il maggior numero di dati di pazienti senza nessuna protezione: oltre 100.000, più di Francia, Spagna, Germania, Inghilterra ed Olanda messe insieme. Per il numero di immagini cliniche senza nessuna protezione non vinciamo ma siamo sul podio (1.15 milioni).

Nulla da dire, sui temi informatici il nostro paese è sempre all'avanguardia.

Ciò non è una sorpresa. Il Digital Society and Economy Index calcolato ogni anno dall'Unione Europea ci vede sistematicamente ad un deprimente 25 posto in classifica su 28 nazioni, ampiamente sotto alla media europea sotto ogni punto di vista.

Alcune domande retoriche:
  1. Qualche provider di servizi sanitari del nostro paese contatterà l'azienda che ha fatto il report per verificre la propria situazione?
  2. Il Garante nazionale per la privacy lo farà?
  3. Qualche partito politico si renderà conto, prima o poi, di questi problemi?
  4. Qualche telegiornale nazionale parlerà, prima o poi, di questi problemi?
Maggiori info:



giovedì 8 agosto 2019

"Gli iPhone sono sicurissimi"

Qualche anno fa c'era in giro la credenza che "i dispositivi Apple non prendono i virus". Credenza ovviamente infondata, come ho descritto in questo post del 2014 (nota: 5 anni fa).

Molti continuano ad avere credenze simili, da cui il titolo di questo post.

Proprio in questi giorni, il Google Project Zero ha reso pubblico quanto segue:

  • I focused on the attack surfaces of the iPhone that can be reached remotely and do not require any user interaction and immediately process input.
  • We reported a total of 10 vulnerabilities, all of which have since been fixed.
  • The majority of vulnerabilities occurred in iMessage...
  • Visual Voicemail also had a large and unintuitive attack surface that likely led to a single serious vulnerability being reported in it.
  • Overall, the number and severity of the remote vulnerabilities we found was substantial.
Nulla di particolarmente sorprendente. Altra dimostrazione che non si deve credere alle favole (e che la migliore difesa possibile è l'aggiornamento dei software).


giovedì 25 luglio 2019

Possiamo fidarci delle Certification Authorities?

(8 Agosto: cambiato il titolo)

Due eventi recenti molto interessanti.

Kazakhstan government is now intercepting all HTTPS traffic

In Kazakhistan, ogni utente può navigare su Internet solo dopo avere inserito il Governo tra le Certification Authority fidate dai propri dispositivi.

Ciò implica che il Governo del Kazakhistan può operare da Man-In-The-Middle nei confronti di tutte le comunicazioni HTTPS, quelle "crittate" che usiamo ogni giorno: può cioè vedere modificare tutto ciò che viene trasmesso nei due sensi. Ripeto, può vedere e modificare le comunicazioni crittate.

Spiegare i dettagli tecnici è troppo lungo...specialmente per una mattina di fine luglio...se uno ha la pazienza di leggere la dispensa "Security" del corso di Reti di Calcolatori trova tutti i dettagli.

Peraltro, penso che questa azione renda impossibile, in Kazakhistan, l'uso del browser Chrome e di molte app per smartphone (per motivi tecnici inadatti a fine luglio...in questo caso i motivi non sono descritti nelle dispense di Reti di Calcolatori; sono spiegati in Reti di Calcolatori II e Principi di Sicurezza Informatica; in breve, alcune applicazioni usano il "Certificate Pinning", contengono già i soli certificati di cui si fidano e non accettano altri certificati, neanche se rilasciati da certification authority che il dispositivo su cui sono in esecuzione considera fidate).

Advanced mobile surveillanceware, made in Russia, found in the wild

Un malware per dispositivi Android scoperto nei giorni scorsi altera le Certification Authority fidate sul dispositivo (pare che esista anche per iPhone). In estrema sintesi e semplificando un (bel) pò, l'organizzazione che ha distribuito quel malware ha (circa) le stesse capacità sopra descritte, può cioè vedere e modificare etc etc.

Come diceva Roger Needham "se qualcuno dice che un problema è risolto facilmente dalla crittografia, dimostra di non avere capito il problema".

venerdì 12 luglio 2019

Dispense di "Reti di Calcolatori"

Ho scritto delle dispense per il corso di "Reti di Calcolatori" ed ho deciso di renderle pubbliche.

Sono consultabili da smartphone e sono in inglese.

Gli argomenti sono più o meno i seguenti:

  • Introduzione: Applicazioni, protocolli, client e server
  • DNS: funzionalità ed implementazione
  • Email: funzionalità ed implementazione
  • Web: pagine, sessioni, autenticazione, analytics
  • Web - The Big Brother: tracking e profiling degli utenti
  • IP: assegnazione dei network number, routing, ARP, firewall
  • Security: proprietà di sicurezza con network attacker, distribuzione delle chiavi, certificati, TLS/HTTPS

E' stato un grosso impegno, spero siano utili.

Apprezzerò molto commenti, critiche e segnalazioni di imprecisioni.

https://bartoli.inginf.units.it/didattica/dispense-reti-di-calcolatori

venerdì 28 giugno 2019

Password UniTs consegnate alla Microsoft?

Molte organizzazioni hanno, giustamente, iniziato ad usare servizi informatici "in cloud", ad esempio i servizi Office 365 di Microsoft.

Operazioni come queste si possono fare in due modi: "facile" o "un pò meno facile".

Il modo "facile" ha, come tutte le cose facili, un costo nascosto. In questo caso il costo nascosto consiste nel permettere al fornitore del servizio cloud di conoscere le credenziali (username e password) usate nell'organizzazione.

E' quello che accade nel nostro ateneo. Per usare alcuni servizi dobbiamo collegarci a https://login.microsoftonline.com ed inserire le nostre credenziali di ateneo. Il browser invia le credenziali al web server di nome login.microsoftonline.com:

POST https://login.microsoftonline.com/OMISSIS/login HTTP/1.1
Host: login.microsoftonline.com
Connection: keep-alive
Content-Length: 1393
Cache-Control: max-age=0
...
Content-Type: application/x-www-form-urlencoded

i13=0&login=MIAMATRICOLA%40ds.units.it&...OMISSIS...&passwd=MIAPASSWORD&....OMISSIS....

Non so chi controlli quel web server perché non ho analizzato l'indirizzo IP corrispondente. Il web server potrebbe essere controllato da Microsoft (molto probabile) o da altri (Università di Trieste compresa, anche se è molto improbabile).

E' però certo che è Microsoft a decidere, ogni volta che ci colleghiamo, a quale indirizzo IP deve corrispondere il nome "login.microsoft.online". Pertanto è Microsoft a decidere a quale web server saranno inviate le nostre credenziali. Pertanto, da un punto di vista tecnico, Microsoft può impossessarsi delle credenziali di ateneo di tutti gli utenti che si collegano a quel servizio.

Il modo "un pò meno facile" è quello di realizzare moduli di autenticazione basati su OAuth o SAML, tecnologie che fanno parte del programma del corso di "Reti di Calcolatori 2 e Principi di Sicurezza Informatica". Queste tecnologie sono molto diffuse (il cosiddetto Sistema Pubblico di Identità Digitale SPID, ad esempio, è basato su SAML) e permettono di ottenere una funzionalità molto importante, specialmente per l'utilizzo aziendale di servizi cloud: le credenziali di ateneo non escono mai dall'ateneo.

Nota bene: "facile" non vuol dire "sbagliato". La modalità da adottare non è necessariamente quella a sicurezza maggiore. La modalità deve essere adottata in base ad un compromesso tra sicurezza e costo ed in base ad una analisi del rischio corretta e consapevole. Uno potrebbe chiedersi se questa analisi del rischio sia stata fatta e da chi, ma questo è tutto un altro problema.




venerdì 22 marzo 2019

Password "in chiaro" nei sistemi di Facebook: è un problema?

Ho ricevuto questo mail da uno studente:

Mi sono imbattuto in una notizia che mi ha fatto riflettere (anzi, preoccupare..).

“Una serie di errori in alcune applicazioni di Facebook ha causato l'accesso alle password degli utenti a circa 20.000 dipendenti. Si ritiene che le password da 200 milioni a 600 milioni di utenti di Facebook siano state esposte...
Facebook ha confermato questa omissione nel suo blog ufficiale...è stata rilevata nel mese di Gennaio. ...almeno 2.000 dipendenti di Facebook hanno cercato i file con le password, ma non era chiara l'intenzione di tali ricerche. Presumibilmente la memorizzazione delle password in “chiaro”è iniziata nel 2012".

Io non riesco a capire se il fatto di memorizzare le password in “chiaro” sia stato effettivamente un errore del sistema/software oppure hanno deciso di farlo “apposta”.. Se siamo nel secondo caso allora la cosa mi preoccupa, perché una organizzazione mondiale come Facebook, dovrebbe garantire delle misure di sicurezza di un certo livello (hashing, salting, ecc..). Non voglio immaginare se ci sono altre organizzazioni importanti che hanno fatto la stessa cosa...

Quando si trova una notizia di sicurezza informatica, la prima cosa da fare è dimenticarsi quanto si è letto e cercare di risalire alla fonte originale; se non ci si riesce, allora cercare la notizia su un sito "affidabile", mai fidarsi di sintesi lette altrove. Se non si trova la notizia su un sito "affidabile", allora prenderla con le molle.

Difficile fare un elenco di siti "affidabili" per queste tematiche. The Verge, Motherboard, Ars Technica, Wired, The Register sono un elenco non esaustivo.

Per questa notizia specifica la fonte originale è Brian Krebs (sito ultra-affidabile): https://krebsonsecurity.com/2019/03/facebook-stored-hundreds-of-millions-of-user-passwords-in-plain-text-for-years/

Ogni cosa non scritta in quell'articolo è una speculazione o un'analisi. Non è un fatto. La fonte ufficiale Facebook afferma che "We’ve not found any cases so far in our investigations where someone was looking intentionally for passwords...what we’ve found is these passwords were inadvertently logged".

Ciò premesso, passiamo alle mie speculazioni/analisi, per quello che possono valere.

  • Sistemisti e programmatori spesso fanno cose che non dovrebbero fare; i motivi possono essere molteplici: incompetenza, superficialità, necessità di risparmiare tempo, errori di analisi/valutazione del rischio oggettivo e di immagine, etc. La spiegazione sopra citata potrebbe quindi anche essere plausibile. Potrebbe.
  • Facebook si è resa conto dell'importanza di controllare l'accesso ai dati, in generale, solo negli ultimissimi anni. Personalmente non mi stupirei se fino a pochi anni fa avessero utilizzato internamente tecniche di controllo degli accessi eccessivamente permissive. Inoltre, non lo giustificherei ma lo comprenderei (vedi anche l'articolo su New Yorker citato in questo mio blog post).
  • I rischi che Facebook ed ogni altra organizzazione che ha accesso ai "nostri dati" fanno correre alla nostra società ed alle democrazie sono enormemente più grandi di quelli che potrebbero essere causati da un accesso indiscriminato alle nostre password su Facebook. Rischi davvero giganteschi le cui implicazioni non sono ancora comprese pienamente da nessuno (vedi ancora il mio blog post sopra citato).
  • E' ovvio che permettere a migliaia di dipendenti di accedere alle password in chiaro di centinaia di milioni di utenti è un errore tecnico ed operativo gigantesco. Ma non bisogna stupirsi di errori del genere. Soprattutto non bisogna pensare "questa è una organizzazione grande, quindi gestisce la sicurezza informatica in maniera adeguata". L'esperienza quotidiana ha ormai dimostrato abbondantemente che non è vero. Per supportare questa affermazione potrei fare un elenco di esempi pressoché infinito. Un'occhiata al primo file di slide del corso base di sicurezza informatica che ho fatto in molti contesti può essere sufficiente per avere un'idea. Un caso recentissimo molto interessante è l'intrusione al VPN provider Citrix.
  • Non bisogna neanche pensare "nessuna organizzazione gestisce la sicurezza informatica in maniera adeguata" oppure "tutto si può bucare". Per capire la sicurezza informatica bisogna pensare in termini di incentivi. Se il costo di un attacco che ha successo è tollerabile, allora il difensore non ha incentivi a spendere in difesa.

    Ad esempio, pochissimi giorni fa un sito italiano specializzato in "indagini patrimoniali, recupero crediti e informazioni commerciali" (quindi un sito che raccoglie dati su mutui, debiti e cambiali, per intenderci) è stato bucato da LulzSec ed i suoi dati sono stati diffusi su Internet. Quasi nessun quotidiano ne ha parlato. Nessuno ne sa nulla. Quale incentivo c'è a spendere in difesa? In teoria il Garante per la protezione dei dati personali dovrebbe sanzionarli con una multa...vedremo se e quando. Soprattutto, vedremo quanto sarà questa multa. Sarà tale da incentivare quella organizzazione ed organizzazioni simili a gestire la sicurezza informatica in modo appropriato?

martedì 19 febbraio 2019

"SPID di livello 3": mi arrendo!

Da qualche tempo la nostra pubblica amministrazione sta promuovendo l'uso di "SPID", il "sistema pubblico di identità digitale": il cittadino si fa rilasciare delle credenziali da un "gestore di identità" abilitato e poi potrà accedere a tutti i servizi web della pubblica amministrazione (magari...) usando quelle credenziali. In altre parole, il cittadino avrà una unica "identità digitale" grazie alla quale potrà accedere a tutti i servizi web pubblici (ripeto: magari...).

Il terzo livello SPID è quello che dovrebbe offrire il grado di sicurezza più elevato. Ci sono solo due gestori di identità che offrono SPID di livello 3: Aruba (pare) tramite smart card e PosteID (pare) tramite una app per smartphone.

Ho cercato di capire come funziona esattamente questo livello. Il sito SPID su questo punto infatti è molto generico: "Il terzo livello, oltre al nome utente e la password, richiede un supporto fisico (es. smart card) per l’identificazione." Ho cercato di capire se il "supporto fisico" che deve essere disponibile al momento della autenticazione (quindi durante l'uso normale, non al momento della richiesta delle credenziali) può essere uno smartphone oppure deve essere un dispositivo di altra natura.

La natura del supporto fisico è molto importante. Uno smartphone può avere del malware a bordo. Un malware può intercettare SMS, può leggere schermate di altre app (quindi anche i codici generati dalle app di autenticazione), può fare praticamente di tutto. Una security key o una smart card o un OTP token (dispositivi portatili che generano codici usa e getta) non può avere malware a bordo (ok, questa è una visione molto ottimistica ma il concetto è chiaro). Anche se la sicurezza non può essere quantificata, è evidente che il livello di sicurezza offerto da uno smartphone è ben diverso da quello offerto da un dispositivo usato solo per la autenticazione a due fattori. Mi sembrerebbe molto strano se il livello di sicurezza più elevato fosse basato su smartphone.

Dopo varie interazioni con l'help desk ufficiale SPID mi sono arreso ed ammetto pubblicamente: non ho capito. Non ho capito se uno SPID di terzo livello può essere basato su smartphone oppure richiede un dispositivo specifico per l'autenticazione a due fattori.

Oltre a non avere capito, ho le idee ancora più confuse di prima:
  1. Il terzo livello SPID "non è ancora operativo". Cosa significhi esattamente "non è ancora operativo" non lo so, riporto quanto afferma l'help desk SPID.
  2. Due provider di identità, Aruba e PosteID affermano però di offrire uno SPID di livello 3 (!) Come ciò possa accadere visto che lo SPID di terzo livello "non è ancora operativo" non lo so.
  3. L'help desk SPID dice che ogni provider di identità può "prevedere procedure differenti per l'attivazione e la gestione" ma ciò non risolve il mio dubbio: se SPID dice che il terzo livello non è operativo perché Aruba e PosteID dicono di offrirlo? E perché lo offrono basandosi su tecnologie il cui livello di sicurezza è così diverso?
A me queste cose rattristano, è più forte di me...

venerdì 25 gennaio 2019

NON cambiate frequentemente la password!

Da qualche tempo l'applicativo che usiamo in Università per la verbalizzazione degli esami mostra un avviso in cui consiglia di "cambiare frequentemente la password per sicurezza":

Questo suggerimento è in conflitto con i suggerimenti che ho dato più e più volte nei mesi scorsi, a centinaia di persone diverse, in vari contesti diversi (compreso un corso di formazione che ho fatto per tutto il personale tecnico-amministrativo del nostro ateneo).

Mi sento quindi obbligato a ribadire che si tratta di un consiglio da non seguire.
  1. Il National Cyber Security Center del Regno Unito (organo che fornisce linee guida di cyber security alla pubblica amministrazione del Regno Unito ed il cui sito web è semplicemente fantastico), dice a proposito delle password che: "Regular password changing harms rather than improves security, so avoid placing this burden on users", cioè "cambiare la password regolarmente danneggia la sicurezza invece di migliorarla: evitate quindi di dare agli utenti questa incombenza".
  2. Il National Institute of Standard Technologies degli Stati Uniti afferma nelle "Digital Identity Guidelines" che occorre "Remove periodic password change requirements" (in questi giorni i siti governativi degli USA, compreso il NIST, sono inaccessabili a causa dello shutdown, quindi queste indicazioni non si possono reperire direttamente, comunque basta cercare un pò su Google e si trovano indicazioni su queste guidelines, ad esempio qui).
Potrei proseguire ma mi fermo qui.

Ovviamente, quando si viene a conoscenza di una intrusione in un sito web, ad esempio attraverso i mezzi di comunicazione, oppure perché ci informa il sito stesso, oppure attraverso un servizio di alert specializzato, allora occorre cambiare la password del sito coinvolto.

Ma sforzarsi di cambiare la password regolarmente "per motivi di sicurezza", no (a meno di non essere amministratore di una rete aziendale Windows, ma questo è tutto un altro discorso).

Le cose da fare sono altre, principalmente evitare il riuso delle password, cioè l'uso della stessa password in più siti importanti.

Appendice: perchè è un suggerimento da non seguire?

Il dato di fatto da cui partire è che il riuso delle password è il rischio di gran lunga più importante.

E' ormai diventato evidente che se gli utenti sono obbligati a cambiare frequentemente la password, allora è mooooolto probabile che arrivino ad usare la stessa password più o meno ovunque (perché altrimenti non riescono a ricordarla). Quindi invece di avere un vantaggio si finisce con l'avere un maggiore rischio.

In teoria cambiare la password frequentemente sarebbe cosa buona e giusta. Ma solo se la password è anche univoca e anche difficile da indovinare per un attaccante. Se uno riesce a soddisfare questi tre requisiti, ad esempio usando sistematicamente un software password manager (il che rende più semplice soddisfare questi requisiti ma non lo rende automatico), allora fa benissimo a cambiare la password regolarmente.

In pratica, pressoché nessuno riesce a soddisfare questi tre requisiti. Di conseguenza, bisogna scegliere il compromesso migliore, cioè quello a minore rischio. Minore rischio significa evitare assolutamente il riuso e cercare di renderla difficile da indovinare.

Appendice: e se sono obbligato a farlo?

Il nostro paese ha delle norme che impongono ai gestori di servizi che trattano dati di una certa tipologia di imporre il cambio della password ad intervalli di tempo regolari, dell'ordine dei mesi (è difficile sperare che queste norme siano aggiornate rimuovendo tale obbligo).

In questi casi il gestore del servizio impone una scadenza temporale forzando quindi l'utente a scegliere una nuova password, al primo login successivo a tale scadenza.

Soddisfare un obbligo normativo è però cosa ben diversa da suggerire attivamente agli utenti di cambiare regolarmente la password, lanciando il messaggio che questo comportamento è benefico per la sicurezza.