Presto saranno disponbili su OWASP TV i video della conferenza.

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

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)

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)

www.thepiratebay.org.       28800   IN      A       127.0.0.1

Ieri il dissequestro, la prima volta che accade in Italia a riguardo dei provvedimenti di “censura” di DNS o IP. La relazione tecnica preparata da Matteo Flora e il ricorso preparato da Giovanni Battista Gallus e Francesco Paolo Micozzi è servita a far ritirare il procedimento di sequestro al Tribunale del Riesame.
Il motivo della decisione del Tribunale di Bergamo non si conosce, inutile fare ipotesi per ora.

Aspettiamo per vedere quanto ci vorrà per tornare a questo:

www.thepiratebay.org.   52928   IN      A       83.140.65.11

Il punto secondo me non è di aver difeso ThePirateBay in quanto tale, ma di aver vinto una (piccola) battaglia contro l’attuale gestione del copyright e della censura.

Per chi si fosse perso le fila della vicenda può leggere in questo ordine questo, questo e questo articolo.

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

Il Web sta (ri)scoprendo la pubblicità come forma di guadagno. Il problema non sono le inserzioni pubblicitarie in senso stretto, ma la profilazione che sta dietro ad esse.

La profilazione (Behavioral targeting) si perfeziona sempre più arrivando a proporre prodotti e/o servizi ai quali si è vulnerabili; per i quali si ha un interesse particolare.
Nessuno ha notato i servizi introdotti su YouTube dopo l’acquisizione da parte di Google?

Un anno fa insieme a Matteo Flora abbiamo condotto delle ricerche sulla diffusione, nel panorama blog Italiano, a riguardo di network di inserzioni pubblicitarie e di statistiche sulle visite. I risultati sono stati tutt’altro che confortanti. Google con i suoi AdSense e Analitycs ha una penetrazione intorno al 90% della blogosfera italiana.

Non è strano che Google dopo aver acquistato la Urchin Software ha reso gratuito un software, Urchin poi rinominato Google Analytics, che prima costava centinai di dollari al mese nella versione out-sourced? Per precisione di cronaca va detto che la versione gratuita di Google Analytics non comprende tutte le features di Urchin, per quelle è necessario abbonarsi.

Oltre ad usare plug-in specifici come NoScript, CustomizeGoogle, AdBlock, ecc c’è un metodo più semplice e trasparente per l’utente finale.
Nato da un’idea sviluppata grazie ai dati emersi dal talk, FoolDNS è un servizio di DNS creato per proteggere la privacy e bypassare i filtri censori dello stato Italiano. Un servizio che rende la navigazione più piacevole. Niente più JavaScript (inserzioni pubblicitarie e tool di statistiche) di tutti quei network che collezionano dati di navigazione senza una esplicita dichiarazione. L’idea di fondo è una gestione “casalinga” di inserzioni pubblicitarie e statistiche: perchè doversi accontentare degli spiccioli che network di inserzioni regalano per ogni click e utilizzare prodotti in out-sourcing per le statistiche?!
Grazie all’invito nella beta, dopo una settimana di utilizzo, non ho riscontrato problemi. La navigazione risulta estremamente pulita e piacevole sapendo anche che non vengono caricati JavaScript dalla dubbia utilità.

Il servizio, a detta anche delle statistiche, promette molto bene:
489378 richieste evase negli ultimi 7 giorni, più di 100.000 banner bloccati e più di 200 utenti attivi.

I 10 domini più richiesti sono:

1. mail.google.com
2. www.google.com
3. www.facebook.com
4. twitter.com
5. profile.ak.facebook.com
6. www.test.fool
7. www.google.it
8. feeds.feedburner.com
9. safebrowsing.clients.google.com
10. www.google-analytics.com

Per i più curiosi quelle che seguono sono le url ordinate per maggior numero di banner sostituiti da FoolDNS:

1. http://www.repubblica.it/index.html
2. http://www.repubblica.it
3. http://home.myspace.com/index.cfm
4. http://messaging.myspace.com/index.cfm
5. http://www.libero.it
6. http://www.youtube.com

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

In Spagna si lavora ad un sistema automatizzato per la gestione e la registrazione delle infrazioni stradali e relative multe. A tal scopo sarà utilizzato un database centralizzato in modo da poter smistare e verificare la mole di dati nazionali.
Il sistema sarà basato sul riconoscimento automatico delle targhe inviando così al database tutti i dati delle infrazioni.

L’immagine, presa da Alfredo Reino, è volutamente provocatoria ma quanto così distante dalla realtà?

Non sono l’unico ad aver pensato alle ZTL Italiane ed in particolare all’Ecopass di Milano: “Sql injection sul Gate di Milano?”

Grazie a pollycoke per l’assistenza sugli articoli in lingua spagnola.

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

Ovviamente l’immunità è garantita solamente a chi rispetta la policy:

Guidelines for responsible disclosure

• Share the security issue with us before making it public on message boards, mailing lists, and other forums.
• Allow us reasonable time to respond to the issue before disclosing it publicly.
• Provide full details of the security issue.

