Twitter horror

Non nutro una particolare simpatia per i social network più famosi, preferisco occuparmi delle implicazioni che possono portare in ambito di privacy e web security. Twitter è una piccola eccezione: mi piace perchè è immediato e semplice.

Twitter, come altri social network, è stato bersaglio di problemi di sicurezza nel corso del tempo. Recentemente ho notato, insieme a Rosario Valotta, un problema di sicurezza che poteva permettere ad un attaccante di prendere il pieno controllo di un account tramite il click su di un link da parte della vittima.

Più nel dettaglio il problema era relativo alla validazione dei parametri della query string: a causa di alcuni caratteri Unicode non correttamenti gestiti dall’applicazione e dall’output del nome del paramentro senza encoding era possibile far scattare un XSS richiamando una URL di questo genere:

http://twitter.com/testxss?<script>alert(‘xss’)</script>=%A2

Il problema della validazione dei caratteri unicode su Ruby On Rails, framework sul quale Twitter è basato, è stato risolto a Settembre 2009. Niente di nuovo, anche se non eravamo a conoscenza dell’articolo prima di fare indagini sulla vulnerabilità trovata. E’ buffo che nei primi giorni di Settembre, Brian Mastenbrook (a cui vanno i crediti per il problema degli Unicode su RoR), sul suo blog ha dichiarato:

After a few days of not receiving a response from either vendor, I decided to ping both of them to get an update. I pinged a security researcher who I knew worked at Twitter, and after a little back and forth things were quickly resolved and Twitter was patched.

Probabilmente hanno installato la patch senza fare code review dell’intero software o perlomeno delle funzioni utilizzate per la validazione dell’output.

L’XSS sul dominio twitter.com permetteva il pieno controllo dell’account della vittima al solo click di un link presente in un twit . Una falla innocente, come viene classificato l’XSS, in questo caso poteva innescare una infezione virale proprio per la natura su cui si basano i social network.
Tecniche come identity stealing, malware distribution e spam sarebbero state immediate.

Il video seguente dimostra in azione la vulnerabilità sfruttata da un JavaScript di poche righe scritto in qualche minuto:

Twitter dovrebbe curarsi maggiormente della sicurezza dei propri utenti, ed essi dovrebbero avere maggiore cura delle informazioni personali che pubblicano nel World Wide Web.

Disclosure:

  • 27 Ottobre: trovata la vulnerabilità
  • 28 ottobre:  Twitter avvisato del problema
  • 3 Novembre: Twitter riconosce il problema nella advisory di Brian Mastenbrook (ma non era già stata installata la patch?)
  • 10 Novembre: Twitter corregge la pagina di errore togliendo l’output del nome del paramentro
 

Utilizzi impropri dell’header HTTP X-Forwarded-For

L’header X-Forwarded-For, come tutti gli header HTTP che hanno come prefisso “X-”, è un campo non definito da una RFC ma introdotto da Squid. E’ utilizzato per segnalare al server Web l’IP assegnato al client, che fa uso di un proxy.

Quando si scrive un’applicazione Web normalmente si tiene traccia o si utilizza in vari modi l’indirizzo IP del client che ha effettuato la richiesta. In tal senso è veramente semplice ottenere l’indirizzo IP tramite un qualsiasi linguaggio lato server.

Ecco come potrebbe presentarsi una tipica richiesta che passa attraverso Squid:

Host: www.example.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
X-Forwarded-For: 192.168.30.25
Proxy-Connection: keep-alive

L’header X-Forwarded-For, essendo sotto il pieno controllo del client, può essere utilizzato da un attacker per veicolare qualsiasi contenuto. Capita spesso di vedere un utilizzo completamente errato di X-Forwarded-For:

//PHP style
$ip = $_SERVER['X_FORWARDED_FOR'] ? $_SERVER['X_FORWARDED_FOR'] : $_SERVER['REMOTE_ADDR'];

oppure

// C# style
String _ip = Request.ServerVariables["HTTP_X_FORWARDED_FOR"];
If (_ip == "" || _ip.ToLower == "unknown")
_ip = Request.ServerVariables["REMOTE_ADDR"];

La logica del codice precedente fa in modo che se l’header X-Forwarded-For è presente viene preso il suo contenuto, senza nessun tipo di validazione, come indirizzo IP del client. In questo non è difficile creare ad arte richieste per ingannare l’applicazione:

X-Forwarded-For: 1.2.3.4

oppure

X-Forwarded-For: ‘ ; SELECT VERSION() –

La logica giusta per gestire gli indirizzi IP è quella di utilizzare il contenuto dell’header X-Forwarded-For in maniera non esclusiva e sopratutto di trattarlo come un qualsiasi user-input.

 

A quando la carta d’identità?

Facebook non ha nessun rappresentate ufficiale in Italia: l’unica sede in Europa è quella di Londra. Nessun problema fin quando non viene bloccato il proprio  l’account. Qualcuno ne sa qualcosa.

