venerdì 14 dicembre 2012

Ancora sui 36 milioni di euro...


...sottratti dal "bellissimo" malware che opera sui PC ed intercetta i codici di autorizzazione alla transazione inviati via SMS: mi chiedo spesso come facciano i nostri telegiornali a non parlare di queste faccende.

  • 16 delle banche coinvolte sono italiane (40% del totale)
  • 12000 utenti ai quali è stato sottratto del denaro sono italiani (39% del totale)
  • 16.380.000 (sedici milioni e trecentoottantamila) euro che si sono volatilizzati sono di italiani (45% del totale)


Siamo primi in tutte le tre classifiche. Germania al secondo posto e Spagna al terzo posto.

Fonte: "A Case Study of Eurograbber: How 36 Million Euros was Stolen via Malware" (spiega molto bene ed in modo molto semplice il funzionamento di questo malware).

giovedì 6 dicembre 2012

Trentasei milioni di euro, trentamila utenti, trenta banche (poi dite che sono "fissato"...)

Dal Corriere della Sera, che riporta una notizia del Financial Times:

Oltre 36 milioni di euro, sui conti di 30 banche europee. Una cifra da capogiro. Rubata da un gruppo di hacker anche di clienti italiani...questa frode ha sfruttato un ... virus che rimaneva inizialmente dormiente sui PC degli utenti, e da lì si trasferiva sui loro smartphone....avendo infettato entrambi i terminali, poteva registrare i codici di verifica che venivano inviati sui cellulari e utilizzarli per creare una sessione di online banking in parallelo. Con quest'ultima venivano effettuati trasferimenti su altri conti.

