lunedì 18 novembre 2013

Duemila morti a causa di una trasmissione di prova con Enigma

Quando parlo di crittografia a Reti di Calcolatori I descrivo in modo intuitivo ed informale un requisito di base di ogni algoritmo: la conoscenza del testo cifrato non deve fornire nessuna informazione sul corrispondente testo in chiaro o sulla chiave utilizzata.

La macchina cifrante Enigma non aveva questa proprietà. Anche per questo motivo gli Alleati hanno vinto la seconda guerra mondiale. Ed anche per questo motivo, i padri ed i nonni di alcuni di noi sono andati incontro ad una tragedia terribile, la battaglia navale di Capo Matapan.

Immaginate di essere a bordo di una nave militare in tempo di guerra, in mezzo alle acque gelide del Mar Mediterraneo. Su di una nave impossibilitata a muoversi. Di notte e al buio. Immaginate poi di attendere per ore i soccorsi, senza sapere se arriveranno prima i soccorsi o il nemico. Immaginate poi di sentire arrivare un convoglio navale e di vedere la vostra nave che lancia un razzo di segnalazione pensando che siano i soccorsi. Immaginate poi di rendervi conto che si tratta del nemico. Poi arrivano le cannonate. Cannonate che pochi minuti dopo arrivano anche verso il convoglio di soccorso. Totale di morti stimato circa duemilatrecentotrenta.

Cosa c'entra Capo Matapan con il requisito di cui sopra ? Enigma non aveva quella proprietà. Gli Inglesi intercettevano continuamente il traffico radio Enigma ed erano quindi in grado di estrarre informazioni sulla chiave utilizzata. Ciò non assicurava automaticamente la possibilità di decrittare il traffico: l'estrazione di informazioni era manuale, osservando le trascrizioni senza senso del traffico cifrato; il traffico era tantissimo; la chiave cambiava ogni giorno. Quando andava bene (per loro) riuscivano a ridurre molto il numero delle chiavi possibili in base alla mera analisi manuale e poi le provavano tutte, usando a tale scopo il primo calcolatore mai realizzato ("Colossus").

Una crittoanalista inglese, analizzando il traffico intercettato del giorno, si accorse che quasi certamente era la cifratura del testo "LLLLLLLLLLLLLLL": una trasmissione di prova da parte di operatori italiani che stavano provando Enigma. Ciò le permise di restringere grandemente l'insieme di chiavi del giorno---proprio perché il traffico cifrato Enigma forniva informazioni sul testo in chiaro e sulla chiave. Il che permise agli Inglesi di decrittare i messaggi crittati in quella chiave. Il che portò alla terribile tragedia di Capo Matapan.


mercoledì 6 novembre 2013

Un bollitore d'acqua che propaga virus

Nell'ultimo post e nelle ultime lezioni di Reti II abbiamo parlato del problema della mutua autenticazione tra "dispositivi" generici, diversi da PC o smartphone, in WiFi. Nei prossimi anni vedremo certamente moltissimi esempi di dispositivi, anche in ambito domestico, da collegare via WiFi al proprio access point: cardiofrequenzimetri, frigoriferi, macchine fotografiche, ripetitori WiFi, game console, elettrodomestici vari...

Il problema di fondo consiste nell'inserire una forma di password in un dispositivo che non ha una tastiera o che non è stato concepito per inserirvi del testo. Come discusso nell'ultimo post, esiste uno standard per risolvere questo problema in modo semplice: si preme un bottone sul dispositivo ed un bottone sull'access point (ovviamente predisposti per questo standard); i due dispositivi si autenticano mutuamente per sempre.

Questo procedimento assume che al momento in cui si preme il bottone non ci siano dispositivi "maligni" in giro per casa. E' facile rendersi conto che un dispositivo maligno può imbrogliare le cose senza che l'utente si accorga di nulla. Si può arrivare a situazioni in cui il dispositivo maligno può osservare ogni comunicazione tra dispositivo ed access point, o peggio ancora in cui ogni comunicazione passa attraverso il dispositivo maligno, con tutto ciò che ne consegue. Oppure a situazioni in cui il dispositivo maligno semplicemente si autentica in modo autonomo nei confronti dell'access point, con l'effetto che l'utente si trova in casa dispositivi che comunicano con il proprio access point senza sospettarne neanche l'esistenza.

Bene, sembra che quest'ultimo scenario si stia già iniziando a diffondere. Una fonte di solito molto seria ed autorevole afferma che in Russia sono stati identificati dei bollitori domestici fabbricati in Cina che contengono piccoli computer in grado di "sending spam and distribute malware". Questi computer funzionano solo su reti WiFi aperte, ma il passo verso le reti WiFi protette è il successivo.

