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

© Matteo Carli - Creative Commons 2.5 (by-nc-sa)

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.

© Matteo Carli - Creative Commons 2.5 (by-nc-sa)

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:

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.

© Matteo Carli - Creative Commons 2.5 (by-nc-sa)

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.

© Matteo Carli - Creative Commons 2.5 (by-nc-sa)

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

© Matteo Carli - Creative Commons 2.5 (by-nc-sa)

Alcuni passi dell’articolo risultano essere interessanti:

In the case of the fighter-jet program, the intruders were able to copy and siphon off several terabytes of data related to design and electronics systems, officials say, potentially making it easier to defend against the craft.

e poi:

Computer systems involved with the program appear to have been infiltrated at least as far back as 2007

Un accesso continuato con un furto di TB di dati sembra essere un qualcosa di premeditato e con un discreto interesse alle spalle. Non credo possibile l’ipotesi di un attacco “casuale”.
Difficile e forse inutile stabilire la vera sorgente dell’attacco; c’è chi parla già del ritorno della guerra fredda.

Da “I signori della truffa”:

C’è una guerra là fuori, amico mio. Una guerra mondiale. E non ha la minima importanza chi ha più pallottole, ha importanza chi controlla le informazioni. Ciò che si vede, si sente, come lavoriamo, cosa pensiamo, si basa tutto sull’informazione!

© Matteo Carli - Creative Commons 2.5 (by-nc-sa)

1. semplicità di exploiting (cross-browser)
2. scarsa awareness della vittima (nessuna interazione richiesta oltre all’apertura della mail stessa)
3. diffusione sul web (ampia diffusione della piattaforma vulnerabile e possibilità di propagazione virale)

Sia chiaro, nessuna novità nella categoria delle vulnerabilità delle Web Application, ma una dimostrazione di come l’insieme di alcune di queste può portare ad uno dei più gravi problemi mai registrati on-the-wild su Web Application. I bug scoperti sono adatti per sfruttati da quello che potrebbe essere uno dei più grandi e gravi Worm delle Web Application: numero di domini Internet coinvolti maggiore di 10 (cross-domain) e semplicità di propagazione.

Prima di scendere nei dettagli del funzionamento dell’attacco è doveroso precisare che il problema è stato corretto a tempo di record dal vendor che si è dimostrato attento alla sicurezza dei propri clienti.

Le WebMail interessate dalle vulnerabilità sono quelle basate sul framework di messaggistica “Memova” sviluppato da Critical Path. Si tratta di una soluzione per la gestione della posta elettronica enormemente diffusa sul Web .

Giusto per riportarne qualcuno:

• Tiscali IT/UK/NL
• Wind
• Telecom
• Vodafone
• Swisscom
• Telefonica
• Virgin
• Sonera
• Terra.es
• Telia
• T-Mobile
• FastwebNet
• Ono
• Regione Puglia
• Regione Sicilia
• Diversi domini gov.uk

Si tratta di ISP diffusi in Europa con una enorme base di utenti.
Ovviamente su ciascuna installazione, la soluzione Memova è stata opportunamente personalizzata, sia nel look che nelle funzionalità per venire incontro alle necessità del cliente, ma le caratteristiche di base sono comuni e, purtroppo, comuni sono anche le vulnerabilità.

Il grafico che segue riassume la vita dell’attacco che può essere portato a termine grazie alle vulnerabilità scoperte:

1. L’attaccante invia una e-mail preparata ad arte alla casella e-mail della vittima
2. La vittima legge l’e-mail e in maniera trasparente viene impostato l’inoltro automatico di tutte le e-mail in ingresso
3. Conoscenti, colleghi ed amici della vittima scrivono e-mail alla vittima stessa
4. Tutte le e-mail in ingresso nella casella della vittima vengono inoltrate all’attaccante in maniera trasparente.

L’impostazione dell’inoltro automatico è solitamente disponibile all’utente sotto le voci “Impostazioni” o “Opzioni” della WebMail. Questa opzioni non viene tuttavia consultata e modificata di frequente, per cui un’eventuale modifica di queste configurazioni passerebbe verosimilmente inosservata per parecchio tempo.
In alcune Webmail, interessate dalle vulnerabilità, non viene concessa all’utente finale la possibilità di impostare l’inoltro automatico tramite il menù delle opzioni; in tale scenario è praticamente impossibile per la vittima disabilitare le opzioni di inoltro, impostata grazie alle vulnerabilità scoperte, senza il supporto dell’assistenza tecnica dell’ISP.

Per il Proof of Concept delle vulnerabilità sono state analizzate le tre più popolari WebMail italiane (almeno in termini di account registrati) che tra l’altro fanno uso tutte e tre del framework Memova:

• Tiscali
• Libero (Wind)
• Virgilio (Telecom)

Tramite l’invio di una mail contenente un unico vettore di attacco è possibile infettare gli account di tutte e tre le WebMail, impostando le opzioni di inoltro automatico verso un account di posta elettronica controllato dalla vittima. Nonostante il PoC sia stato testato solo sulle 3 WebMail sopra descritte, è verosimile attendersi che anche nelle installazioni presso altri clienti, il software di filtering di Memova sia vulnerabile a questo XSS.