Neanche due settimane fa ho fatto un post su queste cose (no, io non c'entro con questa truffa...).

mercoledì 5 dicembre 2012

Come creare malware senza sforzo

Basta procurarsi un kit di sviluppo. SophosLabs ha appena pubblicato una descrizione molto carina di un kit di questo genere.



Si tratta di Citadel: "It comes as a kit that includes a malware builder tool and a collection of server-side components" (servono per controllare i malware distribuiti in giro per il mondo e per raccoglierne i risultati)"The builder is used to create the bot malware (an EXE file) that is sent out to spread infection".

Ha anche un "built-in Customer Relationship Management (CRM) system so that problems are addressed quickly and effectively.". Gli sviluppatori del kit sono molto attivi: "Citadel has been through several significant releases, most recently an upgrade to version 1.3.5.1 in October 2012.".

Occorre abbandonare la visione degli attacchi informatici come attività ludica ed estemporanea. Sono una vera e propria professione: per i pochi che sviluppano kit di questo genere, ma soprattutto per i molti che li usano.

Ciò ha numerose implicazioni, tra le quali il fatto che molti utenti usano i computer come attività ludica ed estemporanea, ma possono essere attaccati da chi, per professione, cerca di impossessarsi del loro computer e possibilmente di spillare loro dei soldi. (vedi anche altri post di questo blog con tag Security).

No, non mi chiedete quanto costano questi kit e dove si possono acquistare...




venerdì 30 novembre 2012

Furto di "un" numero di carta di credito

Una delle cose che dico da anni, temo da almeno una decina, ahimé, è che preoccuparsi della riservatezza del numero della nostra carta di credito mentre è in transito su Internet ha poco senso.

Non perché non sia facile vederlo, ma perché nessun attaccante perderebbe il proprio tempo attendendo di vedere passare un numero di carta di credito quando basta penetrare un server scelto opportunamente per acchiapparne centinaia o migliaia.

Proprio in questi giorni hanno scoperto un gruppo di hacker che dalla Romania hanno preso circa mezzo milione di numeri di carta di credito australiane, prelevando in media 1000 $ da trentamila di esse. Ovviamente non si sono messi in attesa di vedere passare i numeri giusti, ma sono entrati in una manciata di "piccoli rivenditori" (che avevano abilitato il Remote Desktop Protocol di Windows ma non lo avevano configurato opportunamente; probabilmente non sapevano neanche di averlo abilitato).

http://nakedsecurity.sophos.com/2012/11/30/romanian-hackers-busted-with-half-a-million-cards-from-oz/

mercoledì 21 novembre 2012

What is "research" ?

http://gcn.com/Articles/2007/06/02/Rick-Rashid--Innovation-pipeline.aspx?Page=2&p=1



A lot of times, when people talk about applied research, they're really talking about advanced product development. That's not really research. Research is something you can publish in a peer-reviewed conference or journal. It needs to stand up to the best people in your field.

Rick Rashid, Director of Microsoft Research


Malware per fare transazioni bancarie

Talvolta mi capita di affermare che i moderni malware sono in grado di:
  1. Installarsi nel browser e rimanere nascosti.
  2. Quando l'utente si collega con un sito per il quale il malware è stato preparato (tipicamente un sito di e-banking):
    • Attendere che l'utente si autentichi, eventualmente anche con un marchingegno one-time password, smartcard o cose del genere.
    • Eseguire transazioni non richieste dall'utente, inviando autonomamente messaggi HTTP al sito (ad esempio bonifici verso un conto corrente predefinito di un money launder).
    • Nascondere queste transazioni dagli estratti conto visualizzati dal browser.
Esistono numerosi casi emersi alla cronaca di recente (https://www.evernote.com/pub/bartolialberto/news e poi cercare nella search box 'tag:banking tag:malware').

Quello che probabilmente non è chiaro è quanto sia semplice realizzare il punto 2.

Un articolo del 2007 scritto da dei ricercatori di Stanford (nota: cinque anni fa) mostra esempi di codice per il browser Firefox ("We have tested this code on several major retailer web sites").

La parte di codice per eseguire transazioni non richieste dall'utente è più o meno questa:

Quella per nascondere le transazioni fraudolente da ciò che viene visualizzato dal browser è questa:

Tutto sommato è banale...

(aggiornamento successivo)

Giusto per illustrare i diversi casi, IWBank richiede il codice del token sia per l'accesso che per ogni operazione, certamente questo non mette al riparo da questo tipo di attacchi.. come direbbe lei, alza solo l'asticella.

Non è difficile immaginare un malware che gestisca anche questa situazione (sarebbe solo un pelino più complesso e mirato alla singola banca).


Esatto.

C'è un'altra cosa fondamentale da notare: il fatto che il browser è un potenziale nemico. L'esistenza di dispositivi tipo il generatore di token di IWBank lo dimostra. E' obbligatorio:

  1. avere un dispositivo sicuro (cioè che faccia veramente ciò che ci si aspetta),
  2. collegato in modo sicuro alla volontà dell'utente,

proprio perché il browser in esecuzione sul PC non risponde a questi requisiti. Ormai anche il browser fa parte del territorio di cui non ci si fida.

Fino a qualche anno fa, quando iniziò a diffondersi SSL, la crittografia, i certificati etc, il territorio nemico da cui difendersi era Internet ed il PC era ancora in territorio amico. Oggi non è più così, anche il PC ed il browser fanno parte del territorio nemico. Più precisamente, anche prima facevano parte del territorio nemico, ma lo dicevano solo i paranoici come me. Gli altri (banche etc) dicevano che erano territorio amico. Oggi quella posizione non è più sostenibile.

lunedì 19 novembre 2012

What can the attacker do ?

Tutte le volte che parlo di sicurezza dico sempre che il punto di partenza fondamentale è chiedersi cosa può fare l'attaccante e da quali tipologie di attacco ci si vuole difendere (o si ritiene che valga la pena difendersi, o ci si possa permettere di difendersi).

Questa stessa considerazione è stata fatta da una persona di altissimo livello nell'analizzare il recentissimo scoop della love (o sex) story tra il capo della CIA ed una sua amante:

"Understanding the threat is always the most difficult part of security technology,” said Matthew Blaze, an associate professor of computer and information science at the University of Pennsylvania and a security and cryptography specialist. “If they believed the threat to be a government with the ability to get their login records from a service provider, not just their spouse, they might have acted differently.” (link)

Studiare il flow control di TCP (qualche volta) può servire...

Un ex studente mi ha inviato un mail che mi ha fatto molto piacere. Ha risolto un grosso problema pratico grazie al fatto di avere studiato TCP...ci è riuscito anche perché lui è molto in gamba, ma se non avesse saputo come funziona TCP il problema sarebbe stato completamente oscuro...

Buondi' Alberto!

Non ho mai avuto il tempo di raccontarti un aneddoto del lavoro, accaduto ormai diversi anni fa, dove quanto studiato nel corso "reti di calcolatori" e' stato fondamentale per risolvere un problema.

Oggi ti racconto solo il caso, senza la soluzione...

Il nostro collegamento internet e', ovviamente, una linea dedicata ad alta velocita' che arriva fino a noi, una serie di routers (alcuni del provider, altri nostri), una serie di passaggi tra firewalls, antivirus, proxy... 
Insomma, la piu' tipica delle configurazioni per un uso "professionale".

Un bel giorno decidono di sostituire il proxy con una macchina piu' nuova. La macchina vecchia era un linux RedHat 4 credo, la nuova una versione piu' recente sempre RedHat Linux, non ricordo se 5 o 6.

Configurato tutto si comincia  a testare questo nuovo proxy, ma ci si accorge subito che la velocita' di download di questo nuovo proxy e' sempre piu' bassa del vecchio. A volte di poco, a volte notevolmente piu' bassa.
per dare un'idea, nello scaricamento di un file pesante, tipo un iso, se il vecchio teneva una media di 5MB/s, il nuovo andava a 2 o anche meno. In alcuni casi la velocita' era "ridicola".
Il software di proxy non ricordo se era squid o altro, ma non era questo a fare la differenza. Anche scaricando  sulla macchina stessa, senza usare il software di proxy, ma per capirci, facendo un wget "qualcosa" diretto, le velocita' erano queste sopra dette.

Fatte tutte le verifiche sullo switch, su firewall... nessuna differenza per le due macchine. Entrambe sulla stessa lan, con le stesse impostazioni. Entrambe in gigabit full duplex. 
Provato anche a sostituire fisicamente le due macchine, quindi provato la nuova con l'IP della vecchia (per evitare che ci fossero regole sul firewall magari disperse nella configurazione...), stesso cavo di rete...

Configurazione di linux come da "fabbrica", nessuna operazione particolare fatta se non quanto strettamente necessario alla configurazione del proxy, ma niente da fare. La nuova era sempre sensibilmente piu' lenta....

Io non ero piu' nel gruppo reti, e nemmeno nel "gruppo dei proxy", ma mi sono trovato per caso in un ufficio di colleghi mentre discutevano di questo problema.
Ho riflettuto un poco e mi e' venuta un'idea....

La mia risposta è stata:

a questo punto è PROIBITO NON DIRMI LA SOLUZIONE !!!! -:)

dimmela quando vuoi, ma dimmela... (rcvbufsize ?)

Il problema era effettivamente legato ai parametri del flow control in TCP (come avevo immaginato) ma la faccenda era davvero intricata.

allora... quello che mi ha fatto scattare l'intuizione era una frase del Tanenbaum che diceva che banda, latenza e la "tcp windows size" sono intimamente legate.. 
cioè anche avendo  a disposizione una notevole banda, ma con una latenza non trascurabile, se non si imposta un'opportuna "tcp windows size" il risultato sara' comunque scadente.
La banda attuale e' cresciuta di molti ordini di grandezza rispetto quelle del tempo... la latenza sara' anche migliorata ma non piu' di tanto non si puo' fare.... a 0 non andra' mai... 
quindi di conseguenza la "window" dovrebbe essere generosamente aumentata.
E ho subito pensato a questa benedetta window. Ho sniffato un po' di traffico ed effettivamente i valori che vedevo nell'header del nuovo server erano molto bassi.
Non ricordo esattamente, ma era veramente un valore molto molto basso! 

Mentre nel vecchio avevo valori molto piu' alti.

Sintetizzo la parte rimanente:
  1. Il field window size dello header TCP è lungo 16 bit, quindi permette di gestire buffer di ricezione di dimensione massima 64 KB. Questa dimensione può essere eccessivamente piccola, ad esempio nelle network ad alto bandwidth-latency product, pertanto esiste una opzione di TCP che permette di definire window size molto più grandi: (RFC 1323): The window scale extension expands the definition of the TCP window to 32 bits and then uses a scale factor to carry this 32-bit value in the 16-bit Window field of the TCP header. The scale factor is carried in a new TCP option, Window Scale. 
  2. Alcuni router hanno un bug software a causa del quale i bit che definiscono la window scale sono scartati (!). Loro avevano proprio un router di questi. Pertanto il loro proxy inviava una window size ed il partner percepiva una window size completamente diversa. Il problema non finiva qui, infatti:
  3. Il vecchio proxy impostava un fattore di scala diverso da quello del nuovo proxy; e, colmo della sfortuna, la window size percepita con il vecchio proxy era intorno ai 32 KB (non bellissima ma accettabile) mentre quella percepita con il nuovo era 1 KB (!).
Ovvio che con il nuovo proxy la velocità di trasferimento imposta dal flow control fosse inaccettabilmente bassa...invio 1 KB e attendo riscontro; invio 1 KB e attendo riscontro...

Notare che il bug al punto 2 è davvero sorprendente....

mercoledì 7 novembre 2012

How to defend against a determined attacker ?

In un post precedente mi riferivo a recenti ricerche che spiegano come mai gli attacchi informatici sono, sostanzialmente, così pochi, nonostante le vulnerabilità software siano tantissime, gli utenti non sappiano nulla di sicurezza etc etc.

Le slide di cui parlo in quel post terminano con un dato di fatto fondamentale:


Cioè, mettiamoci l'animo in pace, se qualcuno ha motivazioni e risorse sufficienti allora, in pratica, non c'è nulla da fare.

Questa notizia recente su una intrusione alla Coca Cola ne è una dimostrazione.

OpenID, OAuth, SAML, Federations...

Ho aggiornato radicalmente le slide sugli ultimi argomenti del corso di Reti di Calcolatori II. I contenuti sono gli stessi, ma penso che siano enormemente più chiari della versione precedente.

Se qualcuno fosse interessato ad averle mi invii un mail...

lunedì 22 ottobre 2012

Why Google is Google

In una delle ultime lezioni di Reti di Calcolatori II ho accennato ad uno dei miei temi preferiti (sui quali però non ho voglia di dilungarmi; ormai il pessimismo ha preso il sopravvento): i prodotti della ricerca sono le persone. Non sono algoritmi, idee, prototipi, etc. Sono le persone.

Ho fatto l'esempio di Kerberos, per il quali sono occorsi più di dieci anni per passare dalla pubblicazione del protocollo al suo utilizzo su larga scala. Ho poi accennato al fatto che Google non è Google solo perché Page&Brin hanno avuto un'idea brillante e ne hanno mostrato la fattibilità pratica; lo è perché loro si sono trovati in un ambiente con centinaia di persone in grado di padroneggiare lo stato dell'arte della tecnologia e della ricerca.

La lettura di questo bellissimo articolo pubblicato su Wired farà capire meglio cosa intendo.

mercoledì 17 ottobre 2012

Why isn't everyone hacked every day ?

Alcuni ricercatori Microsoft Research hanno pubblicato lo scorso anno una bellissima ricerca che spiega in modo efficace e convincente un fenomeno molto semplice e misterioso:

  • Le vulnerabilità software sono tantissime ed aumentano di continuo, gli utenti scelgono password pessime, non aggiornano i propri software, non usano antivirus etc etc etc.
  • Allora perché mai le vittime di attacchi informatici sono così poche ? Com'è possibile ?
Loro forniscono una spiegazione basata su un modello di carattere economico. Modello che ha delle implicazioni molto importanti e per vari aspetti sorprendenti. Ad esempio, non è vero che l'attaccante deve superare l'anello più debole delle difese: deve superare la somma di tutte le difese esistenti (il che è, appunto, sorprendente; è come dire che quando un ladro entra in un condominio con 12 appartamenti, ognuno con porta blindata, deve superare tutte le porte invece che solo una). Altro esempio: quando un numero elevato di bersagli si difende in modo adeguato il beneficio è di tutti i bersagli, anche di quelli che non si difendono. Pertanto un bersaglio può anche decidere di non difendersi, tanto si difendono gli altri anche per lui. Tra l'altro, questo punto mi ha suggerito una analogia interessante con il pagamento delle tasse in Italia...

Ho preparato delle slide (circa 60) al fine di trattare questi argomenti a Reti II. Non sono leggere ma sono, a mio parere, di fondamentale importanza per comprendere la dinamica delle problematiche di sicurezza informatica odierne. In particolare, per comprendere le radicali differenze tra attacchi indiscriminati su larga scala ed attacchi mirati su un particolare bersaglio.

E' stata una faticaccia. La faccenda in apparenza è relativamente semplice, in realtà è complicata. Inoltre, ho inserito nelle slide l'analisi degli attacchi mirati (non presente nel lavoro citato) effettuata con lo stesso formalismo, terminologia ed impostazione degli attacchi indiscriminati su larga scala.

Ancora non mi è chiaro se, nonostante tutta questa fatica, ne parlerò a Reti II già quest'anno. Il programma è già pesante e non so se conviene tagliare qualcosa. Quest'anno deciderò sul momento, l'anno prossimo ne parlerò certamente, eventualmente tagliando altri argomenti.

Se qualcuno fosse interessato a vedere queste slide mi invii un mail.


venerdì 28 settembre 2012

Chiavi private e firma digitale: davvero private ?


Ci risiamo...
Adobe security chief Brad Arkin has warned that hackers have managed to create malicious files with Adobe's digital code-signing signature.
According to a blog post published on Thursday, the issue appears to have been the result of hackers compromising a vulnerable build server
Adobe plans next week to revoke the certificate for all code signed before July 10, 2012...
(più precisamente: butta via la propria chiave privata e chiave pubblica, poi chiede alla propria CA di revocare il certificato che associa Subject=Adobe a quella chiave pubblica)
However, even when a CA (Certificate Authority) revokes a certificate for an abused private key, any digital signature made before the revocation date will remain valid.

Ogni volta che parlo di queste cose non manco di evidenziare questi problemi. 
Vedi anche questo post.

mercoledì 26 settembre 2012

Contenuto nascosto nei siti web e altro...

Due parole su pubblicazioni recenti del nostro lab (non sia mai che a qualcuno venga la voglia di fare una tesi su questi temi). Faccio un pò di cut-and-paste, spero che sia chiaro ed interessante...

A Look at Hidden Web Pages in Italian Public Administrations
Preventing illegitimate modifications to web sites offering a public service is a fundamental requirement of any e-government initiative. Unfortunately, attacks to web sites resulting in the creation of fraudulent content by hackers are ubiquitous. In this work we attempted to assess the ability of Italian public administrations to be in full control of the respective web sites. We examined several thousands sites, including all local governments and universities, and found that approximately 1.16% of the analyzed sites serves contents that admittedly is not supposed to be there.
This result is not very encouraging and somewhat surprising. To place this result in perspective, we observe that a state-of-the-art system recently developed for efficiently searching malicious web pages, manages to construct a stream of URLs in which 1.34% of them identify malicious pages and this system improves earlier strategies by one order of magnitude (cioè: trovare schifezze nell'1.16% delle pagine che analizzo è davvero tanto...)
...
Careful exploitation of these attacks may create a very odd scenario: pages hosted on a trusted site that serve content fully controlled by attackers, tailored to the navigation path followed by users, visible only to certain users. An analogy with the physical world may illustrate the issue more clearly: when entering into the building of a public administration, one would not expect to find offices that are not supposed to exist and are visible only to certain citizens, perhaps depending on where they come from. Unfortunately, this is exactly what it could happen in web sites of public administrations.
...
It is important to point out that HTTPS—the main and ubiquituos line of defense in sensitive web sites—does not provide any defense in this respect: The problem is, the server site is authenticated as a whole—any page coming from that site appears as being legitimate.

Brand-related Events Detection, Classification and Summarization on Twitter
The huge and ever increasing amount of text generated by Twitter users everyday embeds a wealth of information, in particular, about themes that become suddenly relevant to many users as well as about the sentiment polarity that users tend to associate with these themes.
In this paper, we exploit both these opportunities and propose a method for: (i) detecting novel popular themes, i.e. events, (ii) summarizing these events by means of a concise yet meaningful representation, and (iii) assessing the prevalent sentiment polarity associated with each event, i.e., positive vs. negative.
Our method is fully automatic. We validate our proposal on a real corpus of about 8,000,000 tweets, by detecting, classifying and summarizing events related to three wide topics associated with tech-related brands: Apple, Google and Microsoft



martedì 25 settembre 2012

Valutazione della didattica

Anche quest'anno è andata bene.
La posta interna di ateneo, peraltro, sta diventando sempre meno affidabile. La busta con la valutazione del corso di Reti di Calcolatori mi dicono non sia mai arrivata all'ufficio del nucleo di valutazione...(no, non l'ho buttata via io; non avrei avuto nessun interesse a farlo).

mercoledì 5 settembre 2012

Quanto guadagnano gli hackers ?

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. Si trovano nella mia raccolta bibliografica online, associati ai tag crime oppure webmalware o cose del genere.

In una delle ultime lezioni del corso di Reti di Calcolatori ho detto che se qualcuno era interessato all'argomento gli avrei passato le slide corrispondenti. Uno studente me le ha chieste ed io, mea culpa, ho impiegato molte settimane per renderle pubbliche...so che avrei dovuto farlo prima perché adesso sono tutti sotto esami...sorry.

Le slide sono queste:



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...



venerdì 10 agosto 2012

Perché la ricerca è importante

Un blog post (moderatamente interessante) di Robert Graham (personaggio molto interessante) contiene due considerazioni molto interessanti e molto importanti:

Perché la ricerca è importante
A mio parere quasi tutto ciò che viene scritto e pensato sui giornali, leggi nazionali, regionali etc sul finanziamento alla ricerca è totalmente campato in aria.

Chi pensa che dando X ad un ente di ricerca riceverà entro un tempo Y (dell'ordine dei mesi) un prodotto o qualcosa del genere non ha capito nulla (secondo me).

La storia, almeno quella dell'informatica, dimostra che non è vero per nulla.

Ci sono tantissime dimostrazioni di questo fatto, a volte ne racconto qualcuna a lezione.

Dovrei fare un'analisi sistematica e diffonderla ma non ne ho voglia. E poi il mio pessimismo, o forse dovrei dire realismo, mi dice che tanto sarebbe tempo perso.

Divagazioni a parte, Robert Graham---uno che ha fatto tante cose di impatto nella tecnologia informatica--esprime questo concetto molto chiaramente: pretty much all early Internet code was developed with the same sort of model: lurching in unexpected directions rather than being based on a plan

Ovvero: facevano una cosa ed hanno prodotto tutt'altro, qualcosa di completamente inatteso ed imprevisto.

Per inciso: finanziare la ricerca è importante perché produce persone. Persone in grado di risolvere problemi  molto complicati; di capire se un problema ed una soluzione sono nuovi (a livello mondiale); di capire se sono pratiche ed interessanti; di convincere i maggiori esperti (a livello mondiali) della bontà del proprio approccio; di abituarsi a motivare ogni singola affermazione, etc etc etc

Google è Google non solo perché Brin e Page hanno avuto l'idea che hanno avuto. Lo è anche perché si sono trovati in un ambiente in cui c'erano migliaia di persone con le caratteristiche di cui sopra. Che per vari anni si sono occupati di problemi senza la minima applicazione pratica, ma che sono state in grado di mettere su l'infrastruttura di Google con tutto ciò che ne consegue (e chi sa come funziona Google e tutti i suoi servizi accessori intende cosa voglio dire).

UPDATE: manco a dirlo, cinque minuti dopo avere scritto questo post ho trovato un articolo che dimostra quanto ho detto nel paragrafo qui sopra...http://www.wired.com/wiredenterprise/2012/08/google-as-xerox-parc/all/

QUANTO SEGUE E' DIRETTO ALLA CIURMA DEL LABORATORIO !!!

Perché leggere gli articoli è importante

Conclude la storia della sua "invenzione" degli IDS con: I probably would have done a better job had I read more academic papers. For example, I "invented" my own multi-pattern matching system that, as it turns it, is just the Aho-Corasick algorithm. I would have saved a lot of time and effort had I just studied a bit better.

sabato 7 luglio 2012

Come fare soldi con Internet


Il capitale cresce di 16 (sedici) volte. Ovviamente il metodo è illegale.


Ho letto proprio oggi una ricerca molto interessante sugli aspetti tecnici ed economici della pornografia su Internet. Per inciso, qualche anno fa uno degli autori della ricerca ha ospitato nel proprio laboratorio per qualche mese il peggior calciatore del nostro laboratorio. La ricerca descrive, oltre a molte altre cose, una tecnica che permette di incassare circa 2600$ a fronte di un investimento di soli 160$.

In estrema sintesi il tutto funziona in questo modo.

  1. Si mette su un sito web, ad un URL U.
  2. Si contatta un traffic broker specializzato in pornografia. In pratica, si paga il broker per inviarci richieste HTTP. Il traffic broker è un sito web specializzato nell'attrarre traffico di utenti interessati alla pornografia. Pagando il broker ed indicandogli un nostro URL U, il broker garantisce di inviarci utenti all'url U da noi indicato. Quando un utente contatta il broker, quest'ultimo lo invia su U tramite una HTTP redirection. Non occorre che U abbia necessariamente contenuto pornografico, anche se i numeri citati qui sopra richiedono che lo abbia. 
  3. Si predispone il contenuto del nostro sito web in modo che verifichi la presenza di vulnerabilità nei browser degli utenti che arrivano, anche vulnerabilità molto banali. Basta includere un pò di Javascript opportuno nei contenuti inviati agli utenti.
  4. Si infetta ogni browser con un malware M. Questo deve semplicemente essere in grado di ricevere da noi comandi per scaricare ed installare localmente un programma di nostra scelta. Sembra complicato ma esistono numerosi software in grado di eseguire il tutto in modo automatico, l'unico requisito è che il browser abbia una vulnerabilità sfruttabile in modo semplice.

In parallelo all'attività appena descritta:

  1. Si contatta un Pay Per Install Service (PPI). Si tratta di un servizio web che ci paga per ogni calcolatore in cui abbiamo installato un programma S fornitoci dal PPI stesso. Tipicamente il programma S che ci viene fornito è un malware, ma dal punto di vista della transazione economica ciò è irrilevante sia per il PPI sia per noi. 
  2. Installiamo su ogni browser infettato il software S indicatoci dal PPI---basta inviare i comandi opportuni a tutti gli M controllati da noi. Poi ci facciamo pagare. Tutti i contatti tra noi e il PPI avvengono via web ed in forma del tutto anonima.

Bene, la ricerca citata all'inizio di questo blog afferma che:

  • Per una cifra di 160$ hanno acquistato da un traffic broker 50000 visitor.
  • Di questi 50000, più di 20000 avevano almeno una vulnerabilità facilmente sfruttabile.
  • Poiché le tariffe tipiche di un servizio di PPI sono di circa 130$ per 1000 installazioni, i conti sono presto fatti...


lunedì 4 giugno 2012

Revoca di certificati e update di sistema

L'update di Windows di stamani contiene una revoca di certificati ("update to the certificate revocation list").



Questo update è anche necessario al fine di "keep your systems certificate list up to date".

Questa frasetta in apparenza innocua ("vabbé, uno dei soliti aggiornamenti") nasconde in realtà qualcosa di molto delicato ed importante. L'update infatti serve a rimuovere dal TrustSet alcuni Issuer Microsoft (!).

Ripeto: serve a rimuovere dal TrustSet alcuni Issuer Microsoft. Spero sia chiaro a tutti cosa significhi.

L'update riferisce un articolo della Knowledge Base Microsoft identificato con KB2718704. Cercando questo identificatore su Google si trova un security advisory emesso da Microsoft proprio ieri:

Microsoft is aware of active attacks using unauthorized digital certificates derived from a Microsoft Certificate Authority. An unauthorized certificate could be used to spoof content, perform phishing attacks, or perform man-in-the-middle attacks. This issue affects all supported releases of Microsoft Windows.
Microsoft is providing an update for all supported releases of Microsoft Windows. The update revokes the trust of the following intermediate CA certificates:
  • Microsoft Enforced Licensing Intermediate PCA (2 certificates)
  • Microsoft Enforced Licensing Registration Authority CA (SHA1)
http://technet.microsoft.com/en-us/security/advisory/2718704

Aggiornamento successivo


Alert (TA12-156A)
Microsoft Windows Unauthorized Digital Certificates

X.509 digital certificates issued by the Microsoft Terminal Services licensing certificate authority (CA) can be illegitimately used to sign code. This problem was discovered in the Flame malware. Microsoft has released updates to revoke trust in the affected certificates
http://www.us-cert.gov/cas/techalerts/TA12-156A.html

giovedì 24 maggio 2012

Sfera di cristallo (e verbalizzazione online)

Mi è accaduto più volte di descrivere un rischio in una lezione di sicurezza informatica e poi, pochi giorni dopo, vedere una notizia che dimostra la concretizzazione proprio di quel rischio.

In questi giorni ho corretto gli esami del corso che ho tenuto al "Master in gestione della privacy e del rischio ICT nella pubblica amministrazione". L'esame consisteva di una elaborazione sul tema "Verbalizzazione online degli esami universitari". Tra le osservazioni collettive che ho fatto c'erano queste:
...
3) Quasi nessuno ha dimostrato di essere consapevole delle potenziali conseguenze di malware, virus e cose del genere (solo per dirne una, la possibilità di verbalizzare esami all'insaputa del docente; magari verbalizzandone uno o due in più proprio quando il docente sta verbalizzando una sessione d'esame). 

Anche in questo caso valuto negativamente il mio operato: non essere riuscito a trasmettere la nozione basilare che il pc può fare ciò che vuole lui, indipendentemente da ciò che vuole fare il suo proprietario ed indipendentemente da smartcard, etc.

Un attaccante può sfruttare questa possibilità. Che lo faccia o meno dipende dalla posta in gioco. Omettere questo aspetto dalla descrizione dei potenziali svantaggi non è corretto.

4) Quasi nessuno ha dimostrato di essere consapevole che non basta dire "occorre installare antivirus". I docenti sono molte centinaia, ognuno usa chissà quale PC, con chissà quale sistema operativo, lasciato chissà dove.

