I Worm internet sono sempre più diffusi, anche e soprattutto in virtù della sempre maggiore permeazione delle applicazioni Web Based nella vita quotidiana e alla sempre maggiore quantità di vulnerabilità che in esse si ritrovano ad intervalli regolari.
Mentre siamo ormai abituati alla nozione di XSS e quindi di alterazione del contenuto delle pagine in base all’alterazione delle richieste in GET e PUT, non tutti i meccanismi alla base della moderna arte del Web Application Hacking sono così diffuse nel mondo degli utenti e, soprattutto, in quello dei programmatori che dovrebbero difendersi adeguatamente.
A farne le spese, questa volta, il team di sviluppo di Tumblr, in noto portale e servizio di MicroBloggin e l’attaccante un giovane amico italiano, Matteo Carli , con cui ho lavorato in passato sia nella festa dell’ XSS di Libero sia in una conferenza sulla permeazione di Google e WordPress nel web.
Matteo ha rilasciato un advisory contenente una POC di un Worm in grado di infettare un utente Tumblr e in cascata tutti gli altri utenti Tumbler che capitino casualmente sul sito del primo. E considerando che secondo Google vi sono oltre 110.000 sottodomini che utilizzano i servizi di Tumblr (il servizio è erogato con domini del tipo utente.tumblr.com) il problema è tutt’altro che da poco.
Occorre specificare che d’accordo con Matteo Carli abbiamo deciso di pubblicare questo articolo solamente dopo che Tumblr avesse provveduto a tappare la falla in questione ed ora che il problema è rientrato ritengo sia estremamente interessante analizzare un po’ più approfonditamente il funzionamento di questo interessante pezzo di codice.
Come in ogni analisi che si rispetti partiamo dal Codice Sorgente:
Per chi si trovasse un poco arrugginito sul concetto di CSRF , che Jeremiah Grossman definisce “Il Gigante Dormente” della Web Application Security, si tratta di un meccanismo che sfrutta la sessione mantenuta aperta in determinati siti web per effettuare azioni tramite, normalmente, iframe e tag vari iniettati nel codice.
Poniamo, per esempio, che la Banca di Paperopoli mantenga la sessione basata esclusivamente su Cookie e che io mi autentichi per controllare il mio saldo e decida poi di cambiare sito web senza premere il pulsante di LogOut. A questo punto le mie credenziali “permangono” all’interno di un cookie e un terzo sito malicious potrebbe inserirmi codice come il seguente:
img src=”http://banca.diPaperopoli.pa/faibonifico?conto=bob&somma=1000000&destinatario=LK”
In questo caso sempre che la richiesta sia impostata correttamente potrei riuscire a fare eseguire una “azione”, in questo caso un ipotetico bonifico, al sistema facendo sì che l’utente sia completamente ignaro di quanto accaduto.
Premetto, ad uso e consumo della nutrita schiera di Troll che mi segue assiduamente su Punto Informatico , che l’esempio non è calzante nella vita reale, poiché le banche utilizzano sistemi di altri tipo per lo storing delle credenziali e richiedono, per operazioni dispositive, un secondo codice di autorizzazione.
Ma per le necessità del nostro articolo attuale l’esempio è perfetto.
Ritorniamo al nostro codice e probabilmente capiremo il motivo per la presenza di un IFrame: in questo, infatti, risiede il form che automaticamente pubblica sull’account Tumblr dell’ignaro esecutore un nuovo “post” contenente il worm stesso. Già, poiché Tumbrl non controlla l’effettiva provenienza della richiesta ed è quindi prono, come la banca dell’esempio, ad essere vulnerabile ad un attacco CSRF come quello di Matteo Carli .
Il meccanismo può essere riassunto nel seguente schema:
Seguiamolo passo a passo:
– Il Worm richiede che l’utente si sia loggato precedentemente a Tumblr, cosa che un assiduo user del servizio fa per una decina di volte al giorno
– L’utente si connette ad un sito “malvagio”, cioè ospitante il codice del Worm. Potrebbe anche essere, come vedremo in seguito, il Tumblr di un amico
– L’utente riceve ed esegue il codice malevolo che, all’insaputa dell’utente stesso
-…si connette tramite il form contenuto alla DashBoard di Tumbler e…
-…pubblica un nuovo post contenente il Worm stesso.
E da qui? Da qui basta che qualunque altro utente Tumblr “legga” il post incriminato per far sì che si rientri nel punto 0 e da lì, in modo totalmente automatico, il worm si diffonda senza alcun intervento umano.
E le soluzioni?
Il team di sviluppo del noto portale ha deciso di procedere con le seguenti misure:
– Limitare le connessioni di provenienza a quelle che seguono lo schema “www.tumblr.com/new/*”
– Aggiunta di un field nel form con un token legato alla sessione
Io e Matteo siamo concordi nel sostenere che nonostante queste due accortezze vi sia ancora spazio con un poco di creatività e un poco di tempo per sperimentare per riuscire a bypassare anche queste due misure di sicurezza, certo non con un codice così semplice e cristallino come quello proposto.
Ma per ora si continua a sperare che i programmatori si ingegnino nel constatare che la Web Application Security non è solamente appannaggio di poveri paranoici come il sottoscritto, Matteo e una serie di altri indomiti fautori del testing web, ma una necessaria componente della propria educazione di programmazione, una obbligata tappa nella loro formazione ed un paradigma da tenere costantemente di fronte nel realizzare programmi che utilizzino il Web come Piattaforma.
Matteo Flora
LastKnight.com
I precedenti interventi di M.F. sono disponibili a questo indirizzo
Ti potrebbe interessare
31 mar 2008