Per l’invio della mail l’attacker ha la necessità di creare un testo ad-hoc in modo da sfruttare le vulnerabilità presente sui filtri di validazione dell’input presenti nelle WebMail coinvolte. Il vettore riportato sopra è studiato ad hoc per evadere i filtri anti XSS di tutte le WebMail testate, sia nella loro vecchia versione, sia nella loro nuova versione 2.0 (basata su tecnologia Ajax). All’apertura della mail, il vettore inviato viene posizionato nel codice HTML di un iframe preposto alla visualizzazione del testo di ciascuna e-mail.
Il codice del vettore richiama un file JavaScript ospitato su un server Web in possesso all’attaccante che viene eseguito nel contesto dell’iframe (es: mioisp.it )
In alcune delle implementazioni testate esiste un meccanismo di “protezione2 per limitare i danni provocati da XSS abbinati a CSRF: il dominio dell’iframe in cui viene letta la mail (e quindi eseguito il JavaScript) è differente dal dominio della WebMail (es. mail.mioisp.it).
Esiste tuttavia un meccanismo per aggirare queste limitazioni:

• occorre individuare un secondo XSS sullo stesso dominio della WebMail (es. mail.mioisp.it) e senza la presenza del token di sessione (che non abbiamo ancora a disposizione)
• tale XSS (di tipo reflected) viene richiamato come source di un iframe creato all’interno del frame di lettura della mail
• il Reflected XSS può avere accesso alla document.location della WebMail (steso dominio), riuscendo così a recuperare il token di sessione
• Il reflected XSS può a sua volta lanciare attacchi CSRF verso pagine del dominio “mail.mioisp.it” riuscendo così a modificare i settagli dell’inoltro automatico

Svincolato dalle restrizioni della Same Origin Policy, ed in possesso del token di sessione il codice del reflected XSS può effettuare chiamate XmlHttp verso qualunque risorsa presente sul dominio “mail.mioisp.it”.
In particolare la URL da chiamare per impostare il forward automatico delle mail in arrivo è:

• POST /cp/ps/Mail/preferences/SetForward

Questa pagina è sempre disponibile sulle installazioni testate di Memova, anche in quelle in cui l’opzione di inoltro automatico non è disponibile per gli utenti finali della WebMail.

Come già ipotizzato qualche riga sopra, in una ottica teorica, ma praticamente realizzabile e funzionante, potrebbe essere creato un “worm” che sfruttando le vulnerabilità riportate sia in grado di auto replicarsi leggendo la rubrica o i mittenti e-mail presenti nella “inbox” della vittima. In questo modo si creerebbe un effetto a catena che comprometterebbe milioni di caselle e-mail interessate dalle vulnerabilità.
Avendo, inoltre,il controllo completo della casella e-mail della vittima sarebbe possibile effettuare il furto d’identità scrivendo e-mail a nome della vittima senza fare lo spoofing degli header.

Sulla base di una scelta “etica” e per rispetto nei confronti di tutte le parti coinvolte (la privacy degli utenti da una parte, il rispetto del lavoro di professionisti dall’altra) il codice sorgente e le specifiche tecniche alla base del PoC non verranno divulgate.

E’ disponibile un video dimostrativo (le notizie che si vedono a 2 minuti e 24 secondi evidenziano la data di registrazione) di quanto fin ora descritto e una advisory dettagliata del problema.

Rosario Valotta
Matteo Carli

© Matteo Carli - Creative Commons 2.5 (by-nc-sa)

Il futuro di LLOOGG è così arrivato a un bivio come spiega ‘antirez’ sul suo blog:

Siamo ad un bivio: dovremmo chiuderlo o trovare un modello alternativo, ma l’idea di una chiusura non ci piace perché’ io e Fabio siamo i primi utenti di LLOOGG, perché’ dovremmo fare a meno di questo servizio?
La soluzione e’ quella di far diventare il servizio a pagamento.

La scelta fatta è quella di mantenere un tipo di account gratuito limitato nelle pageviews e nelle features e al contempo attivarne uno nuovo a pagamento per avere tutte le features complete.

Reputo il servizio molto comodo e assolutamente complementare a Google Analytics e simili. I filtri introdotti da poco poi, sono veramente comodi per tracciare le visite su pagine appena pubblicate e la distribuzione dei visitatori con pattern specifici.

Il tutto dovrebbe tornare online prima delle 48h. Tutti gli aggiornamenti sull’account Twitter di LLOOGG.

© Matteo Carli - Creative Commons 2.5 (by-nc-sa)