Continuo a pensare che il sistema di autenticazione che abbiamo realizzato noi in laboratorio sarebbe davvero una bella cosa, per praticità e sicurezza...(vedi fine dell'ultimo post).

giovedì 31 ottobre 2013

Come indovinare una password Wi-Fi

Anche oggi, come nell'ultimo post di qualche settimana fa, dopo la lezione di Reti di Calcolatori II ho trovato una notizia proprio sull'argomento della lezione: autenticazione su reti Wi-Fi e, in particolare, come indovinare la password tramite dictionary attack offline:

A new, free, open-source tool called Reaver exploits a security hole in wireless routers and can crack most routers' current passwords with relative ease. Here's how to crack a WPA or WPA2 password, step by step, with Reaver—and how to protect your network against Reaver attacks.

Il tool non opera come abbiamo ipotizzato a lezione---osservando il traffico di challenge e response tra access point e nodi che si autenticano---ed utilizza invece una componente di WPA che non abbiamo visto per stimolare l'access point a generare traffico. In questo modo il tool riesce ad avere a disposizione una quantità "adeguata" di traffico per la crittoanalisi molto più rapidamente.

La componente di WPA utilizzata per l'attacco è il Wireless Protected Setup (WPS): un protocollo che permette di "accoppiare facilmente" due dispositivi wireless. In parole povere, avendo un access point ed un nodo che supporta WPS (ad esempio uno smartphone, un PC, un qualche sensore etc), invece di inserire nel nodo la password si preme un bottone sui due dispositivi a brevissima distanza di tempo ed i due dispositivi si autenticano mutuamente. L'autenticazione permane anche per il futuro. Il protocollo è molto semplice e comodo, ed è utilizzabile anche in dispositivi che non hanno una tastiera (in cui quindi l'inserimento di una password è molto complicato o addirittura impossibile). Ovviamente, l'ipotesi di base è che durante l'esecuzione del protocollo non ci siano dispositivi controllati dall'attaccante (se questa ipotesi sia realistica o meno ovviamente è un altro problema).

Il tool descritto nell'articolo sfrutta la componente WPS degli access point e funziona solo con gli access point che hanno questa funzionalità. Sembra che tutti quelli più moderni ce l'abbiano.

Per inciso, un paio d'anni fa avevamo sviluppato un bel sistemino per risolvere lo stesso problema di WPS in modo molto più sicuro, nel senso di molto più difficile da attaccare: l'idea consisteva nell'accoppiare fisicamente uno schermo ed una webcam, dispositivi ormai presenti ovunque e di costo molto basso: http://reti-inginf-units.blogspot.it/2011/11/la-mia-assenza-della-settimana-scorsa.html

martedì 8 ottobre 2013

Come aumentare i propri voti

Proprio nella lezione di oggi, a Reti di Calcolatori II, abbiamo parlato di ipotesi sugli attacchi ("threat model"), credenziali che viaggiano in chiaro, errori software ed altre amenità del genere.

Appena tornato in ufficio ho letto questa notizia sul "Corriere della Sera", esattamente ciò di cui abbiamo parlato pochi minuti fa:

Truccare il registro? Se è elettronico si può
Il software scelto da 1.300 scuole ha una falla: le credenziali dei prof viaggiano in chiaro, gli studenti possono rubarle

Questa descrizione, peraltro, è discutibile: quando si parla di "falla" di solito si intende che la soluzione ad un certo problema è stata realizzata in modo imperfetto. I progettisti si sono preoccupati del problema, hanno individuato e realizzato delle soluzioni, ma hanno lasciato qualche scenario non previsto dalle soluzioni. In questo caso non mi sembra che si possa trattare di "falla". Sembra che del problema non si siano neanche preoccupati.

La faccenda è triste per tanti motivi e potrebbe essere elaborata da tanti punti di vista: predisposizione del nostro paese all'innovazione, digitalizzazione della pubblica amministrazione, importanza della competenza tecnica etc. Non ho il tempo e la voglia per farlo. Segnalo solo le spiegazioni fornite dall'amministratore delegato dell'azienda, davvero non trovo aggettivi adatti per qualificarle. Dateci un'occhiata.

Spero che il titolo di questo post non abbia generato false aspettative: "come aumentare i propri voti" ma non a Reti (almeno, non con questo metodo).

mercoledì 2 ottobre 2013

Valutazione della didattica

Sono usciti i risultati della valutazione della didattica per lo scorso anno 2012/2013. I risultati non sono consultabili facilmente in quanto l'applicativo web ha una interfaccia pessima.

Le domande secondo me più importanti sono D7, D8 e D15: "Docente stimola e motiva interesse ?", "Spiega in modo chiaro ?", "Soddisfatto del corso ?".

Nelle valutazioni aggregate per corso di studio il corso di laurea magistrale in Ingegneria Informatica è stato il migliore di tutti i corsi del Dipartimento per D8 e D15 ed è ai vertici tra i corsi dell'intero ateneo (dettagli).

La mia valutazione personale è stata ottima, come gli anni scorsi. Sono molto contento di questo risultato e ringrazio gli studenti che sono stati così "benevolenti" nei miei confronti.

Reti di Calcolatori II 10/10 di media, quindi tutti gli studenti hanno fornito una valutazione massima (anche in D4 e D5):


Programmazione Distribuita 10/10 in D8 e D15, 9.33 in D7:



Reti di Calcolatori 8.90, 8.85 e 8.90 (medie del corso di laurea 6.96, 7.01, 7.12).


In questo caso le colonne da considerare sono il gruppo "equipollenti" sulla destra, in quanto questo insegnamento è erogato in molti corsi di laurea per cui ogni corso ha dati parziali; le colonne "equipollenti" raggruppano i dati dello stesso insegnamento; l'immagine è relativa alla triennale in Ing. dell'Informazione).


lunedì 30 settembre 2013

Plauso ad Eric e Andrea

Venerdi scorso si è tenuta la cosiddetta "Notte Europea dei Ricercatori (NEAR)" simultaneamente in varie città europee, tra le quali Trieste.

Il Machine Learning Lab ha partecipato con uno stand in cui veniva mostrato un applicativo web, sviluppato da Eric Medvet, in grado di indovinare l'età della persona seduta di fronte al calcolatore. L'applicativo, pur essendo strutturato sotto forma "scherzosa e di gioco", incorporava tecnologie ed algoritmi all'avanguardia.
Lo stand ha riscosso notevole successo ed interesse di pubblico.

Desidero ringraziare pubblicamente Eric Medvet ed Andrea De Lorenzo per il loro impegno ed entusiasmo. Desidero anche sottolineare che io non ho alcun merito in questa attività, dal momento che non ho fatto nulla di nulla: non ho partecipato all'implementazione dell'applicativo, non li ho incoraggiati...non sono neanche riuscito a passare dallo stand. Nulla di nulla, solo ed esclusivamente merito loro. L'unica cosa che ho fatto, non so con quanto successo, è stato cercare di non trasmettere in modo troppo esplicito la mia opinione sulle iniziative di questo genere ed il mio conseguente pessimismo.

Bravi.

venerdì 20 settembre 2013

Valutazione Qualità della Ricerca (VQR)

E' stata effettuata recentemente una valutazione della qualità della ricerca di tutti gli atenei italiani.

Ogni docente ha dovuto selezionare 3 prodotti recenti (chi è docente da pochi anni solo 1). Una commissione centrale ha valutato ognuno di questi prodotti secondo la scala seguente:


Erano possibili anche valutazioni negative, in caso di plagio o di prodotti mancanti.

La valutazione dei miei prodotti è stata la seguente.


Per inciso, l'area dell'Ingegneria Industriale e dell'Informazione non ha avuto un risultato lusinghiero. Il motivo principale consiste nel fatto che l'aggregazione dei risultati aveva lo scopo di penalizzare la presenza di ricercatori poco produttivi. Nella valutazione precedente, di pochi anni fa, la nostra area era stata classificata al primo posto a livello nazionale. In quel caso l'aggregazione era fatta in modo completamente diverso e la presenza di ricercatori poco produttivi era sostanzialmente ininfluente.

giovedì 8 agosto 2013

Qualcuno si ricorda del modello OSI ?

Fino a qualche anno fa ogni testo o corso di Reti di Calcolatori iniziava immancabilmente con la descrizione del cosiddetto "modello ISO/OSI". Per molti, molti anni chiunque avesse a che fare con il networking si trovava a che fare con la cosiddetta "pila dei 7 livelli ISO/OSI":


Oggi del modello OSI non se ne parla più, giustamente. Quando ho iniziato a tenere il corso di Reti ne ho parlato anch'io molto brevemente, se non ricordo male solo per le prime due edizioni. Poi ho smesso completamente di farlo---e devo dire di sentirmi orgoglioso per avere smesso di trattarlo così presto. Un recente articolo su IEEE Spectrum racconta la storia del modello OSI in modo molto ameno e leggibile ("The Internet that wasn't", accessibile solo dalla rete di ateneo).

Io sono, diciamo così, passato attraverso tutte le fasi del modello. Quando ero uno studente dell'ultimo anno di Ingegneria Elettronica (1988/89) il modello OSI ci veniva presentato come un mondo fantastico ed inevitabileappena dietro l'angolo---non esisteva ancora ma sarebbe esistito molto presto ed ovunque.

Per capire perché OSI avrebbe creato un mondo fantastico, occorre tenere presente che a quei tempi Internet era praticamente inesistente:
  1. Pochissime organizzazioni avevano una network. C'erano solo i minicomputer (macchine con una decina di terminali a caratteri) ed i primissimi PC o Mac. Quasi mai erano collegati ad una network.
  2. Inoltre, network diverse erano quasi sempre isolate tra loro.
L'invio di messaggi da una network ad un'altra era complicatissimo perché era difficile trovare un protocollo adatto ad entrambe le network e del quale esistessero due implementazioni (una per ogni network) in grado di essere eseguite sul nodo gateway (oggi lo chiamiamo router).

Inoltre, perché mai uno doveva fare una cosa così complicata e costosa ? La comunicazione tra nodi è utile solo se i nodi eseguono applicazioni in grado di cooperare tra di loro, il che richiede altri protocolli ed altre implementazioni. A quei tempi non c'era nulla di tutto questo. In pratica, il massimo che si riusciva a fare era trasferire un file da un nodo all'altro. Qualcosa che si riusciva a fare anche con i floppy disk.

OSI era la promessa di un mondo fantastico, in cui magicamente tutte le network avrebbero potuto essere collegate tra di loro ed i relativi software avrebbero potuto cooperare a tutti i livelli di astrazione. Qualcosa che oggi è normalissimo ma a quei tempi era, appunto, una sorta di sogno.

Una precisazione: Internet esisteva, ma collegava solo alcune network di alcuni enti di ricerca. In questi enti, erano pochissimi i calcolatori collegati ad Internet, tipicamente solo alcuni minicomputer. L'uso pratico di Internet non era neanche paragonabile a quello odierno, serviva solo per trasferire file, leggere le news USENET ed inviare mail. La mail non era neanche paragonabile a quella odierna: pochissimi avevano un account mail e trovare l'indirizzo mail di qualcuno che non si conosceva personalmente era un'impresa---il web non esisteva.

Il sogno di OSI, questo mondo fantastico appena dietro l'angolo, è rimasto tale per anni. Ormai ci siamo, ormai ci siamo...ma non accadeva mai. Nel frattempo, Internet ed i protocolli TCP/IP prosperavano e si diffondevano. I libri di testo ed i corsi continuavano a parlare di OSI. Ma nessuno lo vedeva in pratica. Nessuno capiva quasi nulla di OSI, anche perché chi aveva una qualche esperienza pratica aveva usato ftp o la email su Internet; chi aveva più esperienza conosceva gli indirizzi IP, Ethernet ed un pò di routing IP. Mettere in corrispondenza queste entità con il modello OSI era un'impresa.

In estrema sintesi, ed in modo impreciso: il modello OSI era un elenco di funzionalità da implementare ad ognuno dei 7 livelli di astrazione definiti dal modello; ed un elenco di protocolli che implementavano quelle funzionalità. Internet invece era un piccolo insieme di protocolli molto semplici, senza alcun "modello". Il modello OSI non si diffondeva perché, molto banalmente, le implementazioni dei protocolli erano poche, complicate, inefficienti e costose. Le implementazioni dei protocolli Internet invece erano molte, semplici, rapide e gratuite.

Quando, nel 2000/2001, ho tenuto per la prima volta il corso di Reti di Calcolatori era ormai chiaro che Internet aveva sconfitto definitivamente OSI. Non ho avuto il coraggio di omettere completamente OSI perché se ne parlava ancora molto nei libri di testo. Mi sembra di averlo cassato completamente nella terza edizione.

Concludo con un aneddoto (divertente solo per chi conosce i docenti coinvolti, penso nessuno tra quelli che leggeranno questo blog). Quando ero studente del quinto anno, il docente del corso di "Macchine per l'elaborazione dell'informazione" (corso che verteva sull'hardware dei sistemi multiprocessore...le reti non erano parte dei programmi) organizzò dei seminari tenuti da una persona coinvolta nella definizione del modello OSI. I seminari erano quasi incomprensibili perché il modello OSI era, appunto, un "modello" e nessuno di noi sapeva nulla di reti. L'unica cosa che capivamo era l'enfasi sulla interoperabilità tra i sistemi. La cosa era divertente (e, ripeto, lo possono capire solo quelli che conoscono i due docenti) perché il docente del seminario pomeridiano ci esaltava il fantastico modello OSI, poi la mattina successiva il docente a lezione ci diceva "tanto di OSI non è vero nulla...se avete un computer Digital vi servono i protocolli Digital e se avete un IBM vi servono i protocolli IBM...fra loro non si parlano..non c'è niente da fare, OSI non funziona..."

venerdì 14 giugno 2013

Gli hacker sono davvero un rischio reale per le banche ?

E' appena uscita una notizia secondo me importantissima ma che, ancora secondo me, passerà del tutto inosservata.

Hacking attacks present a bigger risk to the operation of UK banks than problems caused by the ongoing eurozone crisis, according to a senior Bank of England director.

Andrew Haldane, the Bank of England's director of financial stability, told parliament's Treasury Select Committee that representatives of Britain's top banks are telling him that cyber attacks have become their biggest threat over recent months.

Rileggere lentamente, un paio di volte.

Impossibile esprimerlo in modo più chiaro e più diretto.

giovedì 6 giugno 2013

Phishing in siti fidati

Lasciatemi dire che è una piccola soddisfazione...nonché un altro esempio di sfera di cristallo.

Pochi giorni fa hanno accettato un nostro lavoro ad una importante conferenza internazionale di sicurezza informatica:

we developed a methodology for detecting fraudulent pages within trusted sites, that is, pages created by attackers within web sites of trusted organizations and placed at URLs at which no page is supposed (by the administrators of those sites) to exist. 
...
The problem is highly relevant for many reasons, including: HTTPS does not provide any defense in this respect (the fraudulent pages are hosted on sites that, from HTTPS point of view, are authenticated and with content integrity);

Pochi minuti fa, un grande Internet provider inglese, probabilmente il più grande provider al mondo, ha pubblicato un blog post in cui informa che sul sito della Polizia della Malesia è in corso un attacco di phishing proprio del genere indicato nel nostro studio (problema che non molti stanno studiando).

In altre parole, l'attacco è strutturato in questo modo:
  1. Inserimento fraudolento di una pagina identica a quella di PayPal nel sito della Polizia della Malesia.
  2. Campagna di phishing in cui si tenta di portare utenti all'URL creato al punto precedente.
  3. Gli utenti che arrivano a quell'URL vedono un sito completamente fidato dal punto di vista SSL, e probabilmente anche dal punto di vista di molti filtri anti-phishing (il sito della polizia della Malesia non può che essere considerato fidato). Ergo, inseriscono le proprie credenziali PayPal senza sospettare nulla...

giovedì 23 maggio 2013

Form delle credenziali su HTTP


Nella lezione di ieri abbiamo descritto HTTPS, il protocollo utilizzato comunemente per accedere a servizi autenticati (GMail, Facebook, banche, acquisti on line, etc).

Abbiamo evidenziato che di norma il web server espone il form nel quale inserire le credenziali attraverso HTTPS. Ciò sembra inutile, in quanto non c'è nessun vantaggio nell'imporre che la richiesta di prelievo del form e lo stesso form viaggino con garanzia di riservatezza. La riservatezza è necessaria solo per la richiesta inviata subito dopo avere prelevato il form, cioè per la richiesta che contiene le credenziali. Questa slide sintetizza il motivo per il quale prelevare il form su HTTPS sembra inutile ma non lo è:


Secondo molti esperti, nel 2011 il governo della Tunisia ha forzato tutti gli Internet provider del paese a modificare i form esposti su HTTP dai servizi "importanti" (GMail, Facebook etc). Nelle pagine contenenti i form venivano aggiunte, durante il transito dal server al browser, un paio di linee Javascript. Questo codice, eseguito sul browser durante la visualizzazione della pagina contenente il form, prelevava le credenziali inserite dall'utente e le inviava ad una locazione scelta dall'attaccante (ometto alcuni dettagli tecnici irrilevanti su questo punto).

Questo è un esempio lampante di cosa può accadere quando i form sono esposti su HTTP e non su HTTPS: l'integrità dei messaggi non è garantita, ergo possono essere modificati in transito senza che il destinatario se ne accorga.

I dettagli sono indicati qui: Tunisian government harvesting usernames and passwords

Ho scoperto questo aneddoto, che non conoscevo, perché proprio stamani mattina mi sono imbattuto su un articolo che discute questo aspetto specifico in dettaglio:

Your login form posts to HTTPS, but you blew it when you loaded it over HTTP

(per inciso, già altre volte mi è capitato di avere una sorta di sfera di cristallo per prevedere il futuro: agli studenti dico una cosa che potrebbe accadere, probabilmente loro pensano che sono paranoico o fissato, e dopo qualche giorno quella cosa si verifica davvero; riporto un paio di esempi in coda a questo post).

Non è semplicissimo da leggere ma ha alcuni punti molto chiari, proprio sugli aspetti evidenziati ieri:
  • Loading login forms over HTTP renders any transport layer security almost entirely useless.
  • What people forget about SSL is that it’s not about encryption. Well that’s one feature of secure sockets, another really essential one is integrity insofar as it gives us confidence that the website content hasn’t been manipulated. Anything you load over an HTTP connection can be easily changed by a man in the middle which is why it’s absolutely essential to load those login forms over a secure connection.
L'articolo mostra anche esempi di siti molto importanti che NON espongono il form delle credenziali su HTTPS (e quindi sono fatti male).

Sfera di cristallo (esempi di mia previsione del futuro):


mercoledì 22 maggio 2013

Come si prende un virus con il browser

Un esempio semplice ed istruttivo.

Prima:

Utente che:
Dopo:
  1. Utente ha in esecuzione un nuovo programma, senza saperlo;
  2. Questo programma, che può fare tutto ciò che può fare l'utentericeve comandi da un attaccante esterno.
Prima di procedere nella lettura leggere e rileggere questi due punti in modo da comprenderne le implicazioni (tragedia !!!)

Spiegazione:


Federal News Radio 1500 AM and FederalNewsRadio.com comprise the key source of breaking news, information and analysis for the individuals responsible for carrying out and supporting the missions of federal agencies. Federal News Radio addresses federal agency managers, policy makers and contractors. ...
We cover both the federal government and those who do business with the government concentrating on management, defense, technology, contracting, policy and pay & benefits.


WTOP is an all-news formatted broadcast radio station licensed to Washington, D.C., serving Metropolitan Washington, DC area.

Ieri sera sulla mailing list dell'US-CERT (United States Computer Emergency Readiness Team) è stato inviato un avviso, appunto, semplice ed istruttivo relativo a questi due siti, che nel frattempo sono stati ripuliti:

On May 16, 2013, US-CERT was notified that both www.federalnewsradio[.]com and www.wtop[.]com had been compromised to redirect Internet Explorer users to an exploit kit. The compromised websites were modified to contain a hidden iframe referencing a JavaScript file on a dynamic-DNS host. The file returned from this site was identified as the Fiesta Exploit Kit.
Cioè, gli attaccanti hanno fatto in modo di inserire un paio di linee HTML nel contenuto servito da questi siti. Queste linee dicono al browser "carica il file Javascript F che si trova sul server N ed eseguilo". Il file F è il file maligno generato appositamente dall'attaccante (Fiesta Exploit Kit), mentre il server N è associato ad un indirizzo IP che varia rapidamente (non è essenziale approfondire) e che corrisponde ad un calcolatore su cui l'attaccante ha messo un piccolo server web dal quale prelevare F.
The exploit kit script uses one of several known vulnerabilities to attempt to download an executable:
Any systems visiting running vulnerable versions of Adobe Reader or Acrobat or Oracle Java may have been compromised.

Cioè, il file Javascript eseguito dal browser provoca il download da parte del browser di file PDF e file Java generati opportunamente dall'attaccante. Il contenuto del file PDF sfrutta errori software dei programmi Adobe Reader e Adobe Acrobat per fare eseguire, a questi stessi programmi, un piccolo programma scelto dall'attaccante. Il contenuto del file Java sfrutta errori software di Java 7 per fare la stessa cosa. L'attaccante usa più strategie invece di una sola in modo da aumentare la probabilità di trovare installato uno di questi 3 programmi, nella versione che abbia gli errori a lui necessari---a lui basta che sia installato uno di quei programmi.

Questo piccolo programma scarica e manda in esecuzione sul PC del browser un programma più complicato e molto più pericoloso: 
a known variant of the ZeroAccess Trojan. Additionally, according to open source reporting, the malware also downloads and installs a variant of FakeAV/Kazy malware.
The ZeroAccess Trojan attempts to beacon to one of two hardcoded command-and-control addresses, 194.165.17.3 and 209.68.32.176. The beaconing occurs using an HTTP GET using the Opera/10 user-agent string.
After beaconing, the malware then downloads a custom Microsoft Cabinet file and the malware uses port UDP/16464 to connect to the peer-to-peer network...

Alla fine, il PC dell'utente ha in esecuzione un programma (ZeroAccess Trojan) che si collega ad una network "command and control" ed è quindi controllato da remoto da un attaccante.

lunedì 20 maggio 2013

Crittografia quantica o quantistica

Crittografia quantica, un passo avanti significativo
Ricercatori dell'agenzia spaziale tedesca aprono la strada per una rete mondiale di comunicazioni satellitari supersicure.
...La crittografia quantistica è una specie di santo Graal per i crittografi, in quanto dovrebbe permettere di rendere inattaccabili le comunicazioni. Essa permetterebbe infatti ai due soggetti della comunicazioni di rendersi immediatamente conto di un eventuale intruso...
(link)


Premessa:

  1. Non sono un esperto di crittografia.
  2. Tutto ciò che so della notizia indicata qui sopra è contenuto nella notizia stessa (anche se ho letto varie riflessioni, in passato, sulla crittografia quantistica e cose di questo genere)
  3. Tutto quanto segue è implicitamente preceduto da "secondo me".

E' bene rendersi conto che cose di questo genere in pratica servono a molto poco.

Se un ladro desidera entrare in un appartamento al piano terra che ha pareti spesse due metri e porte superblindate, ma ha le finestre aperte oppure apribili facilmente, ovviamente non si mette a sbattere la testa contro le pareti e non cerca di scardinare la porta. Entra dalla finestra.

Nell'informatica è la stessa cosa. Nessuno attacca la crittografia. Qualunque attaccante attacca le numerose componenti vulnerabili che esistono in ogni sistema.

La crittografia quantistica non farà altro che rendere ancora più spesse delle pareti che sono già spesse abbastanza.

(per approfondimenti: http://reti-inginf-units.blogspot.it/2010/03/crittografia-e-sicurezza-informatica.html)




venerdì 17 maggio 2013

Firewall: Tutto proibito o tutto permesso ?

In una recente lezione di Reti abbiamo detto che alla frontiera di ogni organizzazione c'è un firewall che analizza tutto il traffico entrante ed uscente. Abbiamo anche detto che:

  1. I firewall moderni sono del tipo "tutto proibito"; ad ogni pacchetto sono applicate le regole specificate dall'amministratore; se il pacchetto non soddisfa nessuna di queste regole, allora il pacchetto è buttato via; le regole cioè specificano il traffico permesso.
  2. In precedenza i firewall erano del tipo "tutto permesso": le regole specificano gli attacchi, invece del traffico lecito; se il pacchetto soddisfa una regola allora è buttato via.
  3. L'approccio "tutto proibito" è più difficile da configurare ma è preferibile a "tutto permesso", in quanto per usare "tutto permesso" è necessario 1) conoscere tutti gli attacchi; 2) aggiornare rapidissimamente le regole per rilevare gli attacchi, in quanto questi cambiano di continuo.

Un modo indiretto per avere una idea di "quanto" sia complicato realizzare il punto 3 si può avere con la considerazione seguente.

Molte organizzazioni utilizzano, in aggiunta e indipendentemente dai firewall, dei sistemi di "intrusion detection". Un sistema di questo genere è, concettualmente e semplificando, una sorta di firewall "tutto permesso": applica un insieme di regole che descrivono gli attacchi possibili ad ogni pacchetto; se un pacchetto soddisfa una regola, il pacchetto non è scartato ma viene generato un alert (oppure viene memorizzato il pacchetto su disco per analisi successive). Inoltre, le regole non si basano solo sugli header ma possono basarsi anche sul payload.

Uno dei sistemi di intrusion detection più diffusi è Snort. La comunità degli utenti Snort mantiene collettivamente le regole e le aggiorna periodicamente.

Bene, il numero di regole nella distribuzione di pochi giorni fa è 2500 (duemilacinquecento). Molte di queste regole possono essere inutili, se utilizzate in organizzazioni che hanno firewall "tutto proibito" (in tal caso infatti descrivono pattern di traffico che in quelle organizzazioni non si possono verificare). L'aspetto importante da notare è però proprio il fatto che la comunità ha costruito ben duemilacinquecento pattern di traffico sospetti...

giovedì 16 maggio 2013

"La crittografia / sicurezza mi ha sempre affascinato..."


sono un suo studente del corso di Reti I e la crittografia mi ha sempre affascinato. Credo che sia un mondo parecchio vasto e purtroppo in rete si trovano un sacco di informazioni sparse. 
Visto che oggi a lezione abbiamo ne abbiamo accennato vorrei chiederle se può consigliarmi dei testi, oppure uno in particolare, di riferimento sul quale iniziare a studiare (o approfondire) questi aspetti. 

Per iniziare ad approfondire, questo è un ottimo testo disponibile online (molto interessante ma secondo me non scritto in modo "scorrevole"):
L'autore è Ross Anderson, dell'Università di Cambridge. E' una persona che certamente le banche di mezzo mondo vorrebbero rinchiudere da qualche parte buttando via la chiave. Non perché sia un ladro, ma perché è quello che ha dimostrato che:
  1. Le truffe via Bancomat esistono veramente---prima le banche ne negavano l'esistenza, dicendo "hai scritto il PIN su un foglietto e te l'hanno rubato", "è stata tua moglie a fare il prelievo senza dirtelo" etc."Your bank statement arrives in the post, and you find a thousand pounds missing. Someone has been making ATM withdrawals using your card and your PIN. Yet your card wasn't stolen, you've told no-one your PIN, and you're careful to make sure you're not watched as you type it in. If this sounds like you, your dispute is a phantom withdrawal, and this website is designed to help you." (http://www.phantomwithdrawals.com)
  2. Le nuove tessere Bancomat introdotte da poco in tutta Europa, quelle con il chip, hanno errori di protocollo che permettono di fare tante cose interessanti---per i ladri (http://reti-inginf-units.blogspot.it/2010/03/bancomat-c.html).
Per studiare in modo approfondito la crittografia invece occorre considerare "il" libro:
di Bruce Schneier (non so se la copia linkata sia legale; è il primo risultato fornito da Google).

Se invece uno è interessato alla storia della crittografia, c'è un libro davvero fantastico che è anche una ottima lettura serale o estiva. Non si tratta di un libro tecnico, è una sorta di racconto scritto in modo molto semplice, accurato ed avvincente:
ATTENZIONE: spesso le persone sono "interessate alla crittografia" perché pensano che conoscere la crittografia sia importante per soddisfare il loro vero interesse, che è quello della "sicurezza informatica" in generale. In realtà sono pochi i casi in cui conoscere approfonditamente la crittografia sia davvero "utile / importante". A meno di non essere uno studioso di crittografia.

Nella stragrande maggioranza delle applicazioni pratiche è sufficiente considerare gli algoritmi crittografici come una black box. Si sa cosa fanno, ma non come lo fanno. Inoltre, cosa ben più importante, avere un algoritmo crittografico assolutamente perfetto e inattaccabile è spesso del tutto inutile. Cito me stesso:


L’effettivo ruolo della crittografia nelle applicazioni informatiche, peraltro, è spesso frainteso. Si tende infatti a considerare il mero uso della crittografia come sinonimo di “garanzia assoluta di sicurezza”. Purtroppo questa conclusione è del tutto infondata ed in questo breve contributo cercheremo di spiegarne il motivo. In estrema sintesi, la sicurezza di un’applicazione informatica richiede la soluzione di numerosi problemi. La crittografia risolve alcuni di essi ma è del tutto inutile per altri. Nella pratica, gli attaccanti sfruttano proprio i numerosi problemi irrisolti.


Lo stesso concetto era stato spiegato, in modo infinitamente più autorevole di me, dallo stesso Ross Anderson già nel 1993:

("Why cryptosystems fail", si trova via Google Scholar http://meslab.snu.ac.kr/courses/2007f/dip/papers/12-Anderson94.pdf)

dato il mio interesse per la sicurezza informatica volevo chiederle se poteva consigliarmi del materiale su cui approfondire.uno in particolare, di riferimento sul quale iniziare a studiare (o approfondire) questi aspetti. 

In questo caso è difficile rispondere, perchè la "sicurezza informatica" è un settore vastissimo e che si può studiare a molti livelli di astrazione ed approfondimento diversi. Si va dagli aspetti molto specifici per i quali sono necessarie competenze tecniche molto approfondite (come si penetra in un sistema operativo; come si attacca un sito web o una applicazione specifica; come si cercano le vulnerabilità in una applicazione o in una installazione fisica). Ci sono poi tutti i numerosi protocolli e tecnologie per la difesa (SSL/HTTPS che si fa alla fine di Reti I; varie tecnologie che si fanno a Reti II come Kerberos, VPN, OAuth etc; molte altre tecnologie che ho insegnato in corsi vari ma mai a Reti, come DNSSEC; molte altre tecnologie che personalmente conosco solo di nome).

Personalmente penso che un tema molto affascinante sia quello della nascente economia del crimine informatico. Tema che meriterebbe di essere conosciuto da tutti. Potete dare un'occhiata qui:

Nei mesi scorsi ho tenuto un corso di Sicurezza Informatica in Area di Ricerca. Nelle prime lezioni ho cercato di convincere i partecipanti che ormai gli attacchi informatici sono un vero e proprio business e quindi non devono essere considerati come una attività ludica-o-quasi. A tale scopo ho esposto i risultati di alcuni studi recenti molto interessanti sulla "underground economy" del settore....Ho inserito anche alcune slide (leggermente più tecniche) sul malware in generale. Consiglio caldamente un'occhiata all'argomento "Botnet: Torpig case study", a partire dalla numero 44. Mostra che questa botnet sostituisce tutti i programmi dei computer infettati, compresi i  browser...

lunedì 13 maggio 2013

Concretezza

Io stimo più il trovar un vero, benché di cosa leggiera, che 'l disputar lungamente delle massime questioni senza conseguir verità nissuna.

Galileo Galilei

(altre "WordsOfWisdom": http://reti-inginf-units.blogspot.it/search/label/WordsOfWisdom)

giovedì 9 maggio 2013

L'attacco più bello degli ultimi anni

Questo è uno degli attacchi più belli e più istruttivi degli ultimi anni:


Stealthy, malware-spewing server attack not limited to Apache


someone is replacing legitimate web server software with binaries containing the Cdorked backdoor, but exactly how they're doing it remains a mystery.

In parole poverissime, il codice sorgente di alcuni tra i web server più diffusi è stato modificato in modo fraudolento; adesso contiene del codice che:

  1. effettua, in modo nascosto, redirection verso siti che tentano di iniettare malware;
  2. è controllabile, in modo nascosto, da remoto;

Questo attacco è "bello" perché nessuno ha ancora capito come faccia l'attaccante a modificare il codice del web server, e perché il funzionamento del codice fraudolento incorpora numerose tecniche per renderne complicata la rilevazione. Sono elencate nell'articolo: solo alcuni utenti subiscono la redirection, secondo un pattern "inexplicable"; un utente che è stato rediretto può non essere rediretto nuovamente; etc

E' anche un attacco molto "istruttivo" perché dimostra in modo lampante il problema più radicale e più evidente di tutti i marchingegni informatici. Problema di cui però, purtroppo, pochi hanno coscienza, nonostante sia un problema molto semplice da capire---non occorre avere grandi competenze tecniche.

Il problema è che ogni calcolatore può eseguire azioni fraudolente in modo completamente nascosto al suo proprietario. Può farlo attraverso software di cui il proprietario non sospetta neanche la presenza, oppure attraverso software che dovrebbe fare una cosa e invece ne fa un'altra. Ergo, ogni calcolatore può essere un nemico.

Ciò non è una "possibilità teorica", ma un fenomeno concreto e diffuso. Sia sul lato client (vedi ad esempio questo post) sia, come si vede in questo caso, sul lato server.

Le implicazioni di questi dati di fatto sono enormi.

lunedì 6 maggio 2013

Posso crittare i dati nel cloud ?

Questo è complicato da leggere ma ne vale la pena (per aggiornarsi).
IBM takes a big new step in cryptography: practical homomorphic encryption
In breve, i servizi di cloud storage (come Dropbox, Box, Google Drive, Microsoft Skydrive etc etc etc) memorizzano i dati degli utenti "in chiaro", cioè senza crittarli. Ciò è un problema enorme per molte categorie di utenti ed organizzazioni. Dati potenzialmente sensibili, o comunque rilevanti per l'organizzazione, diventano accessibili al provider del servizio e soprattutto possono diventare accessibili se un attaccante riesce a "bucare" il servizio. In altre parole, la difesa principale nei confronti del furto dei dati (crittare i dati) non può essere applicata nei servizi di cloud.

In linea di principio l'utente potrebbe crittare i propri file con una chiave nota solo a lui, e poi potrebbe memorizzare sul cloud i dati crittati. In questo modo però il servizio di cloud non potrebbe effettuare nessuna operazione. Neanche una semplice ricerca testuale---sul cloud ci sarebbero infatti dati crittati. Ogni operazione dovrebbe essere fatta sulla macchina dell'utente, sui dati decrittati.

Le limitazioni di questo approccio sarebbero enormi. Senza contare il fatto che, in pratica, crittare il contenuto dei file sarebbe addirittura troppo poco, in quanto un eventuale attaccante avrebbe visibile la struttura in directory, nome dei file etc---informazioni che in molti casi possono essere sufficienti per lo scopo dell'attacco. Sarebbe cioè necessario crittare completamente il filesystem, nascondendo all'attaccante anche la struttura in directory. In tal caso però il servizio di cloud non potrebbe neanche elencare il contenuto di una directory---non saprebbe neanche quali e quante directory o file esistono.

La cosiddetta "homomorphic encryption" è uno strumento che permette di rivoluzionare il tutto e risolvere proprio problemi di questo genere. Con questa tecnica crittografica, il servizio di cloud storage può fare ricerche sui dati crittati ed ottenere i risultati corretti (!)---sto ultrasemplificando e scrivendo cose inesatte, solo per descrivere l'idea. Io ho i dati, il servizio di cloud storage ha i dati crittati (che non sa come decrittare) ma può eseguirci sopra operazioni per me utili.

La cosa ovviamente è enormemente complicata---visto che il servizio di cloud storage può usare utilmente i dati crittati, come fare in modo che non possa farlo anche un attaccante ? quali utilizzi sono praticamente possibili ?

L'articolo citato descrive in modo sommario la faccenda e lo stato attuale dell'arte, così come implementato in un software open source rilasciato da IBM.

giovedì 2 maggio 2013

What is the real difficulty in hacking Internet banks ?

La notizia riportata qui sotto descrive in modo interessante un dato di fatto ben noto:

  1. Il vero problema non è prendere il controllo di un conto corrente;
  2. il problema è riuscire a spostare i soldi senza generare trasferimenti anomali.

Da un altro punto di vista:

  1. il vero problema non è superare le difese tecnologiche dell'Internet Banking;
  2. il problema è superare i controlli tradizionali, effettuati in background e a posteriori.

Il che dice molto sulla vera natura delle tecnologie moderne per la sicurezza informatica.
  • Organized hackers in Ukraine and Russia stole more than $1 million from a public hospital in Washington state earlier this month.
  • roughly $133,000 of the lost funds have been recovered so far,....
  • ...the attack occurred on Apr. 19, and moved an estimated $1.03 million out of the hospital’s payroll account into 96 different bank accounts,... 
  • ..."Take the $9,180 just deposited into his account and send nearly equal parts via Western Union and Moneygram to four individuals, two who were located in Russia and the other pair in Ukraine. After the wire fees — which were to come out of his commission — Contreras said he had about $100 left over."...
http://krebsonsecurity.com/2013/04/wash-hospital-hit-by-1-03-million-cyberheist/

venerdì 26 aprile 2013

Non sono più...

Da oggi non sono più il presidente del corso di studi in Ingegneria Informatica.

Ho ricoperto questo ruolo ininterrottamente dal 2001, solo per spirito di servizio (= ne avrei fatto molto, ma molto volentieri a meno).

Adesso sono stato obbligato alle dimissioni. Una delle infinite norme ministeriali sull'ordinamento universitario impone a chi ha ricoperto questo ruolo per due mandati (sei anni complessivi) di essere "squalificato a vita". Questa norma era sempre stata interpretata in modo molto soft---eufemismo per dire "all'italiana"---ma adesso è diventata cogente per tutta una serie di motivi che è inutile riassumere.

Il nuovo coordinatore è Eric Medvet. Eric è una persona che non solo ha grandi capacità ma è anche piena di entusiasmo. Spero che le immersioni nei moduli, norme, leggi, decreti, tabelle, convalide, transitori, piani di studio, etc etc etc non gli tolgano questo entusiasmo.

Per gli studenti questo cambio di coordinatore non avrà alcun effetto pratico.

Ho riflettuto se fare una sorta di "bilancio pubblico" di questa mia esperienza di servizio. Ho concluso che è meglio di no.


martedì 9 aprile 2013

Com'è fatta una pagina web "vera" ?

La visualizzazione di ogni singola "pagina web" non è il risultato del prelievo di un documento HTML ed una manciata di file JPG.

E' il risultato del prelievo di molti documenti da più server, e dell'elaborazione nel browser di molti programmi Javascript prelevati da più server. In un post di un pò di tempo fa ho anche riportato statistiche molto interessanti calcolate da Google: in media, la visualizzazione di una pagina richiede il prelievo di più di 40 documenti da 7 server diversi.

Ho trovato un servizio web molto interessante per evidenziare questo fenomeno. Si tratta di urlquery.net. E' stato sviluppato per fare analisi relative al malware diffuso via web, ma è molto interessante anche per capire com'è realizzata una pagina "vera".

Gli ho chiesto di analizzare www.gazzetta.it. Dopo qualche decina di secondi ha fornito un report molto dettagliato, con alcuni aspetti di non facile interpretazione ma molto istruttivo:

  • Eseguiti 194 (centonovantaquattro) script.
  • Gli script hanno applicato 457 (quattrocentocinquantasette) modifiche al documento visualizzato dal browser.
  • Il browser ha eseguito 449 (quattrocentoquarantanove) scambi request-response HTTP.
Una "pagina web" reale è quindi qualcosa di molto, ma molto complicato.

Il report dovrebbe essere accessibile a questo link (altrimenti fatelo generare nuovamente); qui sotto una sorta di mappa dei documenti necessari.


martedì 2 aprile 2013

Il grande attacco di questi giorni (e inginf non accessibile)

Qualche giorno fa uno studente mi ha inviato un mail chiedendomi chiarimenti su una notizia comparsa su Wired.it: L'attacco a Spamhaus che sta rallentando Internet Un'offensiva senza precedenti che potrebbe mettere in ginocchio tutta la rete.

Nei giorni successivi tutti i siti della zona inginf.units.it sono diventati irraggiungibili (problema risolto pochi minuti fa).

Il secondo fenomeno è stato una conseguenza del primo. Cerco di spiegare brevemente la faccenda in questo post. Se qualcuno avesse dubbi o curiosità mi chieda a lezione.

Premessa: l'articolo su Wired.it secondo me è incomprensibile dal punto di vista tecnico. Non si capisce minimamente cosa sia successo.

Per capire cosa sia successo, consiglio questo articolo:
Massive DDoS attack against anti-spam provider impacts millions of internet users

In brevissimo:
Una organizzazione A ha deciso di lanciare un attacco "Distributed Denial of Service" nei confronti di una organizzazione B. Denial of Service significa che A ha iniziato ad inondare B di un flusso di dati enorme, talmente grande da saturare le risorse di calcolo e/o di comunicazione di B. In pratica, B non fa altro che ricevere e scartare messaggi generati (indirettamente) da A. Distributed significa che l'attacco è stato generato da un insieme di calcolatori sparsi in giro per il mondo (e probabilmente partecipanti all'attacco all'insaputa dei rispettivi proprietari).

L'attacco si basa, in estrema sintesi, su due tecniche:

  1. Si invia una query DNS su UDP falsificando l'indirizzo mittente; l'indirizzo mittente (falso) è quello di uno dei nodi che si vogliono colpire (falsificare l'indirizzo mittente in UDP è banale; farlo in TCP, come abbiamo detto a lezione, è molto più difficile). L'attaccante cioè invia la query ed il nodo che si vuole colpire riceve la response, ad una query che non ha mai fatto. La dimensione di una DNS response è più grande della dimensione di una DNS query, diciamo di un fattore a (con a circa 10). In questo modo, un attaccante in grado di generare un flusso di K bit/sec ha un meccanismo di amplificazione automatico per generare a * K bit/sec.
  2. L'attaccante deve avere a disposizione una botnet, cioè migliaia o decine di migliaia di computer in grado di eseguire comandi scelti da lui. Normalmente all'insaputa del proprietario del computer. In pratica, ogni computer infettato da un "malware" rimane in attesa di comandi inviati dal creatore, o dal proprietario, del malware ed esegue quei comandi. Ad esempio, l'invio di query DNS come quelle indicate al punto precedente.
In altre parole, con il punto 2 si ottiene K molto grande. Con il punto 1 si moltiplica K per un fattore a. Se il prodotto a * K è sufficientemente grande allora il gioco è fatto.

Ovviamente le query DNS non possono essere inviate tutte allo stesso name server, altrimenti sarebbe saturato quel name server invece del bersaglio dell'attacco. Per questo motivo è necessario distribuire le query su un insieme di server DNS. A tale scopo è sufficiente identificare dei server DNS che accettano di effettuare risoluzione ricorsiva per qualsiasi client---i cosiddetti open resolvers.

Osservazione sul punto 1 e sugli open resolver: la faccenda è spiegata molto bene e molto brevemente in questo documento dello US-CERT:  DNS Amplification Attacks. Il documento spiega anche come configurare un name server affinché non funzioni da open resolver.

Osservazione sul punto 2. Le botnet si possono comprare, ad un prezzo dell'ordine dei pochi centesimi di euro per nodo.  Con poche decine di euro si acquistano cioè centinaia di calcolatori sui quali è stato installato un software a scelta, tipicamente controllabile da remoto e tipicamente all'insaputa del proprietario. Ovviamente in un mercato che non è legale.Informalmente si dice che un nodo "ha un virus". In realtà il nodo ha un malware (cioè sul nodo è installato un programma maligno); molti malware sono programmati per tentare di diffondersi il più possibile; il termine virus si riferisce a questa funzionalità dei malware. Quello delle botnet è un tema molto affascinante e molto complicato...ogni botnet ha il proprio protocollo C&C (command and control) che permette all'attaccante di inviare i comandi alle botnet senza essere localizzato; comandi autenticati, in modo che ogni bot esegua solo i comandi inviati dal proprio proprietario; comandi che non possono essere falsificati neanche quando i "buoni" entrano in possesso di un nodo della bot e possono analizzare sia il suo funzionamento sia il traffico con il rispettivo proprietario...

Anche se l'attacco di questi giorni era da una organizzazione A verso una organizzazione B, l'impatto è stato molto diffuso in quanto la dimensione dell'attacco è stata talmente elevata da causare sovraccarichi su molti "canali di comunicazione comuni", anche ad organizzazioni che non hanno nulla a che fare con A o con B.

Venerdi scorso molti enti di ricerca, tra i quali il nostro ateneo, hanno ricevuto una direttiva da parte del GARR (l'organizzazione che coordina gli accessi Internet degli enti di ricerca italiani) in cui imponevano di eliminare l'utilizzo degli open resolver, per contribuire a disinnescare l'attacco (da notare che si stima ci siano venti milioni di open resolver in giro per il mondo...). Il nostro ateneo ha quindi bloccato tutto il traffico in ingresso sulla porta 53 (e spero sia chiaro il motivo) a meno del traffico diretto verso le zone "sotto" units.it gestite da name server interni alla rete di ateneo.

Per un errore organizzativo, si erano dimenticati di permettere il traffico in ingresso verso la porta 53 del name server della nostra zona inginf.units.it, server che non è un open resolver....

martedì 26 marzo 2013

Clickare su un link

Nelle lezioni di Reti di Calcolatori ho insistito molto, per la prima volta, sul fatto che clickare su di un link può essere sufficiente per prendere un virus. Da ciò discende, tra le altre cose, che prima di clickare su link contenuti in email ricevuti è bene pensarci molto, ma molto, ma molto bene. E se possibile è meglio evitare di farlo.

Non avevo mai insistito su questo punto perché mi sembrava ovvio, ma ho cominciato a pensare che sia meglio dirlo esplicitamente.

Ne abbiamo parlato pochi giorni fa. Proprio oggi la Polizia Slovena ha arrestato 5 persone coinvolte in una truffa basata proprio su meccanismi di questo genere e che ha coinvolto trasferimento di denaro su conti bancari per circa due milioni di euro (forse questa tempistica vi sembra sospetta...comunque no, non sono coinvolto...).

Alcune frasi di questa notizia riportano esattamente quanto ho detto: ...shows how damaging clicking on links that appear in spoofed messages can be...When in doubt, don't click. Educate your ...friends and family about avoiding suspicious emails and links - even if they appear genuine. Tell them they should try to use a trusted external method of verification when possible.

Avevo detto però anche una cosa imprecisa.

Avevo detto che un indicatore sulla genuinità di un link è la corrispondenza tra "ciò che si vede" ed il "link effettivo", cioè il documento che sarà effettivamente prelevato dal browser in caso di click. Se ciò che si vede è un link dall'aspetto innocuo, ad esempio la home page di una istituzione o grande azienda, ed il link effettivo coincide con ciò che si vede, allora si può ragionevolmente sperare che clickando sul link non si inneschi il prelievo di un documento maligno.

Per vedere il link effettivo di solito basta spostare il mouse sul link, senza clickare; il browser mostra, di solito in basso a sinistra, l'URL del documento che sarà prelevato clickando. In questo modo si riesce ad avere una qualche indicazione prima di prelevare il documento. Ovviamente l'indicatore è molto grossolano: spesso ciò che si vede ed il link effettivo non coincidono anche quando il link è "benigno".

Non avevo però pensato ad una cosa molto interessante, cioè che il link effettivo potrebbe cambiare proprio dopo il click ! In altre parole:

  1. vedo l'URL A;
  2. sposto il mouse sopra il link, senza clickare;
  3. il browser indica come link effettivo A;
  4. sono tranquillo, quindi faccio click...grazie a del codice Javascript il link diventa B ed il browser preleva B invece di A !!!

Questo documento spiega questa ed altre faccende in modo molto semplice.

Da ciò si potrebbero trarre molte conseguenze, difficili da sintetizzare. Una di queste è molto semplice: tutto ciò che si vede sullo schermo deve essere trattato con sospetto.

Se uno entra in questo ordine di idee, allora si rende conto di cosa sia veramente il web, Internet, etc.


venerdì 22 febbraio 2013

Research and its Objectives

Research often pays off in unanticipated ways – we can’t predict what the biggest impact will be.
Ed Lazowska

PS Ogni tanto a lezione accenno al fatto che i mezzi di informazione descrivono la ricerca in modo completamente fuorviante. Uno dei motivi è proprio questo evidenziato da Lazowska. Un altro è evidenziato dallo stesso Lazowska al link indicato, subito prima di questa frase. Gli esempi nella storia dell'informatica sono moltissimi.

venerdì 8 febbraio 2013

Perché Internet Banking si e Internet Voting no ?

"Internet voting is harder than almost any other kind of activity on the internet including banking – and the only reason we can do banking and other activity online is because of cross-checks and the willingness to accept a level of fraud that’s not possible with voting"

Jeremy Epstein

mercoledì 30 gennaio 2013

L'evoluzione (parziale) di HTTP

Il funzionamento del Web dietro le quinte---a livello HTTP---è cambiato molto negli ultimi anni. Una delle componenti più importanti di questo cambiamento è il protocollo SPDY ("speedy").

L'articolo indicato più sotto descrive molto, molto bene la faccenda. E' molto tecnico, ma è scritto in modo chiaro e (abbastanza) facile da seguire.

Consiglio caldissimamente la lettura a chiunque abbia interesse a capire il funzionamento e l'evoluzione di Internet a livello HTTP-e-simili.

In particolare l'ultima sezione, Future SPDY Gateways, contiene considerazioni molto interessanti sulle forze in gioco, anche a livello economico e di incentivi, e sulle ulteriori (radicali) evoluzioni possibili.
  • an experimental low-latency application-layer protocol designed by Google and introduced in 2009 as a drop-in replacement for HTTP on clients and servers.
  • SPDY retains the semantics of HTTP, allowing content to remain unchanged on servers while adding request multiplexing and prioritization, header compression, and server push of resources.
  • By September 2010, SPDY had been implemented in the stable version of the Google Chrome browser.
  • By February 2011, Google quietly flipped the server-side switch on SPDY, using the protocol to serve major services (such as Gmail, Maps, and search) to Chrome and other SPDY-enabled clients.
  • In February 2011, the Android Honeycomb mobile Web browser received client-side SPDY support, also with little publicity.
  • In September 2011, Amazon announced its Kindle Fire tablet, along with the Silk Web browser that speaks SPDY to Amazon cloud servers.
  • In January 2012, ...development of an open-source Apple iOS SPDY client library.
  • By June 2012, was enabled by default in Firefox 13, bringing combined client-side support (Chrome + Firefox) to approximately 50% of the desktop browser market

SPDYing Up the Web