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