Garantire l'integrità dei PC, intesa come presenza del software che "ci deve essere" ai fini dei processi operativi dell'organizzazione e solo di quello, è un problema ENORME. Non basta dire cosa si dovrebbe fare, bisogna farlo davvero. Ed è quindi necessario chiedersi: "è realistico aspettarsi che ciò sia fatto ? cosa succede se non viene fatto ?"

Questo problema non è presente solo in università, ma in qualsiasi organizzazione. Un giudice naviga su Internet con il proprio portatile ? Ci mette le chiavette che usa anche sul pc di casa, magari suo figlio ? Male, malissimo....
...
Bene. Proprio stamani ho letto l'esito di uno hacking contest in cui è stato dimostrato come alterare il browser Chrome. Dettagli tecnici a parte, l'effetto è il seguente:

Installing and running native code with the privilege of the browser itself, simply by visiting a web page, and without any warning... you can now do everything the current user could do, and anything he wouldn't.
In two words, "Game over".
Più chiaro di così impossibile.

Non è la concretizzazione del rischio che ho descritto ma è esattamente la descrizione della sua piena fattibilità tecnica, con step descritti chiaramente su Internet.

martedì 22 maggio 2012

Concorso di poesia

La scorsa settimana ho partecipato alla 22-esima edizione di un concorso di poesia. Mi sono classificato secondo. Il tema di quest'anno era "la responsabilità". Segue il mio componimento...