Non è tollerato, come è normale aspettarsi, l’uso della vulnerabilità per accedere a dati di cui normalmente non si possiede l’autorizzazione, pretendere una somma di denaro in cambio delle informazioni dettagliate della vulnerabilità o causare un D0S all’intero sistema PayPal.

La policy porta a porsi qualche domanda come evidenziato da Chris Shiflett, ma sicuramente le buone intenzioni ci sono e per migliorare siamo sempre in tempo. Credo che sia la prima volta che una grossa azienda mette nero su bianco un comportamento del genere per incoraggiare chiunque a segnalare preventivamente le vulnerabilità al team di competenza.
Google, Microsoft e Yahoo hanno delle policy simili, ma ancora, al contrario di PayPal, non si fa menzione di possibili rivolti legali per le vulnerabilità segnalate.

Questa notizia non dovrebbe interessare solamente agli addetti ai lavori ma anche ai semplici clienti/utenti, una grossa azienda che gestisce i nostri dati personali (o ancor peggio i nostri risparmi) non deve nascondere eventuali attacchi o vulnerabilità di sicurezza. Solitamente infatti, non solo non esiste una policy ben precisa sul comportamento che l’azienda terrà nei confronti di chi segnala una vulnerabilità ma addirittura non è ben chiaro a chi segnalare i dettagli di essa.

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

Tutto è iniziato a causa dello spostamento di una statua eretta alla fine della seconda Guerra Mondiale in memoria dei soldati dell’Armata rossa caduti nella liberazione dell’Estonia dall’invasione nazista. La repubblica estone perse la propria indipendenza per mano sovietica nel 1939 in seguito del Patto Molotov-Ribbentrop, riguadagnandola solo nel 1991. La rimozione della statua, dettata da una legge del 2006 contro la pubblica esibizione di monumenti rappresentanti l’occupazione sovietica, ha causato l’indignazione della minoranza russa in Estonia e del senato Russo e successivamente un attacco DDoS su larga scala.

L’attacco informatico iniziato il 27 Aprile scorso, ha preso di mira, come spiegato da Hillar Aarelaid del CERT Estone, siti Web di banche, scuole e quello del primo ministro causando non pochi danni all’interno della nazione.
Secondo Jose Nazario, l’attacco DDoS è stato fatto tramite tre diverse tecniche: ICMP floods, TCP SYN floods e floods tramite richieste generiche. Sembra che tra le sorgenti di attacco (presumibilmente una botnet) vi sia oltre a Brasile, Canada, U.S. e Vietnam anche la Russia.
In un primo momento era stato puntanto il dito contro il governo Russo, ma più approfondite analisi hanno portato a pensare che vi fossero “semplici” cittadini (nazionalisti) dietro gli attacchi. Fatto sta che il CERT Estone riceverà l’aiuto niente meno che dalla NATO (North Atlantic Treaty Organization, tengo a sottolineare). Lo scopo dell’organizzazione internazionale, nata da una temuta invasione sovietica dell’Europa occidentale, è riassunto in maniera esaustiva nell’articolo 5 del Trattato Atlantico:

Le parti convengono che un attacco armato contro una o più di esse in Europa o nell’America settentrionale sarà considerato come un attacco diretto contro tutte le parti, e di conseguenza convengono che se un tale attacco si producesse, ciascuna di esse, nell’esercizio del diritto di legittima difesa, individuale o collettiva, riconosciuto dall’ari. 51 dello Statuto delle Nazioni Unite, assisterà la parte o le parti così attaccate intraprendendo immediatamente, individualmente e di concerto con le altre parti, l’azione che giudicherà necessaria, ivi compreso l’uso della forza armata, per ristabilire e mantenere la sicurezza nella regione dell’Atlantico settentrionale. Ogni attacco armato di questo genere e tutte le misure prese in conseguenza di esso saranno immediatamente portate a conoscenza del Consiglio di Sicurezza. Queste misure termineranno allorché il Consiglio di Sicurezza avrà preso le misure necessarie per ristabilire e mantenere la pace e la sicurezza internazionali.

Siamo di fronte ad un pezzo di storia?

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

HttpOnly Cookie è stato implementato per la prima volta in IE 6 sp1, da pochi giorni è stato integrato di default anche nella terza beta di Firefox 3.

HttpOnly è ancora una tecnologia poco utilizzata: è stata implementata ufficialmente su PHP dalla versione 5.2 Ci sono però dei workaround per utilizzarla anche sulle versioni precedenti.

Per chi volesse provare HttpOnly su Firefox 2 può usare l’estensione “httpOnly” scritta da Stefan Esser. L’estensione non segue la vera implementazione usata da Microsoft: tutti i cookie in arrivo, contrassegnati dal flag HttpOnly vengono criptati con AES tramite un hook di Firefox. Un altro hook decripta i cookie solo quando vengono inviati tramite HTTP, in questo modo i cookie ottenuti tramite JavaScript saranno inutilizzabili perché criptati.

Segnalo inoltre, che da poche ore sono stati rilasciati Firefox 2.0.3 e Firefox 1.5.0.11 che correggono alcuni bug di sicurezza venuti alla ribalta negli scorsi giorni.

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