Senza dover andare troppo indietro, FBHive all’inizio di Giugno ha segnalato un bug che permetteva l’accesso incondizionato alle informazioni personali di qualsiasi account presente sul social netowork. La segnalazione  a Facebook è stata fatto il 7 Giugno e solo dopo il 23 Giugno, quando FBHive ha pubblicato un post,  il bug è stato preso sul serio e corretto nell’arco di qualche ora. Senza dover entrare troppo nel tecnico il bug permetteva, tramite la modifica a piacimento del parametro “userid”, inviato dalla pagina che gestisce le modifiche al proprio profilo personale, la visualizzazione delle informazioni personali dell’account avente l’userid specificato.

L’ultima moda di Facebook sono state le vanity url, ovvero la possibilità di legare (in maniera indissolubile) una URL breve al proprioprofilo. Una mossa, forse avventata, fatta per portarsi alla pari di altri tutti i social network concorrenti. Il cybersquatting era inevitabile e così è stato. Per correre ai ripari hanno attivato un metodo di verifica:

Prima di impostare il tuo nome utente, devi verificare il tuo account.

Prossimamente verrà chiesta la carta d’identità per poter usare un social network?

La privacy è sempre un concetto astratto, che nei prossimi anni si dovrà delineare. Questo concetto si evolverà con l’evolvere dei cittadini digitali che sempre più faranno coincidere la propria identità reale con quella virtuale.

Per ora manca la consapevolezza del Web: Internet ha memoria ed è sempre disponibile.
Facebook, come altri social network, è già la nostra carta d’identità on-line:  dati anagrafici, relazioni interpersonali, tendenze (politiche, sessuali,ecc..), ecc.

Si possono utilizzare tutti i social netowrk che si vuole, ma è necessario avere ben chiaro quale sarà il bacino di utenti che usufruirà delle nostre informazioni. A tal proposito consiglio la lettura della guida alla configurazione dei parametri sulla privacy previsti da Facebook e la policy scritta da Giovy.

 

Month of Twitter bug

Twitter Luglio sarà il mese dei bug legati  a tutti i servizi che utilizzano le  API di Twitter: Month of Twitter Bug (MoTB per gli amici) appunto.
Ieri sono stati pubblicati diversi XSS riguardanti il servizio bit.ly utilizzato per rendere più brevi le URL. La pericolosità degli XSS sta nel fatto che nell’account di bit.ly si possono inserire i profili di Twitter in modo da postare gli aggiornamenti direttamente da quel servizio. In questo modo un XSS può permettere all’attaccante di aggiornare l’account di Twitter della vittima senza che questa se ne accorga.

Per ora non sono state ancora pubblicate i dettagli del secondo servizio coinvolto a causa del fuso orario.
Per oggi 2 Luglio è statopublicato un XSS sul servizio HootSuite che permette la gestione di più account Twitter. Leggendo i commenti del post però sembra che ci siano altri XSS sul servizio oltre a quello segnalato dal MoTB.

L’idea è venuta ad Aviv Raff, già coinvolto nel Month Of Browser Bug creato da H.D. Moore, per mettere in luce quanto sia importante la cura della sicurezza dei servizi terzi che utilizzano le API di Twitter. Non ci vorrebbe molto a scrivere un worm che, sfruttando tutte queste vulnerabilità, impatti su un gran numero di utenti di Twitter.

Sarà sicuramente interessante leggere tutte le vulnerabilità che verranno pubblicate durante il mese.

 

CAPTCHA che si risolvono da soli

CAPTCHA antani
Si discute da tempo se sia sempre utile utilizzare i CAPTCHA. Usabilità pari a zero risolta con lettori audio di testi e debolezza a OCR avanzati e manodopera a costi ridicoli risolta con tecniche che rincorrono sempre gli attaccanti.

C’è un Corriere Espresso Italiano che per effettuare il tracciamento della spedizione chiede, oltre al solito numero di tracking, di compilare un form con le lettere che appaiono dentro un CAPTCHA.
La cosa simpatica è che l’url dell’immagine che viene richiamata attraverso il codice HTML punta ad una Servlet che disegna, attraverso il metodo ActionTracking.doGetCaptcha, le lettere del CAPTCHA grazie ad un paramentro presente nella query string:

<img src=”/ResourceServlet.html?execute2=ActionTracking.doGetCaptcha&ses_id=…&text_immagine=HNHILE” border=”0″>

ActionTracking.doGetCaptcha scrive le lettere ricevute in GET nella sessione corrente per poi poter controllare, nel passo successivo, la correttezza delle lettere inserite nel campo di testo. In questo modo, per automatizzare il processo di controllo di stato della spedizione, è possibile leggere direttamente nel codice HTML della prima pagina il parametro che viene utilizzato per richiamare il metodo ActionTracking.doGetCaptcha. In più è possibile forzare il salvataggio di lettere arbitrarie, all’interno della sessione, impostando il paramentro text_immagine a piacere.

Il CAPTCHA sopra è un tributo alle parole no-sense utilizzate nella trilogia “Amici miei”.