martedì 24 maggio 2016

Hanno rubato la mia password

...su LinkedIn (qualcuno pensava già alla mia password per verbalizzare gli esami...invece no; più precisamente, se mi sono state trafugate le credenziali di ateneo io non lo so).

Non dovrebbe essere successo nulla di particolarmente grave, ma mi pare importante condividere questo evento per sottolineare che:
  1. Queste cose possono accadere a chiunque.
  2. Il furto della intera tabella delle credenziali (username e password) sui server è un evento relativamente frequente e può coinvolgere anche grandi organizzazioni. Ne avevo già parlato in un post recente.
  3. Io posso tentare di custodire le mie credenziali nel modo migliore possibile; ma se le mie credenziali le conosce anche il server, allora l'attaccante può rubarle dal server. 
Per quanto riguarda il punto 3, tentare di rubare le credenziali dal server è molto più conveniente per l'attaccante: se ha successo un attacco verso di me, l'attaccante ottiene UNA credenziale; se ha successo un attacco verso il server, l'attaccante ottiene MILIONI di credenziali.

In sintesi, è accaduto questo:

  1. Nel 2012 si è verificata una intrusione in LinkedIn: quasi 6.5 milioni di credenziali sono state trafugate.
  2. All'epoca ricevetti un email di allerta da LinkedIn, in cui mi avvisavano che "We recently became aware that some LinkedIn passwords were compromised and posted on a hacker website. We immediately launched an investigation and we have reason to believe that your password was included in the post". Ovviamente mi suggerirono di cambiare la password immediatamente.
  3. Da qualche giorno sono state messe in vendita queste credenziali sui siti underground; a un prezzo mooooolto ridotto: 4 bitcoin (circa 2000$) per vari milioni di credenziali. Molti siti di sicurezza ne stanno discutendo. Una discussione particolarmente autorevole è questa.
  4. Stamattina ho ricevuto dal sito haveibeenpowned (proprio il sito di cui parlavo in coda al post recente) un email in cui mi si avvisava che "You're one of 164,611,595 people pwned in the LinkedIn data breach". Nulla di sorprendente, mi ha confermato quanto LinkedIn sospettava fosse accaduto.

Probabilmente la copia delle mie credenziali che sta circolando adesso è quella precedente al cambio di password che ho eseguito nel 2012...ma ho cambiato la password nuovamente.


mercoledì 18 maggio 2016

SSL / HTTPS: (esempio di) cosa non garantisce

Nella lezione di "reti di calcolatori" di ieri mi sono reso conto che devo insistere maggiormente per sottolineare un aspetto di SSL (quindi di HTTPS) che a me pareva banale ma che evidentemente banale non è.

SSL fornisce garanzie di sicurezza (autenticazione, integrità, riservatezza) tra le due estremità della connessione TCP. Fornisce cioè garanzie relative allo spostamento di dati tra un punto ed un altro.

SSL non fornisce nessunissima garanzia di sicurezza "nei calcolatori" alle due estremità della connessione.

Esempio semplicissimo: un attaccante può modificare un documento statico sul server; oppure può modificare i programmi sul server che generano i documenti dinamici. SSL continua a fornire le proprie garanzie: i dati sono autentici, riservati ed integri da una estremità all'altra della connessione. Ma i dati che viaggiano nella connessione non sono quelli che il server "avrebbe voluto inviare".

Da un altro punto di vista, il dato sul server prima viaggia dalla sua "origine ideale associata al vero subject" fino alla estremità della connessione; poi viene inserito nella connessione. La prima parte del viaggio non ha garanzie di autenticazione e integrità; la seconda ha garanzie di autenticazione, integrità e riservatezza. SSL opera sulla seconda parte del viaggio, non sulla prima.

Attaccare la prima parte del viaggio può essere facile o difficile per l'attaccante, la cosa fondamentale è che SSL non ha nulla a che vedere con questo problema. Nulla. Non lo rende più difficile per l'attaccante. Non fornisce al client nessun elemento per accorgersi della intrusione.

Il ragionamento si applica in modo identico al lato client. Il dato effettua un viaggio in due parti: tra browser ed estremità client della connessione; tra estremità client della connessione ed estremità server. SSL non fornisce nessuna garanzia sulla prima parte del viaggio.

