mercoledì 4 novembre 2015

Quanto è difficile trovare security bug critici nel Samsung Galaxy S6 Edge?


Il Samsung Galaxy S6 Edge è uno smartphone "top" uscito da poco. E' naturale porsi una bella domanda: "quanto è difficile trovare security bug critici in questo dispositivo?"



Ovviamente "difficile" non significa molto. E' più utile considerare quantità misurabili. Una domanda  molto più utile è quindi "quanto tempo occorre per trovare security bug critici?". Neanche questa però è del tutto soddisfacente in quanto è ovvio che la produttività di 1 persona e la produttività di 5 persone sono diverse. Pertanto conviene porsi la domanda con riferimento alla formulazione standard "mese-uomo":  "quanti mesi-uomo occorrono per trovare security bug critici?". Adesso la domanda è sensata (ok, consideriamo implicitamente di usare persone qualificate; è ovvio che un cuoco o un avvocato difficilmente potranno trovare security bug critici).

Questo blog post recentissimo del "Project Zero" di Google fornisce informazioni mooooolto interessanti: due team di 5 persone ognuno hanno scoperto 11 (UNDICI) security bug, quasi tutti molto critici, in UNA SETTIMANA.

http://googleprojectzero.blogspot.it/2015/11/hack-galaxy-hunting-bugs-in-samsung.html

Questo dato permette di fare molte riflessioni interessanti che ognuno immaginare abbastanza facilmente.

Consiglio caldamente la lettura del blog post: oltre ad essere molto sintetico, è di una chiarezza non comune in queste tematiche.

mercoledì 28 ottobre 2015

Intelligence e Università

Poche ore fa ho fatto un intervento sulla cybersecurity nell'aula magna del polo universitario di Gorizia "tappa numero 21 del roadshow che da ottobre 2013 vede il Sistema di informazione per la sicurezza della Repubblica dialogare con i giovani nelle principali università italiane".

L'evento è stato aperto dal nostro Magnifico Rettore e c'è stato un intervento della Autorità Delegata per la sicurezza della Repubblica (in parole povere: il responsabile dei cosiddetti servizi segreti). Evento molto interessante. Locandina qui.

Le slide del mio intervento sono consultabili a questo link.

Mi sembra che il mio intervento sia stato apprezzato. Quando ho collegato il proiettore e si è visto lo sfondo del mio PC forse non mi avevano preso troppo sul serio....(per chi non lo conoscesse, eccolo qui).







venerdì 23 ottobre 2015

Vulnerabilità di implementazione crittografica

Nel corso di Reti di Calcolatori II abbiamo descritto un modello per comprendere gli attacchi informatici ed il funzionamento dei protocolli di sicurezza. Gli attacchi si possono fare su:

  1. Protocolli di comunicazione;
  2. Algoritmi crittografici;
  3. Implementazione dei protocolli;
  4. Implementazione della crittografia;
  5. Software che implementa i protocolli o la crittografia;
  6. Software che implementa tutto il resto;

Abbiamo detto che i protocolli di comunicazione (SSL, VPN, Protected WiFi, Kerberos, etc) assumono attacchi di tipo 1 ed assumono che tutto il resto sia perfetto.

Abbiamo anche detto che, nella pratica, il resto non è per niente perfetto. Pertanto nella pratica gli attaccanti fanno attacchi di altri tipi, prevalentemente di tipo 6, perché costano molto meno degli altri ed hanno elevata probabilità di successo.

Inoltre, abbiamo sottolineato che anche attacchi dei tipi 2-5 possono avere successo e che, nella pratica, spesso si sono verificati. L'iniezione fraudolenta di dati nelle connessioni TCP, analizzata in dettaglio nel corso, è un attacco di tipo 3.

In queste settimane è stato pubblicato un lavoro che ha riscosso moltissimo interesse ed ha sollevato molto scalpore per quanto riguarda la possibilità di attacchi di tipo 4. E' stato infatti dimostrato come decrittare "tranquillamente" il traffico HTTPS nell''8% del milione di siti più utilizzati al mondo. E' stata anche dimostrata la possibilità di decrittare il 20% del milione di siti HTTPS più utilizzati al mondo, il 66% delle VPN (!), il 25% dei server SSH. Questi risultati confermano i documenti sulle capacità di analisi della NSA che sono stati resi pubblici a seguito della "fuga di documenti" di Snowden. Maggiori dettagli tecnici qui.