Democrazia

Et voilà, ecco qua, chi l’avrebbe mai detto,
salta fuori un altro furbetto,
solo perché è stato eletto,
gli par normale farsi un bel tesoretto

Anche i suoi amici ed i suoi figli brillanti,
rimborsi e regali, diplomi e diamanti,
paghette mensili euro cinquemila
per incassare facevan la fila

Degna sequela di un altro cammeo
di quella casetta al Colosseo
“non so proprio come l’abbia avuta,
certamente comprata a mia insaputa”

Certo, certo, anche gli altri,
lo so bene, tutti assai scaltri
si urlano insulti di tutti i colori
poi tutti insieme ad intascare i valori

Pensioni, prebende e rimborsi a milioni
regalati da noi, come tanti "oioni",
a noi ogni giorno togliete qualcosa,
ma per voi la vita non è mai faticosa

Dovreste mostrare responsabilità
ma pensate solo alla tassabilità
Vedo ognuno di voi e quanto si approvvigiona,
io ogni giorno mi sento un poco più mona

giovedì 10 maggio 2012

cgi-php: Well, that just about wraps it up for open-source

I trust Chrome over Internet Explorer not because it's open-source, but because they pay people to put eyeballs on it. Thus, the new axis is "bounties vs. no-bounties", not "open-source vs. close-source".