Fino ad ora però la tecnica utilizzata per ogni target era sempre differente. CSRF per i router, modifica del file hosts o del registro di Windows e della modifica delle impostazioni di sistema per i Mac. Adesso è stata escogitata un nuovo modo completamente cross-platform utilizzando il protocollo DHCP. Infatti un nuovo malware segnalato da Symantec e ISC, una volta installato su un sistema Windows, manda in esecuzione, sulla medesima macchina, un server DHCP non legittimo (detto anche rogue DHCP) che di fatto si contrappone a quello già esistente, praticamente,  in tutte le LAN domestiche e aziendali. Di fatto questa cosa consente al “rogue DHCP” di far credere ai client che i server DNS da utilizzare siano quelli in possesso degli attaccanti. ISC a tal proposito segnala che i DNS utilizzati da questo ultimo attacco si trovano tra 85.255.112.0 e 85.255.127.255.

L’idea, sicuramente non nuova, ma mai utilizzata da un malware, sfrutta il fatto che il protocollo DHCP non prevede nessun metodo per verificare se la risposta arriva dal server DHCP legittimo o meno. Le richieste dei client girano sulla rete Ethernet in broadcast. In questo modo qualsiasi server DHCP presente sul dominio di broadcast sarà in grado di rispondere. Il primo, in ordine di tempo, che risponderà alle richieste dei client, sarà quello che verrà preso in considerazione.

Dopo questa premessa vorrei passare ai tool che risultano essere utili per scoprire “rogue DHCP” sulla LAN:

TIME: 2008-12-06 15:17:50.200
IP: 192.168.0.1 (XX:XX:XX:XX:XX:XX) > 255.255.255.255 (ff:ff:ff:ff:ff:ff)
OP: 2 (BOOTPREPLY)
HTYPE: 1 (Ethernet)
HLEN: 6
HOPS: 0
XID: a6e51638
SECS: 0
FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 192.168.0.101
SIADDR: 0.0.0.0
GIADDR: 0.0.0.0
CHADDR: YY:YY:YY:YY:YY:YY:00:00:00:00:00:00:00:00:00:00
SNAME: .
FNAME: .
OPTION:  53 (  1) DHCP message type         5 (DHCPACK)
OPTION:  54 (  4) Server identifier         192.168.0.1
OPTION:  51 (  4) IP address leasetime      86400 (24h)
OPTION:   1 (  4) Subnet mask               255.255.255.0
OPTION:   3 (  4) Routers                   192.168.0.1
OPTION:   6 ( 12) DNS server                85.37.17.55,85.38.28.93
OPTION:  15 ( 22) Domainname                domain_not_set.invalid

(Sono stati sostituiti i mac del server con XX:XX:XX:XX:XX:XX e quello del client con YY:YY:YY:YY:YY:YY)

Questo è un esempio di un DHCPACK mandato da un server DHCP dopo le richieste del client. Come si può notare il server DHCP comunica Gateway e DNS.

Ho trovato alcuni tool interessanti per monitorare richieste e risposte DHCP su una LAN:

• DHCPloc (resurceKit di Windows)
  
• DHCPdump (disponibile nei repository della maggiori distribuzioni Linux)

Dove gli antivirus non arrivano, con qualche riga di script non è difficile gestire gli alert in caso siano rilevati server DHCP non legittimi.

© Matteo Carli - Creative Commons 2.5 (by-nc-sa)

Difficile non aver sentito parlare di Social network negli ultimi tempi. Perfino telegiornali e quotidiani ne stanno parlando. Il fenomeno Facebook è esploso: oltre 100 milioni di iscritti totali e circa due milioni e mezzo italiani. Tra i numeri bisogna intravedere anche account doppioni o abbandonati, ma restano comunque numeri di tutto riguardo. Bello rimanere in contatto con gli amici, sempre, in ogni momento. Bello poter contattare amici ora lontani con un solo click.

Un dipendente di una compagnia telefonica Australiana di 21 anni chiama in ufficio per annunciare la sua indisposizione non prima di aver scritto sul proprio profilo di Facebook: “Kyle Doyle is not going to work, fuc* it i’m still trashed. SICKIE WOO!” (ndr. Kyle Doylenon andrà al lavoro… Sono ancora devastato. VIVA LA MALATTIA!”). Per sua sfortuna, il suo capo letta la frase dal feed dei contatti di Facebook, non ha fatto altro che chiedergli il certificato per giustificare l’assenza. Ammesso che sia una bufala è così lontano da essere reale?

Andrea Feick e Hannah Emerson, due studentesse sconosciute ma con la passione per Facebook, lo scorso mese, sono state in compagnia di Bono degli U2 in Costa Azzurra. Le due ragazze, aspiranti modelle, hanno inserito le foto della gita su Facebook: dopo il Nikki Beach Bar la compagnia si è spostata sul “Cyan”, lo yacht da 12 milioni di sterline di proprietà del chitarrista degli U2, The Edge per finire all’Oxybar di Saint Tropez. Il tutto per vantarsene con la piccola cerchia di amici, se non era per l’iscrizione di Andrea Feick al gruppo geografico di New York. Circa un milione di persone che possono accedere al suo profilo e alle sue fotografie. Non credo che la moglie di Bono sia così entusiasta delle fotografie viste sul Daily Mail.

Sicuri del numero di amici che avete e di chi siano realmente?
Per non parlare poi delle vulnerabilità dell’applicazione del social network stesso.

© Matteo Carli - Creative Commons 2.5 (by-nc-sa)