Sugli attacchi di tipo 6 è ormai inutile soffermarsi. Dobbiamo rassegnarci a convivere con attacchi che hanno successo semplicemente facendo aprire un foglio Excel o visitando un sito web che ha video Flash...sigh.


lunedì 21 settembre 2015

Tedeschi o italiani?

(sono aperte le iscrizioni---obbligatorie---ai miei corsi di questo semestre: http://bartoli.inginf.units.it/Home/didattica/slides)

Notizia di pochi giorni fa: gli Stati Uniti hanno obbligato la Volkswagen a sostituire il software installato in quasi mezzo milione di automobili diesel.

Hanno infatti scoperto che questo software è stato realizzato in modo da avere un comportamento in fase di revisione periodica dell'auto diverso dal comportamento normale. In parole povere, se l'automobile è sotto revisione allora il software riduce le emissioni inquinanti, mentre se l'automobile è in funzionamento normale allora il software non riduce le emissioni, in modo da aumentare le prestazioni del motore.

A parte l'ovvia riflessione suggerita dal titolo di questo post, questa notizia è molto importante per i seguenti motivi:


  1. Una piccola riflessione sul costo di immagine e sul costo necessario per richiamare mezzo milione di auto e sostituire il software installato su queste auto è sufficiente per capire l'importanza che ormai ha raggiunto il software anche nei settori "non tradizionalmente" associati all'informatica. Peraltro, ci attendono tempi molto divertenti da questo punto di vista, visto che alcune delle automobili più recenti hanno problemi di sicurezza tali da renderne possibile il controllo di motore e freni da remoto (!).
  2. Gli scenari che talvolta dipingo a lezione possono sembrare paranoici o infondati, come quando accenno alla possibilità di realizzare macchine per il voto elettronico con un comportamento inappuntabile in fase di test e con un comportamento completamente diverso al momento della raccolta dei voti, in modo da favorire questo o quel candidato. D'altra parte, questa notizia sulle automobili Volskwagen è proprio un esempio concreto di comportamento di questo genere---comportamento fortunatamente scoperto.

mercoledì 2 settembre 2015

Valutazione della didattica

Anche quest'anno è andata bene. Risultati qui.

Commenti opzionali degli studenti per il mio corso di Reti di Calcolatori (click per ingrandire):

Commenti dello scorso anno:

Grazie.


lunedì 31 agosto 2015

My personal workflow Part 1: task management

Use of a tool for task ("to-do") management for me is a necessity. I have tried many, many approaches. Every once in a while I also look at new tools, to see whether I can improve my current way of working.

The approach I have been using since a couple of years, with minor fixes, turned out to be extremely useful. At least for my way of working. I recently gave another extensive look at similar tools, but could not find anything better.

I use Remember The Milk (RTM). I keep my to-dos separate in two lists: "Home" and "Work". This granularity is adequate to my needs.

I occasionally create to-dos directly on the RTM web site, but in most cases I transform either an email (GMail) or a note (Evernote) to a to-do with very few clicks:
  1. By tagging an email in GMail with a special label (either "Automator-Home" or "Automator-Work").
  2. By sending an email from GMail to myself, at a special destination address. The address is in my contact list (either RTM-HOME or RTM-WORK) and shows up as soon as I type "RT" (very quick even from smartphone). The email will not appear in my inbox.
  3. By creating a reminder in Evernote (one click on an Evernote note).
This is extremely handy, especially because an URL is automatically associated with the to-do, either a GMail thread or an Evernote note. Later, a single click on the to-do allows me to jump directly to the "context" describing the to-do.

The Evernote integration is provided by RTM.

The GMail integration has been implemented by myself. RTM provides a GMail gadget, which is very useful to have the full list of to-dos always under your eyes, sortable by due date, priority and alike. However, RTM provides neither option 1 nor option 2.

I implemented option 1 with a simple Google Apps Script which runs automatically every 5 minutes and executes the following steps:
  1. Collect all threads labelled either "Automator-Home" or "Automator-Work" (I keep my to-dos separate in two lists; this granularity is adequate to my needs);
  2. For each thread, send an email to the the special email address provided by RTM which allows creating to-dos. The email content follows the RTM syntax, so that:
    • To-do name: GMail thread subject;
    • To-do list: either Work or Home, depending on the GMail label;
    • To-do URL: GMail thread URL;
    • To-do deadline: "tomorrow";
Choosing "tomorrow" as deadline ensures that no to-do gets unnoticed while at the same time making to-do creation quick and simple. I can fix the deadline appropriately later, when the to-do shows up on the GMail gadget.

I implemented option 2 with a couple of GMail tricks. In GMail, an address of the form "user@gmail.com" is equivalent to "user+string@gmail.com". Thus, I defined two "strange strings", say "+kijyht-HOME" and "+kijyht-WORK". Next, I defined two GMail filters that detect emails sent to me, at those addresses, and label them appropriately (either "Automator-Home" or "Automator-Work") in order to be processed by the Apps Script described above. Moreover, these filters mark the email as "read" and "skip the inbox".

I do not use RTM reminders, nor do I let RTM deadlines appear in my Google Calendar. I have just too many pending to-dos: I would be flooded by reminders and by calendar events. I prefer to use the GMail gadget judiciously to postpone, change deadline, change priority (to detect visually what should not be postponed) and alike.

That's it. For me, this approach is a huge time-saver and efficiency booster.

In a next post I will describe the other cornerstone of my personal workflow: reading list management with Evernote (and Feedly, Twitter, Zapier, IFTTT...).

giovedì 26 marzo 2015

Io "sono" un numero

Ieri a lezione abbiamo detto che se un client CX genera (in modo fraudolento) una request RX contenente l'identifier di una sessione di un altro client C, allora RX viene elaborata dal server come se fosse stata generata da C.

Ciò è evidentemente molto spiacevole. Specialmente se la sessione è "autenticata", cioè l'utente che sta controllando C ha dimostrato la propria identità al server (con meccanismi che vedremo nella prossima lezione) ed il server ha quindi inserito nello stato della sessione informazioni quali "sessione autenticata, username rettore ateneo".

In questo modo, infatti, CX può accedere in lettura e scrittura a dati privati dell'utente che sta controllando C. Superfluo evidenziare le implicazioni.

Ho anche detto che queste cose, fino a pochissimi anni fa, erano talmente facili da fare che erano stati sviluppati software gratuiti in grado di farlo in modo automatico. In pratica, bastava osservare il traffico in una rete WiFi per raccogliere gli identificatori delle sessioni degli altri utenti della stessa rete. Trovati gli identificatori, generare request contenenti quegli identificatori era banale. A questo link trovate informazioni al proposito:
http://bartoli-alberto.blogspot.it/search?q=sidejacking

​Oggi, fortunatamente, le cose sono cambiate nel senso che tutto il traffico di tutte le sessioni autenticate è crittato. Pertanto indovinare il session identifier di un altro client non è più banale come in passato ("non banale" è diverso da "impossibile").

Ciò che è istruttivo è il fatto che le cose sono andate avanti in quel modo per moooolti anni.

A questo punto ci sarebbe da spiegare "ma come mai non se ne preoccupavano?"....

lunedì 23 marzo 2015

Machine learning e tesi di laurea

Un lavoro basato su una tesi di laurea magistrale svolto nel "mio" laboratorio è stato accettato ad un congresso scientifico internazionale moooolto prestigioso.

Come ho già avuto modo di scrivere in una occasione simile "Ancora una volta mi chiedo perché molti studenti in gamba preferiscano fare tesi di laurea in cui l'obbiettivo è fare qualche finestra colorata con qualche bottone altrettanto colorato usando una delle N tecnologie esistenti al momento...ma questo è un altro discorso."

Il lavoro è descritto in un post sul sito del Machine Learning Lab.

Il tesista, Marco Virgolin, è stato davvero molto bravo. Ha un solo difetto, purtroppo non rimediabile, che non riporto pubblicamente ma che lui conosce benissimo. Difetto che comunque non ha impedito il raggiungimento di questo bellissimo risultato.

Al fine di non deludere gli altri tesisti, passati e futuri, il cui lavoro non è stato pubblicato, chiarisco che per arrivare alla pubblicazione di una tesi sono necessari molti fattori: bravura ed impegno del tesista sono solo due di questi. Ho seguito infatti molte tesi che non hanno portato a pubblicazioni pur essendo molto belle, fatte da persone molto in gamba e che hanno lavorato molto.  L'esempio più lampante è quello del mio braccio destro, Eric Medvet...


Indipendentemente dalle pubblicazioni, comunque, spero che il passaggio dal Machine Learning Lab sia stata una esperienza positiva per tutti quelli che l'hanno fatto.

giovedì 5 marzo 2015

Come organizzo lo studio di Internet

Lo studio di Internet è molto diverso dallo studio di Analisi I o di Fisica II. Internet fa parte della nostra esperienza quotidiana immediata, altre discipline sono più lontane dall'esperienza quotidiana o ne sono parte ma non ce ne accorgiamo.

Ciò rende potenzialmente più "appassionante" lo studio di Internet, ma rende anche l'impostazione didattica molto complicata. Analizzare gli argomenti di Internet esattamente come si verificano nella realtà sarebbe didatticamente disastroso. In ogni argomento si mescolano infatti:
  1. elementi necessari per il funzionamento e fondamentali per la comprensione dell'argomento;
  2. elementi non necessari per il funzionamento e/o non fondamentali per la comprensione;
Gli elementi 2 purtroppo sono tantissimi. In ogni argomento visto così come si verifica nella realtà ci sono infatti elementi:

  1. inutili (anche se non ci fossero non cambierebbe nulla);
  2. duplicati (più componenti che risolvono lo stesso problema);
  3. dannosi (componenti che renderebbero il sistema più efficiente se non ci fossero);
  4. non fondamentali per la comprensione (necessari per motivi non tecnici o necessari per motivi tecnici irrilevanti);
  5. errati (i sistemi possono funzionare anche in presenza di comportamenti errati in alcune componenti);

Molto spesso, inoltre, ci sono anche elementi che:

  1. si studiano successivamente;
  2. si studiano in un corso successivo;
  3. non si studiano;

Quanto sopra è un dato di fatto. 

Una impostazione "completamente pratica", quindi, avrebbe l'effetto di fornire una idea estremamente nebulosa sul come funzionano le cose e perché sono state fatte in quel modo. Effetto didatticamente disastroso. Come risolvere questo enorme problema didattico?

Una possibilità potrebbe essere quella di prendere l'approccio opposto: impostare il corso in modo "completamente teorico", prescindendo completamente dall'esperienza quotidiana. Anche questo approccio secondo me è sbagliato, seppur migliore dell'altro.

Cerco quindi di fare un compromesso tra i due estremi. Cerco di individuare per ogni argomento il sottoinsieme delle informazioni necessarie e fondamentali. Per me è molto complicato e faticoso, ve lo garantisco, ma in questo modo si dovrebbe riuscire a capire meglio il come ed il perché. Ovviamente quando lo studente cerca di fare la corrispondenza tra quanto fatto a lezione e l'esperienza quotidiana mancano sempre alcuni elementi, pochi o molti ma mancano. A me sembra comunque il male minore, un buon compromesso tra tutti i vincoli e gli obbiettivi.

E' importantissimo che lo studente si faccia sempre domande e cerchi sempre di mettere in corrispondenza quanto visto a lezione con l'esperienza quotidiana. Importantissimo. Occorre però essere consapevoli che la corrispondenza sarà sempre parziale e non del tutto accurata, per i motivi discussi. Occorre inoltre evitare di cadere nell'approccio "questo non lo capisco, quindi non sarà importante o sarà troppo complicato per me"---in questo modo non si capisce nulla. Purtroppo a priori uno non sa se un aspetto sfugge perché è giusto che sfugga oppure perché non lo si è capito o non ci si è riflettuto abbastanza. Studiare è impegnativo, c'è poco da fare.

Ultima osservazione. Nel mail precedente ho scritto vi ho descritto un sottoinsieme delle regole .it;. E' proprio così, in ogni argomento cerco di semplificare fornendo parte delle informazioni; quasi mai fornisco informazioni diverse dalla realtà.

A volte mi capita di restringere troppo il sottoinsieme ed effettivamente manca qualcosa, in quel caso cerco di integrare. Questo problema però capita di rado, solo quando faccio modifiche significative al programma (ad esempio, con l'approfondimento sul ruolo dei registrar nel DNS). In alcuni casi, pochissimi, invece di descrivere una parte della verità scelgo di descrivere una cosa leggermente diversa dalla verità (ad esempio, wifi e https).

lunedì 2 marzo 2015

Attacchi al DNS

Come sempre, nella prima lezione sul DNS ho richiamato l'attenzione sulla possibilità di alterare in modo fraudolento la traduzione da nomi ad indirizzi IP---ad esempio, www.unicredit.it potrebbe essere tradotto in IP-criminale invece che in IP-del-vero-server.

Ho citato solo alcuni dei numerosi modi per farlo: minacciare l'amministratore del name server con una pistola, inserire un malware nel name server. I modi possibili sono ovviamente moltissimi altri e molti saranno discussi nelle prossime lezioni (avevo peraltro dimenticato di evidenziare che l'amministratore stesso del name server potrebbe essere parte della gang...).

L'alterazione fraudolenta delle traduzioni da nomi ad indirizzi IP non è una possibilità teorica. E' un evento che accade relativamente spesso. Al link qui sotto ho messo una raccolta di notizie di questo genere, dovrebbero essere 75 (settantacinque).

(UPDATE FEBBRAIO 2015: nella pagina al link qui sotto, inserire "DNS" nella casella di ricerca; la pagina adesso non elenca solo news legate al DNS ma anche altre news legate a questo post; se a qualcuno interessano queste bruttissime cose, trova una raccolta aggiornata frequentemente a questo link)

https://www.evernote.com/pub/bartolialberto/news-selected-public

lunedì 23 febbraio 2015

Sfera di cristallo ("de novo")

Negli scorsi mesi si sono verificati molti eventi di sicurezza informatica estremamente importanti. Mi ero ripromesso di analizzarli in questo blog, ma rimando continuamente perché non riesco mai a trovare il tempo e la tranquillità necessarie---le implicazioni di questi numerosi eventi sono davvero molte e molto profonde.

Nei giorni scorsi si sono però verificati altri eventi che non posso fare a meno di citare, anche se non ho il tempo di commentarli.

  1. Un gruppo di criminali ha effettuato una truffa informatica su larga scala. L'aspetto importante non è il fatto in sè e per sé e neanche l'entità della truffa (alcune centinaia di milioni di euro), bensì le sue modalità. Gli attaccanti hanno penetrato i sistemi interni della banca, collegandosi per molti giorni durante gli stessi orari dei dipendenti in modo da non generare anomalie di accesso. Hanno effettuato operazioni fraudolente cancellandone subito dopo gli effetti dai log e dagli estratti conto. Hanno fatto uscire 7 milioni di euro in contanti programmando i bancomat in modo da fare uscire soldi ad istanti di tempo prefissati---qualcosa come "fai uscire 8000 euro in Via Ginnastica alle 02.27 di stanotte".
    http://www.nytimes.com/2015/02/15/world/bank-hackers-steal-millions-via-malware.html?_r=0
  2. Un grande fabbricante di PC da anni vende PC il cui truststore e keystore contiene un certificato scelto dal fabbricante stesso. Inoltre, i PC contengono software che redirige tutto il traffico HTTPS verso un server controllato dal fabbricante, per il quale viene generato sul momento un certificato trusted (firmato dalla chiave privata associata al certificato installato dal fabbricante; il server è un proxy in esecuzione sul PC stesso, ma ciò è irrilevante). Gli utenti quindi non si accorgono di nulla. Inutile dire che quel software è in grado di alterare ogni pagina visitata dai browser, vedere ogni informazione inserita dall'utente, generare traffico per conto dell'utente etc. Su ogni sito.
    http://marcrogers.org/2015/02/19/lenovo-installs-adware-on-customer-laptops-and-compromises-all-ssl/
    http://blog.erratasec.com/2015/02/some-notes-on-superfish.html
  3. I servizi segreti statunitense e britannico hanno rubato (questo è il termine corretto) le chiavi crittografiche inserite in tutte le SIM fabbricate da uno dei più grandi fabbricanti al mondo, un'azienda olandese (il traffico telefonico generato da uno smartphone è crittato con crittografia a chiave privata, usando una chiave condivisa tra la SIM e l'operatore telefonico). Sono riusciti a farlo con tecniche di attacco informatico non particolarmente sofisticate---phishing mirati e cose del genere. La cosa importante non è che adesso sono in grado di intercettare tutto il traffico telefonico corrispondente, in maniera completamente non rilevabile, quanto il fatto di essere riusciti a prelevare in modo fraudolento e su larga scala delle credenziali così importanti.
    https://firstlook.org/theintercept/2015/02/19/great-sim-heist/