Link


tags: WordsOfWisdom, Vulnerable, securityincident

giovedì 19 aprile 2012

Ma chissene degli hacker...

Consiglio caldissimamente la lettura a chiunque abbia a che fare anche solo lontanamente con la sicurezza informatica, anche da un punto di vista non tecnico.

"Every major company in the United States has already been penetrated by China." That's the claim being made by Richard A. Clarke, the former top US government counterterrorism official at the White House, in a long interview about cyber security (or lack thereof) in the April issue of Smithsonian magazine.

There is a long but fascinating story about hacking in today's Wall Street Journal that should send a cold chill into every corporate board room. It concerns the infiltration of Nortel Networks' computer systems by suspected Chinese-based hackers since at least the year 2000.
According to the WSJ, the hackers--using seven passwords stolen from top Nortel executives, including the CEO--"downloaded technical papers, research and development reports, business plans, employee emails and other documents" for the past decade or more. Nortel, which was once a leading telecommunications firmthat went bankrupt in 2009, is in the process of selling itself off in pieces as part of the bankruptcy process. There is now a concern that those companies purchasing Nortel IT assets may also be "purchasing" the hackers and their spyware as well.

Da leggere con calma. Articoli come questi fanno capire molto bene come stanno realmente le cose. 


venerdì 13 aprile 2012

