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.

 

Cookie, HTTP e HTTPS

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.

 

Tumblr worm, quando i blog diventano virali

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

 

Top Ten Web Hacks 2007, grazie!

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

 

L’equo compenso dei Phisher

Custom PHP scam scriptPremetto 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:

Double mail function

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.