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.

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

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.