Su quale sito sono "collegato" ?

E' ben noto, come sottolineo spesso a "Reti di Calcolatori I", che:
  • una pagina web è composta da molti documenti;
  • questi documenti possono essere prelevati da molti host;
  • gli host spesso non hanno nulla a che vedere con il sito dal quale si sta prelevando la pagina.
L'immagine seguente mostra questo fenomeno in modo interessante. Il server DNS del nostro lab ogni tanto "perde" le richieste (ne stiamo installando uno nuovo) il che, ogni tanto, impedisce il prelievo di qualche documento web. Quando ciò succede, Chrome visualizza un avviso nello spazio in cui avrebbe dovuto visualizzare il documento (clickare per ingrandire e vedi colonna di destra): uno crede di contattare solo www.corriere.it ma in realtà contatta anche rcspfm.simply.com.


Questo meccanismo è utilizzato per molti motivi leciti, ad esempio la delega della gestione delle pubblicità, del conteggio delle visite etc. E' utilizzato anche per motivi meno leciti, quali la diffusione di malware (http://www.citeulike.org/user/bartolialberto/article/9301761). In questo caso, un attaccante potrebbe infettare browser con vulnerabilità software semplicemente alterando il contenuto di  rcspfm.simply.com, il che è presumibilmente più semplice che non alterare quello di www.corriere.it.

