Tag Archives: ripe

Twitter e identità digitale nei social network

Che succede se qualcuno ti “ruba” l’account su Twitter? Nel momento in cui sto scrivendo, ad esempio, l’account “Microsoft” (http://twitter.com/microsoft) è vuoto e non appartiene all’azienda produttrice di Windows.

Uno “scherzo” come questo, nel campo dei domini internet, si chiama typosquatting (ne avevo già parlato da qualche parte): il nome (trademark) di un’azienda famosa (Microsoft, in questo caso) viene sfruttato per attirare traffico verso un sito o un servizio che con Microsoft non ha niente a che vedere. Il typosquatting non è legale e l’ICANN gestisce i casi dubbin tramite  attraverso l’UDRP.

Twitter è un giochino carino, a volte utile, ma non fondamentale per il funzionamento di Internet. E se un giorno diventasse importantissimo? Sarebbe corretto che l’account Microsoft non fosse assegnato a chi, normalmente, ne avrebbe diritto?

Un anno fa Steve Poland fa incetta di account Twitter con l’intento dichiarato di rivenderli quando avranno acquisito valore. Uultimamente, però, se li vede annullare uno a uno per essere restituiti ai “legittimi proprietari”. Io penso che la decisione sia stata corretta (Steve Poland è solo uno speculatore). In generale, però, Steve ha ragione quando si chiede

I’m just wondering, when does it end? My personal twitter account is STP — are you going to pull that from me when STP (motor oil company) or Stone Temple Pilots comes to you guys and claims trademark infringement? My initials are STP — as in, “Steven Thomas Poland.”

Stiamo parlando di identità digitale: FaceBook, MySpace, Second Life e qualsiasi applicazione Web 2.0 identifica i propri utenti tramite un nickname univoco. A lungo andare, si crea una relazione forte fra utente reale e suo alter ego digitale un po’ come capita già fra un’azienda e il suo marchio. Da qui nascono due problemi importanti e contrapposti:

  1. Il problema della continuità, stabilità e persistenza del doppio virtuale dell’utente. La sicurezza, cioè, che un nickname o un account non venga cancellato, riassegnato e sospeso, magari perché inutilizzato per un certo periodo di tempo o perché richiesto da qualche entità terza che non ne abbia diritto.
  2. Il problema del Yet Another Social Network, il rischio, cioè, che l’identità che è di un utente in un’applicazione (spesso, lo ripeto, consiste di un semplice nickname) sia assegnata (magari anche in modo legittimo) a un altro utente in un’altra applicazione (UPDATE: per l’appunto, qui si parla di Reverse User Name Hijacking)

Esistono delle proposte in questo senso (OpenID, ad esempio) ma, oltre a non essere soluzioni definitive, sono, per ora, gestite da compagnie private, che non è il massimo.

Io credo che il problema dell’identità digitale, con tutti i suoi risvolti tecnici e legali, non sia ancora stato compreso e affrontato adeguatamente e mi chiedo se sia necessario, nel prossimo futuro, iniziare una riflessione di ampio respiro su questo tema (di typosquatting, ad esempio, si parla da anni e ormai c’è anche una certa letteratura legale a riguardo. Ma il problema è ancora lungi dall’essere risolto).

Per ulteriori approfondimenti consiglio la lettura di Social Media User Names Becoming More Like Domain Names apparso su DomainNameNews qualche giorno fa.

Advertisements

Il segreto di Pulcinella

Come previsto, il segreto (che segreto non era da un pezzo) ora e’ totalmente di pubblico dominio.

Una breve ricerca con Google individua gia’ decine di siti (Slashdot compreso) che parlano del non-segreto. Ad esempio, qui.

In pratica, Halvar Flake ha formulato un ipotesi e un ricercatore di Matasano Security ha gentilmente confermato. Tranquilli, ora chiede scusa. In pratica, il super-segreto che era mezzo segreto perche’ molti lo conoscevano, anzi un quarto perche’ chi non lo conosceva dice che uno bravo lo avrebbe capito, anzi un ottavo perche’ quello bravo dice che era troppo facile per lui, non e’ piu’ segreto.

Qui la descrizione dettagliata, di seguito una spiegazione “fatta in casa” per cercare di dare forma ai tecnicismi.

***
Supponiamo che io sono un cattivo e voglio far si’ che tutti gli utenti di un ISP (esempio, Telecom Italia) che visitano il sito di Repubblica.it vengano indirizzati al mio sito (fasullo) di Repubblica. Quello che devo fare e’ incredibilmente semplice:

  1. Interrogo il nameserver di Telecom Italia con “AAAAAA.REPUBBLICA.IT” (suponiamo si chiami NS-TI)
  2. Il sito non e’ nella cache di NS-TI e questo gira la richiesta al nameserver di Repubblica.it (es, VENERE.INET.IT)
  3. VENERE.INET.IT dovrebbe rispondere qualcosa del tipo “sito inesistente” e la risposta sarebbe memorizzata da NS-TI
  4. Fra domanda e risposta c’e’ un breve intervallo di tempo in cui io, cattivo, posso creare una risposta fasulla da spedire a NS-TI
  5. Non c’e’ modo, per NS-TI, di sapere chi ha generato una data risposta, o meglio, un modo c’e’: ogni query contiene un ID generato casualmente che deve essere riprodotto nella risposta
  6. Io, cattivo, non conosco questo ID e posso solo indovinarlo. Le probabilita’ sono molto basse, ma se lo indovino ho convinto NS-TI che la mia risposta fasulla e’ invece quella vera. Quante probabilita’ ho di indovinare? 1/65536 (circa), se gli ID vengono generati casualmente. Molto bassa, ma posso ripetere lo stesso giochino con AAAAAB.REPUBBLICA.IT e cosi’ via finche’ non “c’azzecco”

Supponiamo che, ad un certo punto, riesca a convincere NS-TI che FFFFFF.REPUBBLICA.IT sia io. A che mi serve? Nessuno digitera’ un indirizzo cosi’ stupido. Vero, ma si da il caso che ci sia una piccola regolina nel funzionamento del DNS che mi dice che, insieme alla risposta di FFFFFF.REPUBBLICA.IT, io possa mandare un update per VENERE.INET.IT.

Cosa vuol dire? Che da questo momento in poi, qualunque utente del service provider Telecom Italia che digiti WWW.REPUBBLICA.IT sul suo browser verra’ rediretto al mio sito. Ora immaginate che questo giochino venga fatto con il sito di una banca online.

***

SOLUZIONE
Senza entrare nei dettagli, Dan Kaminski propone di applicare un “source port randomisation”, che vuol dire che io, cattivo, non solo devo indovinare l’ID contenuto nel messaggio ma anche la porta UDP dal quale il messaggio e’ partito.

La comunita’ internet e’ d’accordo che questa e’ una mezza soluzione, perche’ se diminuisce le probabilita’ dell’attacco non lo elimina del tutto:

  • Ho letto da qualche parte che alcuni cache resolver non usano tutte le porte possibili (65535) ma solo un sotto-insieme, rendendo la soluzione meno efficace
  • In altri casi, le porte cambiano in maniera sequenziale (cioe’, se prima ho usato 1025, ora uso 1026 e cosi’ via)

Ma il vero problema e’ che se prima un hacker ci impiegava 10 secondi adesso ci impiega, nel peggiore dei casi, 10*65535 secondi, circa 8 giorni. Cio’ che fa la differenza e’ la mole di traffico che l’attacco genererebbe, che difficilmente non verrebbe notato dai firewall degli ISP.

Se l’attacco, pero’, venisse distribuito in maniera intelligente fra vari ISP e diluito in un periodo di tempo piu’ lungo (ad esempio, qualche mese) potrebbe non essere facilmente rilevabile. Se i tempi vi sembrano lunghi, pensate che, con un simile attacco, avreste la certezza che da qui alla fine dell’anno il sito della vostra banca preferita sara’ hackerato. Speriamo solo “non con il mio ISP.

L’unica soluzione, come ho parlato da qualche parte, e’ DNSSEC, ma ha ancora troppe resistenze di tipo politico.

PS: in ogni caso, ho la vaga sensazione che manchi ancora un tassello… forse, pero’, questa volta mi sbaglio.

Nuova falla nel DNS

Questa e’ abbastanza grave, qui si parla di Alleanza che ci salvera’… e’ forse arrivata Star Trek?

In pratica, Dan Kaminski (di cui si parla anche qui) ha scoperto una falla molto grave nel DNS, i cui dettagli rimarranno riservati per ancora 30 giorni per dare il tempo a tutti i (aka, il maggior numero possibile di) ISP di aggiornare il loro software.

Diciamo pure che ne riparliamo tra un mese, ma secondo me diventera’ presto un segreto di Pulcinella e fra non molto vedremo i primi attacchi ai DNS.

A risentirci.

DNS Ops Workshop

(cross-post Experiment, Three)

As promised, I post a report of the DNS Ops workshop I attended last week. The workshop has been very interesting, though a few talks were a bit too technical for me, which I only have a partial knowledge of DNS operations. Following, then, you will find a non-comprehensive list of “impressions” rather than a detailed report.

A Statistical Approach to Typosquatting
Of course 😉 I will start from my talk, which reports the preliminary results of the research on typosquatting I have been conducting recently. The slides can be found here (and here as well, as I gave the same talk at the Centr technical meeting in May).

The talk seems to have generated a bit of interest in the audience, though I think it suffered a bit from the fact that these are “early results” and much work still needs to be done before we can claim we really understand what typosquatting is (at least from a technical point of view). The talk also raised a bit of questioning about Nominet’s involvement in typosquatting. Just to be clear, at the moment Nominet is interested in my work only from a research point of view and is not taking any position in favour or against any registrar, registrant or any other party that might think to be the object of my work.

DNS monitoring, use and misuse
According to Sebastian Castro (CAIDA), in 2007 only 510 unique IP addresses generated 30% of the traffic at the root servers and 144 of them (called Heavy Hitters) sent more than 10 queries/sec and in 11 cases more than 40 queries/sec.

This are impressive numbers which might tell something about the kind of traffic that daily takes place in the Internet.

Later on, Shintaro Nakagami from NTT Communications, one of the major ISPs in Japan, reported that only 15% of the queries hitting their name servers were legitimate. This doesn’t mean that the other are necessarily malicious, for example, many of them are simply malformed queries or are generated by misconfigured web servers, however…

Finally, Young Sun La (NIDA, Korea) showed an impressive tool that they use at NIDA for monitoring queries to the .kr name servers in real time. It even sends sms’ to sysadmins if an urgent problem arises. Have a look at the slides for an idea of how it works. I might have heard that the software will be released for download, but I might have misunderstood.

Heatmaps
How do you conveniently represent the IPv4 space? With a Hilbert Curve, for example, or, as Roy Arends (Nominet) suggests, with a Z-order curve. The resulting graph is more intuitive to read and can easily be extended to work in a 3D space.

Check out his interactive tool (from Nominet website) and his slides. In particular, go to slide number 9 and watch the heatmap of… women below 30 and earning more 100000$/year in Manhattan!!

Privacy issues in DNS
Karsten Nohl (University of Virginia) talked about the privacy issues related to the use of DNS caches. When users query the DNS they leave pieces of information in many caches and they have to trust several entities, ISPs, registries, backbone operators, etcc, that their information will not be released, sold, etc.

DNS operators cache the results of user queries, i.e., the IP corresponding to certain URLs in order to retrieve them more efficiently. This information is anonymous, i.e., they do not register the IP who made the query (in theory), but in practice certain URLs are used only by one (or a small subset of) person(s). At present, it is relatively easy for a malicious party to trace the online behaviour of some user by querying specific DNS servers only and check whether a specific URL is present in their cache.

Such an attack can be used to identify the individuals that access a specific web site: knowing the IP gives the geographic localisation of a user, but knowing his/her online behaviour might disclose much more personal information. Alternatively, it might be possible to track a specific user.

This scenario might become even more critical with the large-scale deployment of RFIDs. RFIDs have unique identifiers but are too small to store information (e.g., product information, price, etc) and they will use the DNS to look up for this data. Then, RFIDs (which have unique identifiers) will be indexed by the DNS and it will be easy to identify single users.

Piu’ di meta’ del traffico Internet e’ P2P

Il traffico P2P rappresenta piu’ del 50% del traffico complessivo di Internet.

La notizia, e’ particolarmente interessante perche’ discussa lunedi scorso al RIPE, la conferenza semestrale dei registry europei (quelli che gestiscono il DNS, per intenderci) e dei rappresentanti dei maggiori ISP. Durante questa conferenza si discute di Internet e della sua evoluzione, in termini di infrastruttura, a livello europeo.

Il nocciolo della presentazione e’: un ISP conosce la locazione fisica di un peer, la banda, etc. I peer, quando devono scegliere i propri “vicini” (neighbour), contattano l’ISP che, conoscendo lo stato della rete, puo’ scegliere quelli che, complessivamente, minimizzano la latenza, massimizzano la prossimita’ geografica, etc. Il risultato e’ una topologia non ottimale ma con prestazioni migliori di una completamente casuale…

A essere sincero, c’e’ qualcosa che non mi torna in questa proposta, e cito solo una delle conclusioni finali:

Benefits
ISPs: regain control of network traffic

Per carita’, io non sono contrario a un certo tipo di controllo operato dagli ISP, ma un conto e’ limitare il traffico, un altro scegliere i neighbour a cui un peer si collega (se vogliamo fare della filosofia, controllare la topologia di una rete P2P equivale a controllarne i flussi informativi).

A parte questo, credo che parlare di peer-to-peer fra un DNS e un IPv6 e’ indice che la tecnologia sta diventando matura e che si stanno cominciando a riconoscerne le potenzialita’. E questo non puo’ che essere positivo.

ale

ps: perche’ nel grafico della seconda slide gli autori distinguano fra P2P e VOIP?