Ci sarebbe davvero molto, molto da discutere di queste faccende. Non tanto sugli aspetti etici quanto sulle implicazioni per la nostra società. Penso comunque che la lettura di queste notizie sia sufficiente almeno ad intuirne la portata---davvero estesa e dirompente.

Ancora una volta ho la piccola soddisfazione di vedere concretizzate alcune delle eventualità che vado raccontando da anni quando parlo di sicurezza informatica. Eventualità che, forse, per molti mi fanno rientrare nella categoria dei "fissati" o di chi si preoccupa di mere "curiosità teoriche".

Purtroppo nella testa mi frullano anche altre cose, ancora più gravi di queste. Sinora non ne ho mai parlato in pubblico, ne ho solo accennato agli studenti di Reti di Calcolatori II pochi mesi fa. Spero di non vedere concretizzare anche quelle...

giovedì 8 gennaio 2015

Miglior docente dell'anno (!)

Da tempo combatto con la sensazione di lavorare inutilmente. Questa notizia mi fa quindi molto, molto piacere. E' bello sapere che il proprio lavoro viene apprezzato.

Grazie.



(from www.units.it)

Il prof. Bartoli "miglior docente dell’anno" del c.d.l. in Ingegneria Elettronica e Informatica

Quando: 07/01/2015
Il prof. Bartoli nominato "miglior docente dell'anno" per la laurea triennale in "Ingegneria Elettronica e Informatica".

