Top Ten Web Hacks of 2007, la classifica degli “hacks” più interessanti, nel campo della Web Application Security, presentati durante l’anno passato.

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?!

Premetto subito che la notizia non è nuova, credo però, che sia degna di nota.

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.

Tramite Jeremiah Grossman leggo che PayPal ha pubblicato una pagina contene la “vulnerability disclosure policy“. Essa permette ai (Web application) security researchers di segnalare vulnerabilità trovate in PayPal senza rischiare azioni legali.

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.

Chi era presente all’ESC durante la presentazione di “GoogleTistic e WordpressTistic: le statistiche che nessuno avrebbe mai voluto mostrarvi” sicuramente si ricorderà come le installazioni di WordPress nella blogosfera italiana non siano sicure e ancor meno aggiornate a versioni recenti.
Ovvio che il problema non è solo sulla blogosfera italiana, ma su quella mondiale.

Può capitare, anche se non dovrebbe, che utenti non troppo esperti non aggiornino la propria piattaforma per paura che un plug-in o l’intero blog smetta di funzionare. Nessuna scusante è data però agli addetti ai lavori.
Anche se esiste il detto “Il calzolaio ha le scarpe rotte” chi si occupa di Web a tempo pieno o ancor peggio di sicurezza non si può permettere la compromissione della propria piattaforma.

Vedere blog di sicurezza informatica con versioni di WordPress di un anno fa non è una bella sensazione, figuriamoci a vederli compromessi: la scorsa settimana LightBlueTouchpaper, noto blog del Security Group dell’Università di Cambridge, ha ammesso senza troppi problemi che:

Regular readers may have noticed that Light Blue Touchpaper was down most of today. This was due to the blog being compromised through several Wordpress vulnerabilities.

Ieri è successa una cosa simile, annunciata da tempo da LHM (si vedano i commenti nel suo tool per antiblogging): il blog di SecuriTeam è stato compromesso.

Sono stati inseriti link che portano ad un blog (WordPress 2.0.2), ospitato su un sottodominio dell’Università del Michigan, il quale a sua volta è stato compromesso ed usato per ospitare pagine che effettuano redirect verso domini di casinò on-line. Per eludere li spider che passeranno da quelle pagine è stato inserito un testo con alcune keywords e il redirect viene fatto con del codice JS offuscato.

E’ troppo facile gestire un blog pensando solo a scrivere e tralasciando la sua sicurezza in quanto, presunta, roba da ragazzini (in tutti questi casi si tratta di vulnerabilità conosciute e risolte).
Dal punto di vista degli sviluppatori non sarebbe il caso di pensare a rilasci meno frettolosi e a maggiore testing di WordPress visto il bacino di utenza che ha?
Ad ognuno le proprie conclusioni.

E’ passato ormai un mese dall’annuncio della versione 2.3 di WordPress. Essa porta con se miglioramenti e bug fix.
Sembrava un momento di svolta per questo software: nessun bug segnalato dal rilascio della versione 2.2.3 avvenuto l’8 Settembre scorso.

Sicuramente il codice è migliorato molto, i problemi di sicurezza più grossi sono stati risolti (forse) ma non penso che siamo giunti alla perfezione; ciò è dimostrato anche dalla segnalazione fatta da un utente sul forum di supporto di WordPress: da un giorno ad un altro si è visto riempire il proprio blogroll con link a domini di spammer.

Ho seguito la vicenda dal nascere, all’inizio pensavo ad una compromissione della macchina dell’utente che ha fatto la segnalazione, ma poi ho visto un bug report sul Trac di Wordpress intitolato “Link manager exploit?” la cosa ancora più interessante è che il Trac riporta “Opened 3 months ago”. Non male direi!
Sostanzialmente il problema risiede nella pagina wp-admin/link.php delle versioni 2.0, 2.1, 2.2 e 2.3. Questo file riceve le richieste di amministrazione del blogroll senza però verificare i permessi dell’utente che le invia. In questo modo qualsiasi persona che possiede un account su un blog costruito con WordPress dalla versione 2.0.12 in poi può deliberatamente aggiungere, togliere e modificare link dal blogroll.

E’ stata rilasciata una nuova versione di link.php per WordPress 2.3, per tutti gli altri esiste una patch che consiste nell’agiungere dopo la funzione wp_reset_vars(), del file wp-admin/link.php questo codice:

if ( ! current_user_can(’manage_links’) )
wp_die( __(’You do not have sufficient permissions to edit the links for this blog.’) );

Anche se il problema sembra risolto, alcuni utenti segnalano che il fix non funziona. Sarà necessario tenere sott’occhio il thread del forum e il Trac 4627 nei prossimi giorni.

Sinceramente mi rende un po perplesso il fatto che dopo 3 mesi solo nell’ultima settimana il response team di WordPress si stia occupando di questo bug. Mi sembra una svista piuttosto grave e ancor più grave è l’inesistenza di un bollettino di sicurezza ufficiale con patch o nuova versione annessa.

Aggiornamento: il problema non risiede sul file wp-admin/link.php. Esso non effettua nessun controllo dei permessi dell’utente durante la gestione del bloroll perchè questo viene effettuato direttamente dalla funzione edit_link() e da add_link() che è un alias della prima.
A questo punto è necessario capire cosa può aver aiutato gli spammer ad inserire i link nei blogroll di ignari blogger.