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.

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.

Italian TLD and malicious web sites

(cross-post Experiment, Three)

Mapping the Mal Web, Revisited (McAfee, June 4).

A new security report from McAfee has just been released on the spread of malicious web sites among different TLDs. Very informative and detailed, the report integrates last year report. Some of the key findings:

• .ro (Romania) and .ru (Russia) are the most risky European TLDs, i.e., the probability of finding a malicious web site is higher if surfing one of those TLDs.
• Risk related to .biz (business) and .cn (China) is also increasing (if compared to last year)
• .it (Italy) has worsened, but is still “a safe place”
• .hk (Hong Kong) is the riskiest TLDs

The “Hong Kong” case, in particular, is worth a closer attention:

Bonnie Chun, an official [from the .hk] TLD, acknowledged that they had made some decisions that inadvertently encouraged the scammers:
1 . “We enhanced our domain registration online process thus making it more user-friendly. Instances include the capability for registering several domains at one time, auto-copying of administrative contact to technical contact and billing contact, etc. Phishers usually registered eight or more domains at one time.
2 . We offered great domain registration discounts, such as buy-one, get-two domains.
3 . Our overseas service partners promoted .hk domains in overseas markets.”

In a previous post I talked about the recent increased phishing activity in the .uk registry, which, in that particular case, has taken advantage from Nominet’s automatic registration process.

Other country, other problem: the .it registry will implement automatic registration procedures by the end of the year; and I read, a couple of weeks ago on Swartzy’s blog, that the IIT/CNR is also launching an advertisement campaign for .it domains.

I am curious to see if, in analogy to what happened in Hong Kong, we will see an increase of the malicious activity in the .it TLD.

Internet e’ a rischio?

Ieri mi sono imbattuto nelle 10 minacce alla rete, tradotto in Italiano da Web *.0? (qui la cronistoria, dal post originale in poi). Come primo impulso, mi sono chiesto perche’ mai dovremmo essere a rischio di censura o di eccessiva regolamentazione da parte dei governi? Il problema piu’ grande della rete, al momento, sono botnet e frodi informatiche, che ne minano alla base la reputazione.

Poche ore dopo mi sono trovato a parlare di phishing con un collega, come capire se un sito web nasconde una frode per raggirare gli utenti ignari. E chi, fra coloro che operano su Internet, dovrebbe combattere la diffusione di queste pratiche criminali.

Le conclusioni a cui siamo giunti sono un po’ prevedibili e un po’ sconfortanti (e diverse da quelle da cui sono partito). Ne elenco alcune in ordine sparso:

• Tecnicamente sarebbe possibile, se non bloccare completamente, almeno arginare il fenomeno del phishing. Si potrebbe analizzare il contenuto della pagina incriminata e confrontarlo con quello del sito autentico. Si potrebbe cercare il sito nell blacklist di siti come spamhous o analizzare il traffico DNS per capire se tale sito fa parte di una qualche botnet.
• La risposta potrebbe essere l’interdizione/chiusura temporanea del sito fino a che i proprietari non hanno abbiano fornito spiegazioni sulla sua attivita’.
• Quello di cui stiamo parlando e’, a tutti gli effetti, un filtro.
• Difficilmente gli ISP implementerebbero una soluzione di questo genere.
• Se venisse fatto a livello di DNS, data la natura centralizzata e storicamente legata alle istituzioni di questo servizio, si parlerebbe di alto rischio di censura: :chi lo sa che tipo di traffico viene veramente bloccato?:
• …

In pratica, il dubbio che una soluzione di questo tipo non possa essere implementata senza un cambiamento nella regolamentazione vigente e’ forte; e il rischio che possa essere interpretata come invasione della privacy degli utenti o, peggio ancora, come forma di censura, impedendo l’accesso a siti presunti malevoli, lo e’ ancora di piu’.

***
Alla fine (per tornare alla domanda del titolo), io non credo che Internet sia a rischio; penso, tuttavia, che mai come in questo momento sia necessaria un’estrema cautela da parte di quegli organi che ne determinano l’evoluzione e lo sviluppo, perche’ l’equilibrio fra sicurezza, liberta’ d’espressione e privacy degli utenti e’, per ora tutt’altro, che scontato.

Botnet in affitto

Una sintesi impeccabile a cura di Alberto Berretti sul proliferare delle botnet in Internet.

Le ragioni economiche e politiche che si nascondono dietro al fenomeno delle botnet e’ spiegato egregiamente nel post di Berretti. Qui voglio aggiungere solo una piccola considerazione su un fenomeno sorprendente, o forse inevitabile, osservato di recente: e cioe’, che esistono botnet in grado di attivare misure di autodifesa contro chi cerca di studiarne i meccanismi.

Se un ricercatore si collega a uno o piu’ bot per studiarne il comportamento si puo’ ritrovare a subire un Distributed Denial-of-Service, con decine di migliaia di messaggi provenienti dalla botnet che bloccano il suo computer e i server del suo service provider. In alcuni casi si parla anche di botnet in grado di rilevare altri tipi di “controlli esterni”: un tempo di risposta troppo lungo, ad esempio, puo’ indicare la presenza di una rete di controllo che filtra e analizza ogni comunicazione in entrata e uscita da un particolare pc. Il bot che lo controlla puo’, a questo punto, scatenare l’attacco e disattivarsi per evitare ogni futuro controllo (quest’ultima forma di auto-difesa, a dire il vero, mi e’ stata “raccontata” ma non sono riuscito a trovare nessun riferimento in Internet).

Google Apps Security Services

Allora, vediamo se ho capito quello che ho letto qui.

Il nuovo pacchetto Security di Google Apps offre delle funzionalita’ che aumenteranno la sicurezza di applicativi email quali “Microsoft Exchange Server, Lotus Domino, Postfix, Sendmail, Macintosh OS X Server, Novell Groupwise”. Il pacchetto, quindi, e’ orientato ad un utilizzo aziendale, cioe’ dove tali server sono in genere installati.

Le tariffe sono competitive e i servizi probabilmente validi (come al solito, quando si parla di Google):

* message filtering: anti-spam, anti-virus, anti-phishing, and malware protection for inbound messages – $3/user/year
* message security: inbound and outbound mail filtering, email encryption, content policy management – $12/user/year
* message discovery: the same as above plus one-year message archiving, audit reports – $25/user/year

Il vero problema, pero’, emerge quando ci chiediamo come funzioni questo sistema:

You change the MX records to point your mail traffic to Google’s data centers and all the bad traffic will be stopped before reaching your mail server.

A quanto pare, tutta la posta dell’azienda deve passare attraverso i server di Google! Fra le righe, infine, leggiamo che

Google processes email in RAM and doesn’t write the valid messages to disk

segno che qualche nota stonata e’ emersa anche da quelle parti.

Insomma, da un punto di vista della privacy aziendale non mi sembra accettabile consegnare nelle mani di un soggetto esterno tutta la propria corrispondenza, nella speranza che rispetti il suo motto e “non sia cattivo”!