Nell'ambito di valutazione della didattica da parte degli studenti, attività avviata nei corsi di laurea triennale e magistrale in Ingegneria dell’Informazione (ICT, Information and Communication Technology) dell’Università di Trieste già da alcuni anni, emerge quest’anno la figura del prof. Bartoli, il quale, oltre ad aver ottenuto punteggi particolarmente elevati, ha ricevuto numerosi elogi da parte degli studenti. Nello spazio del questionario riservato a "ulteriori commenti e suggerimenti", e solitamente utilizzato per esporre critiche e criticità, gli studenti hanno scritto infatti commenti quali
·         «È difficile immaginare un modo in cui migliorare questo corso, perchèè già tenuto in modo eccellente; è uno dei corsi meglio curati che abbia seguito in tutto il corso di laurea.»
·         «Il professor Bartoli è un ottimo insegnante, spiega benissimo ed è stimolante.»«Il corso è bello, utile e interessante.»
·         «Ottimo professore: simpatico, chiarissimo, disponibile, organizzatissimo. Un corso perfetto.»
·         «TUTTI i professori dovrebbero essere come Alberto Bartoli.»

Il Consiglio di Corso di Studi della laurea triennale in Ingegneria Elettronica e Informatica, riunitosi in data 18/12/2014, ha deciso quindi di nominare il prof. Bartoli "miglior docente dell’anno".

Il prof. Bartoli, docente di Reti di Calcolatori alla laurea triennale in Ingegneria Elettronica e Informatica e di Programmazione Distribuita e Reti di Calcolatori II alla laurea magistrale in Ingegneria Informatica, è Direttore del Machine Learning Lab del Dipartimento di Ingegneria e Architettura, dove si occupa di applicazioni di machine learning a problematiche di ingegneria, in particolare sicurezza informatica e elaborazione automatica dell’informazione (per esempio, analisi del linguaggio naturale nei messaggi dei social network per il riconoscimento dell’umore dell’autore).
Nel febbraio 2004 ha tenuto la Prolusione Scientifica in occasione della cerimonia di inaugurazione dell’anno accademico 2003/2004 dell’Università di Trieste, alla presenza del Ministro per l’Innovazione e le Tecnologie.