Statistiche sul numero di documenti contenuti in ogni pagina, numero di host diversi da contattare per ogni pagina etc sono state raccolte da Google e rese disponibili pubblicamente. A parte tanti altri numeri, è interessante notare che in media occorrono ben 43,91 documenti per ogni pagina e questi documenti sono distribuiti, in media, su ben 7,01 host.

giovedì 29 marzo 2012

Ridere o Piangere ?



The Obama Administration this morning unveiled details about its Big Data R&D Initiative, committing more than $200 million in new funding through six agencies and departments to improve “our ability to extract knowledge and insights from large and complex collections of digital data.” The effort, spearheaded by the White House Office of Science and Technology Policy (OSTP) and National Science Foundation [...]

Il finanziamento dello stato italiano per i progetti di ricerca in TUTTI i settori dell'ingegneria industriale e dell'informazione (meccanica, civile, elettrica, etc etc etc) per l'anno 2012 è di circa $25M (cosiddetti programmi "PRIN", per l'esattezza 19.125.369 euro).

Poi si sente tanta gente blaterare di innovazione...

("big data" sono le applicazioni di machine learning, data mining e simili, le cose di cui ci occupiamo nel nostro lab)

mercoledì 21 marzo 2012

Vulnerabilità software (lezione Reti di Calcolatori I)

Video dimostrativo visto in classe:

Tutorial: Find and Exploit a Vulnerability (Nessus and Python)

This video shows how to use the Nessus vulnerability scanner to scan for a vulnerability, then exploit the flaw using a Python script I wrote as that uses the vulnerability "DD-WRT HTTP Daemon Metacharacter Injection Remote Code Execution" for a Proof-of-Concept DoS (denial of service) attack. The script uses the vulnerability to force the router to reboot, in essence creating DoS for all users who rely on the router for network access.

The vulnerability itself is a flaw which allows any attacker who is connected to the router to run a command of his choosing using "/cgi-bin/;[command]" appended to the URL. The attacker can also use this vulnerability to force the router to spawn a remote shell on a port of his choosing, then connect to it using a client such as Putty. Free root access. It's pretty bad.

Vulnerabilità del router:

Produttore del router:


mercoledì 14 marzo 2012

Onore alla ciurma

Ieri sera abbiamo ricevuto la notifica di accettazione di un nostro lavoro su Genetic Programming ad un importante congresso scientifico internazionale (Automatic Generation of Regular Expressions from Examples with Genetic Programming, ACM Genetic and Evolutionary Computation Conference 2012).
E' un risultato che mi rende "orgoglioso" per motivi che mi sembra opportuno rendere pubblici.

  1. Il lavoro è il risultato di TUTTI i componenti del laboratorio: Andrea, Enrico, Eric, Giorgio, Marco (ordine alfabetico). E' la prima volta che mi succede. Ognuno ha contribuito in base alle proprie competenze specifiche. Credo che la mancanza anche di uno solo dei componenti non ci avrebbe permesso di raggiungere questo risultato (i contributi non sono stati quantitativamente uniformi, ma ciò è irrilevante da questo punto di vista).
  2. L'idea iniziale non è venuta da me. Per molto tempo, inoltre, sono stato molto scettico sulla rilevanza del problema e sulla possibilità di ottenere soluzioni praticamente applicabili e scientificamente rilevanti. Non è la prima volta che mi succede: era già accaduto un paio di volte (se non vado errato), ma sempre per congressi di livello meno elevato di questo.
Sono quindi molto soddisfatto.
Per chi fosse interessato, questo è l'abstract:

We propose a system based on genetic programming (GP) for the automatic generation of regular expressions. The user describes the desired task by providing a set of labeled examples, in the form of text lines. The system uses these examples for driving the evolutionary search for a regular expression suitable for the specified task. The result may be used with common engines such as those that are part of Java, PHP, Perl and so on. Usage of the system requires neither familiarity with GP nor with regular expressions syntax. In our GP implementation each individual represents a syntactically correct regular expression and the fitness consists of a linear combination of two objectives to be minimized: the edit distance between each detected string and the corresponding examples, the size of the individual.  We performed an extensive experimental evaluation on 10 different extraction tasks applied to real-world datasets. We obtained very good results in terms of precision and recall, even in comparison to earlier state-of-the-art proposals.



e questa è una tabella con le regular expressions generate per vari problemi (generate con Genetic Programming, cioè in modo completamente automatico a partire da molte regular expressions generate in modo del tutto casuale).



giovedì 8 marzo 2012

Cloud Storage


Da un pò di tempo uso molto i servizi di cloud storage (directory locali sincronizzate automaticamente su di un sito web).

Hanno per me moltissimi vantaggi, tra i quali quelli che descrivo qui:
Se qualcuno decidesse di provarli, gli consiglio di provare Sugar Sync. Per me è decisamente il migliore di tutti.

Se poi lo prova seguendo questo link, c'è un vantaggio sia per me sia per chi prova (entrambi abbiamo 500 MB in più rispetto alla dotazione standard)

https://www.sugarsync.com/referral?rf=kbmrokr2bjix&utm_source=txemail&utm_medium=email&utm_campaign=referral

venerdì 2 marzo 2012

Esami o provette ?

Percentuale di promossi alle provette di Reti di Calcolatori
  • Circa la metà di quelli che si presentano alla prima provetta supera l'esame con le due provette.


Percentuale di promossi alle provette di Reti di Calcolatori II
  • Circa i tre quarti di quelli che si presentano alla provetta (ma si presentano molti di meno che a Reti I).
Meglio esami o provette ?
  • La percentuale di promossi agli appelli ufficiali è molto più bassa rispetto alla percentuale di promossi alle provette
I dati in realtà non sono omogenei: i risultati per le provette sono quelle di Reti I, quelli per gli appelli ufficiali comprendono tutti gli insegnamenti. La sostanza però è evidente.

Perché voglio che gli studenti si iscrivano per tempo agli esami ?

Basta notare:

  • il numero assoluto (varie centinaia ogni anno)
  • la quantità di colori diversi