Gli attacchi alla prima parte del viaggio sul lato client si chiamano "Man-In-The-Browser (MITB)". Il nome evidenzia che l'attaccante si trova virtualmente all'interno del browser ed ha accesso a tutte le comunicazioni tra client e server (e per analogia con gli attacchi "Man--In-The-Middle (MITM)" in cui l'attaccante si trova nella internetwork).

Gli attacchi MITB sono terribili perché l'utente vede le pagine inviate dal server, vede il lucchetto che descrive il certificato inviato dal server...ma il browser non fa quello che deve fare; fa quello che decide l'attaccante. SSL è del tutto inutile: fornisce garanzie tra le due estremità della connessione, ma l'attaccante opera esternamente alla connessione.


martedì 17 maggio 2016

A cosa serve l'esame di stato

Sto valutando l'opportunità di sostenere l'esame di stato, ma cercando su internet e sui vari forum non trovo particolari vantaggi come ingegnere informatico (se non 0,5 punti in graduatoria nei concorsi pubblici...ed un po' di prestigio personale).

Prima di scartare questa idea però volevo chiederle un'opinione in merito, poiché credo che la sua esperienza l'abbia aiutata a rispondere al "a che cosa serve l'esame di stato per un ingegnere informatico"?

La mia esperienza purtroppo non mi ha aiutato a rispondere. La risposta è "in tutta sincerità non lo so".

"Non lo so" non significa "a nulla". Significa "non lo so". Per estensione implica "a me non è mai servito e non conosco nessuno di cui possa affermare che gli sia servito".

Devo comunque aggiungere che è vero anche il contrario: non conosco nessuno di cui possa affermare che sia stato danneggiato dall'avere sostenuto l'esame di stato (a parte il danno indiretto associato al tempo ed al costo).



mercoledì 11 maggio 2016

HTTPS e crittografia a chiave pubblica: cosa può andare male

Le cose che possono andare male sono tantissime (vedi anche
https://bartoli-alberto.blogspot.it/2015/10/vulnerabilita-di-implementazione.html).

Al fine di capire meglio a cosa serve e, soprattutto, a cosa non serve la crittografia a chiave pubblica, è utile ricordare le ipotesi alla base delle sue applicazioni pratiche (in particolare, HTTPS e firma digitale). Queste ipotesi, in parole povere, sono:

  1. Subject diversi hanno chiavi diverse.
  2. Le chiavi private sono davvero private.
  3. Le certification authorities emettono certificati con associazioni vere.

Qui sotto riporto un elenco, non commentato, di casi reali in cui queste ipotesi non sono verificate. In tutti questi casi le garanzie fornite da HTTPS e dalla firma digitale, non ci sono.

Slide che mostrano altri casi reali, meno recenti di quelli elencati qui sotto, sono reperibili a questo link: https://drive.google.com/open?id=0B-uEgJBKxWJLbzNjWG5Wb09nRTg . La prima slide indica un articolo divulgativo che ho scritto vari anni fa su questo argomento ma che è ancora attuale: il link all'articolo è cambiato, adesso è questo: https://docs.google.com/document/d/14hCBeHPcIrDXb0lYw_1by1K2cvHIg8JgGauq6RaRZfk/edit#










lunedì 2 maggio 2016

Internet Day: slide (e altro)

A questo link sono visibili le slide del mio intervento su "Crimini informatici e Cyber(in)security" allo Internet Day di venerdi 29/5.

Pochi mesi fa avevo fatto un intervento sulla sola Cyber(in)security al "road show" dei "servizi segreti" presso il polo universitario di Gorizia (slide al link indicato).

A proposito dei 30 anni di Internet (documentario e uno dei numerosi articoli), penso di avere detto a poche persone di avere avuto l'onore di essere stato studente di Luciano Lenzini (il "protagonista" del documentario, in quanto persona che più di ogni altra ha contribuito a portare Internet in Italia) proprio pochi anni dopo l'accensione del primo nodo italiano al CNUCE di Pisa (yes, ho una certa età).

Mi sono laureato nel 1989. Il docente di uno dei corsi dell'ultimo anno organizzò dei seminari sulle reti di calcolatori. Ci disse che i seminari sarebbero stati tenuti "dalla persona che di reti ne sa più di tutti", cioè Luciano Lenzini. Era il 1988 o il 1989, quindi due o tre anni dopo il collegamento dell'Italia a Internet.

Devo dire che all'epoca nessuno di noi studenti si entusiasmò in modo particolare. Nessuno di noi percepiva realmente l'importanza delle reti di calcolatori. A cosa poteva mai servire la possibilità di inviare un file o un messaggio attraverso una rete? Bisogna rendersi conto che all'epoca i calcolatori erano pochi ed esistevano solo nelle università. A chi mai avrei dovuto, io studente, inviare un file o un email?

La primissima applicazione delle reti per me fu da tesista, pochi mesi dopo i seminari di Lenzini.

Ogni tesista si portava dietro una scatoletta di floppy disk in cui salvare i sorgenti del programma che stava sviluppando come tesi, o del documento tesi negli ultimi giorni del lavoro. La mattina infilava un floppy nel lettore, lo copiava nel computer, ripeteva per tutti i floppy necessari (uno non era quasi mai sufficiente) ed iniziava a lavorare. La sera faceva il lavoro inverso. Non c'era infatti garanzia che il giorno successivo uno avrebbe avuto a disposizione lo stesso PC del giorno prima. Inoltre, la probabilità di un evento catastrofico (hard disk illeggibile o cose del genere) era tutt'altro che trascurabile.

Ogni tanto c'era la necessità di cambiare PC durante la giornata. Alcuni avevano poca RAM e non permettevano di eseguire certi programmi. Molti non avevano interfaccia grafica per cui scrivendo un documento non si vedevano i titoli e non si potevano fare i disegni. Solo uno era collegato alla stampante. Limitazioni oggi inimmaginabili. Ogni spostamento richiedeva il lungo e noioso travaso attraverso i floppy.

Le reti presenti in alcuni laboratori dell'università permettevano di fare cose per noi quasi fantascientifiche. Ad esempio, spostarsi di PC senza fare il travaso dei file. Se serviva un file, lo si poteva prelevare. Ci si metteva un bel pò, occorreva ricordarsi i comandi (interfacce grafiche? e chi le aveva mai viste?), talvolta non funzionava...ma si poteva fare senza passare dai floppy.

Spostare i file da un PC all'altro della stessa stanza, al massimo di stanze adiacenti. Una innovazione per quei tempi davvero notevole.