Tumblr worm, quando i blog diventano virali

Probabilmente molti avranno già letto l’alrticolo, Così nasce un worm internet pubblicato ieri  su Punto Informatico.
Eviterò quindi di fare una introduzione all’argomento passando invece subito alla parte più tecnica che non ha potuto trovare spazio su PI.

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

Tumblr worm workflow

  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.

Creative Commons License “Oruga cerebral” photo credit: Gustavo Olivera

 

Un Commento a 'Tumblr worm, quando i blog diventano virali'

Segui i commenti sottoscrivendo il feed RSS oppure TrackBack a 'Tumblr worm, quando i blog diventano virali'.

  1. Complimenti, sia per la vulnerabilità, sia (e sopprattutto) per la spiegazione, molto chiara e concisa… ;)

    Stefano

:: Trackbacks/Pingbacks ::

Nessun Trackbacks/Pingbacks

Lascia un Commento