Inoltre, i 5 colori di ogni barra---che sono già molti---sono in realtà il raggruppamento di molte altre varianti che richiedono esami diversi: Reti di Calcolatori da 3 cfu, 6 cfu, 9 cfu; Complementi di Reti di Calcolatori e Reti di Calcolatori II; Fondamenti di Informatica I e Fondamenti di Informatica II.

Gestire questa situazione è molto complicato.




Frode nella registrazione degli esami


Come dico sempre, l'elemento principale è la motivazione dell'attaccante; se la motivazione è adeguata, allora si può fare (quasi) tutto.

Speriamo bene...

Palermo:
Le accuse a loro carico sono accesso abusivo a sistema informatico, frode informatica e falsità ideologica in atto pubblico.... I due dipendenti, infatti, avevano accesso al sistema informatico Gedas in dotazione all'Ateneo per la registrazione degli esami sostenuti dagli studenti. Dal confronto incrociato tra la documentazione cartacea...e quella informatica, infatti, è emersa la divergenza dei dati registrati...In tutto sono 200 i casi di falsi esami accertati e numerose sono le persone indagate....casi sono stati riscontrati anche ...Ingegneria.

giovedì 1 marzo 2012

Ipotesi 1: "le chiavi private sono davvero private"

Chiunque abbia seguito uno dei miei corsi sulle applicazioni pratiche della crittografia a chiave pubblica ha:
  1. sentito ripetere fino alla nausea che tutte si basano su tre ipotesi, che se le ipotesi non sono verificate allora non c'è nessuna garanzia, che soddisfare una ipotesi può essere difficile o meno ma è sempre un atto di fede etc etc etc.
  2. certamente pensato: "Bartoli è un pò fissato con queste cose".
Rivest, la "R" di RSA ed uno dei tre inventori della crittografia a chiave pubblica, ha sottolineato di recente più o meno le stesse cose con le quali martello gli studenti da anni:
Rivest, a professor at MIT and one of the inventors of the RSA algorithm, said that keeping the corresponding secret keys secret can be just as hard. The assumption that secret keys could be kept private is one of the underlying principles of public-key cryptography, and if it can't be done properly, then the cryptosystems that rely on it can fail.
"The assumption that people can keep their secrety keys safe is one of those assumptions that I think we need to go back and examine more carefully," Rivest said. "In fact, it's been shown to be a bad assumption in many ways. We can't keep keys safe."
(notizia completa qui)
Sottolineo questo solo per dire che se sono così fissato un motivo c'è.

Tra l'altro, Rivest parla anche di un aspetto di cui ho iniziato a parlare anch'io, ma non con l'enfasi e l'importanza che merita: dobbiamo chiederci cosa fare se le cose vanno male; occorre cioè partire dal presupposto che le cose possono andare male (invece di dare per scontato che se vanno male è proprio un evento singolare e sfortunato).

mercoledì 29 febbraio 2012

venerdì 17 febbraio 2012

Intrusioni in Verisign (!)

Notizia Reuters


VeriSign Inc, the company in charge of delivering people safely to more than half the world's websites, has been hacked repeatedly by outsiders who stole undisclosed information from the leading Internet infrastructure company.

Commento di Bruce Schneier

The problem for all of us, naturally, is if the certificate system was hacked, allowing the bad guys to forge certificates. (This has, of course, happened before.)
Are we finally ready to accept that the certificate system is completely broken?


mercoledì 15 febbraio 2012

Vulnerabilità nelle implementazioni di RSA (?)

UPDATE: le conseguenze ci sono, ma sono meno gravi di quanto pensavano...
(
http://www.theregister.co.uk/2012/02/21/rsa_crypto_analysis/)


Fino a qualche anno fa, nel corso di Reti I spiegavo qualche cenno di RSA, il sistema di crittografia a chiave pubblica usato "ovunque", per Internet banking, firma digitale etc. Da quando ho cercato di alleggerire un pò il corso non lo faccio più. Qui si trovano le slide che facevo.


Il sistema è strutturato in questo modo: per generare una coppia chiave privata - chiave pubblica si genera una coppia di numeri primi random e molto grandi; questa coppia è nota solo al possessore della chiave privata; la chiave pubblica è il prodotto di questi numeri. In parole poverissime, la sicurezza del marchingegno si basa sul fatto che 1) dato un numero molto grande che sia il prodotto di due numeri primi, trovare questi numeri primi è computazionalmente "exceedingly expensive"; e 2) i numeri primi sono generati in modo sufficientemente random (ovviamente la faccenda è molto più complessa, la cosa veramente complicata è la garanzia aggiuntiva che la conoscenza del testo crittato non permette di escludere a priori nessuna possibile chiave).


Sul New York Times è uscita una notizia interessante. Alcuni ricercatori hanno analizzato un database di chiavi pubbliche RSA e, sembra, che per lo 0.2% di queste chiavi la proprietà 2 non sia verificata. Ciò implicherebbe che "as many as two out of every thousand keys would not be secure". Non si tratterebbe di un errore nell'algoritmo ma nelle implementazioni dell'algoritmo.


Notizie di questo genere vanno prese con le molle. La correttezza della loro analisi e delle loro conclusioni, al momento, non è stata ancora validata da nessuno. Il loro lavoro è stato sottomesso ad una conferenza scientifica e, come accade sempre, è in corso di valutazione da parte di revisori anonimi che faranno di tutto per dimostrare che si sono sbagliati. Per inciso, il fatto che i ricercatori abbiano deciso di rendere pubblica la loro analisi prima che sia stato completato questo processo di valutazione a me, modestissimamente, non sembra una bella cosa.


Le implicazioni pratiche delle loro conclusioni, ammesso e non concesso che abbiano ragione, non mi sono del tutto chiare. Probabilmente non lo sono ancora a nessuno. Una implicazione è certamente di ordine "didattico" (comprensibile a chi ha fatto Reti II): 1) gli algoritmi possono essere teoricamente errati, 2) possono essere implementati in modo errato, 3) il software che realizza le implementazioni può a sua volta essere errato. Il grossissimo problema pratico è il 3, spesso si sono verificati anche i casi 2 e questo sarebbe, appunto, un altro caso 2.