Nuovo attacco: Clickjacking

[riazzituoi]

.

[riazzituoi]

.

[c.m.g]

ripreso da punto informatico:

http://punto-informatico.it/2419482/...lnerabili.aspx

e webnews:

http://www.webnews.it/news/leggi/922...cking-sul-web/

[riazzituoi]

.

[Ignorante Informatico]

Originariamente inviato da riazzituoi

Novità by Giorgio Maone (sviluppatore di NoScript)..

Merita tutti i consensi che ha ed ogni donazione effettuata a suo favore.

Buon NoScript a Tutti

[Sisupoika]

Nuovo?

Che questa possibilita' sia venuta fuori adesso con un certo rilievo pubblico, non necessariamente vuol dire che sia nuova.

Con tutto il rispetto per i mitici Hansen and Grossman, non vi ricordate quando parlavo di possibilita' di dirottare clicks di un utente anche senza
javascript? Quando in uno dei miei test avevo detto che si poteva dirottare l'azione di un utente anche con Noscript in Firefox?

Certamente i piu' assidui ricorderanno.

Mi auto-quoto questo mio post del 24 settembre 2007:

[...]un link si puo' manipolare in mille modi, non solo agendo sull'href: puoi usare l'oggetto location, puoi sostituire l'elemento A nel DOM con un altro, sovrapporre un link ad un altro con CSS, sfruttare la priorita' dell'evento onclick coi parent, far si' che al click l'href rimanga lo stesso - inalterato - e che il click annulli quel link, per invocare il click su un altro link aggiunto dinamicamente alla pagina all'onload ecc ecc ecc. Non si tratta solo di href[...]

Adesso hanno dato un nome, "Clickjacking", ma questa classe di possibilita' non e' proprio nuova.
Lo stesso discorso dell'iframe, well, NON e' indispensabile un iframe per azioni di questo tipo; con i css si puo' fare di piu', come diceva Morandi o chi era

Di certo questa possibilita' ha un significato notevole, soprattutto perche' non e' affatto complicata. Comunque devo ammettere che e' stata una sorpresa per me apprendere di questi nuovi "risvolti" sulla cosa perche' per quanto mi riguarda era piu' o meno finita nel dimenticatoio.
Negli ultimi mesi infatti ho messo appunto una piccola libreria Javascript con cui posso accedere alle proprieta' di un documento, iniettare codice, manipolare il DOM, fare praticamente di tutto, da un altro dominio
L'ho accennato in un altro thread mi pare la settimana scorsa e sto risolvendo un paio di problemi, ma la cosa funziona e NESSUN browser al momento da "access denied" o simili. Appena finisco le prove e risolvo un paio di cose postero' qui su HU un esempio (forse entro la settimana prossima se ho tempo).
La tecnica di cui sto parlando ora necessita di Javascript in questo caso, ma e' potenzialmente tutt'altro che da trascurare perche' posso fare di un documento proveniente da un altro dominio cio' che voglio.
Un esempio - che ho mostrato al mio manager la settimana scorsa - e che e' appunto soltanto un esempio della miriade di possibili applicazioni, e' il furto di cookies da innumerevoli siti attraverso semplici ads.
L'esempio che ho mostrato a lui (qui mostrero' una cosa simile ma non posso mostrare gli stessi siti che ho usato per la prova pubblicamente, anche perche' voglio lasciare qualcosa per un blog che forse apro a breve), ho simulato un network di advertising (immaginate Google Adwords) che si poggia a del codice Javascript per l'inclusione dinamica di ads nelle pagine dei publishers/affiliates. Nell'esempio, questi ads vengono aggiunti dinamicamente alla pagina dell'affiliato all'interno di un iframe dinamicamente iniettato nel DOM. Teoricamente, qualunque codice ci sia in quel iframe non potrebbe accedere alle proprieta' o altro della pagina che lo contiene (quella del publisher/affiliato), poiche' i domini sono diversi (immaginate, per puro esempio di fantasia, che l'iframe con gli ads provenga da "google.com" e il dominio del publisher sia "miosito.com").
Con la mia libreria, posso iniettare nella pagina del publisher del codice che di nascosto grabba i cookies appartenenti al sito del publisher ma anche eventuali cookies non adeguatamente protetti (dove per adeguatamente protetti intendo: con un adeguato secure cookie protocol) di altri siti che l'user del sito del publisher ha visitato. Questi cookies poi vengono di nascosto trasferiti attraverso JSON nella pagina nell'iframe che li manda via email, pronti per replays

In realta' quando ho parlato di "esempio di fantasia" parlando di Google , non e' proprio fantasia: provate ad immaginare quante informazioni riservate Google (e compagnia) potrebbe raccogliere di nascosto attraverso il network di Adsense, per esempio.
Cmq spieghero' qualche dettaglio in piu' non appena ho tempo.

[Sisupoika]

***

[Sisupoika]

Non so se qualcuno aveva gia' letto quello che avevo scritto nel post precedente, in caso affermativo: ho dovuto editare perche' devo verificare delle cose.

Tornando in topic, voglio fare una precisazione che stranamente non e' stata discussa adeguatamente, e sinceramente me ne chiedo il perche'

Come dicevo e ripeto ancora una volta, questi giochetti sono tutt'altro che nuovi, chi e' nel settore li conosce da tempo cosi' come sa che ci sono ben piu' di uno o due modi per effettuare attacchi di questo tipo con e senza Javascript, e che ci sono applicazioni che vanno oltre al dirottamento del link.

Noscript puo' essere una buona difesa se si disattivano i frames, ma questo si aggiunge alla lunga lista delle ragioni per cui Noscript non mi e' mai piaciuto.
Noscript non e' una soluzione, ma soltanto una "pezza" (con tutto il rispetto per il suo autore) che tappa dei buchi rendendo molta parte del web inusabile. Il web va avanti per funzionalita' ecc., ma con Noscript si ritorna indietro di anni.
Bisogna trovare altre soluzioni che siano degne di tale nome e che siano alla portata di tutti, non soltanto di chi usa Firefox e sa cosa e' una estensione.

Ho in mente un programmino che puo' risolvere il problema della tecnica di clickjacking (come e' stata definita adesso - prima non aveva mai avuto un vero e proprio nome) almeno nelle piu' probabili e preoccupanti varianti, senza dover costringere l'utente ad utilizzare Firefox, e pur lasciando Javascript abilitato. L'usabilita' non verrebbe in questo modo compromessa e si potrebbe utilizzare qualunque browser si desidera, non necessariamente Firefox con Noscript. Cmq per adesso ho una idea, e sono abbastanza sicuro che potrei metterla in atto in pochi giorni - se riesco ad averne il tempo. Vi faro' sapere cmq. Il motivo per cui ho interesse in questa cosa e' che adesso e' abbastanza nota, e non e' (fidatevi) una cosa facile da risolvere, e dubito che nelle prossime versioni dei maggiori browser vi sara' gia' una soluzione definitiva al problema, vista il grande ventaglio di possibilita' di questa minaccia.

Cmq, tornando alla "precisazione": vi suonera' strano e a tratti divertente
Ma, credetemi: Internet Explorer e' al momento piu' sicuro degli altri browser contro molte varianti di clickjacking

Non sto scherzando!!!
La ragione sta nella implementazione che Microsoft ha fatto in IE6 e successivi della P3P, che sta per "Platform for Privacy Preferences".
Rimando all'articolo su Wikipedia per qualche dettaglio in piu'
http://en.wikipedia.org/wiki/P3P, quindi inutile ripetere qui perche' penso non sia complicato capire di che si tratta.

Dunque, la domanda spontanea, immagino, e': perche' IE sarebbe piu' sicuro in caso di clickjacking?

Risposta: L'implementazione di IE6 e successivi della P3P fa si che by default un sito non puo' accedere ai suoi stessi cookies eventualmente gia' salvati dallo stesso, se quel sito viene eseguito in un iframe.

Esempio: esegui la tua webmail (say Gmail, for instance), ti autentichi e spunti la casella che permette alla applicazione web di "ricordare" il tuo login per un certo tempo, in modo che tu non debba autenticarti ogni volta.
Questo viene ovviamente fatto attraverso i cookies.

Cosa accade, a questo punto (utente gia' loggato al servizio - Gmail nell'esempio), se l'utente apre una pagina maligna che nasconde in un iframe invisibile una pagina di Gmail, con lo scopo di far compiere all'utente qualche azione sul suo account Gmail, senza saperlo?

Provate ad immaginare che la pagina maligna carichi in un iframe nascosto una pagina di Gmail con URL preparato adeguatamente cosi' che l'utente - senza saperlo - aggiunga un filtro per fare forward di tutta la sua posta, ad un altro indirizzo email. Senza saperlo.

1) Firefox, Safari, Opera, ecc: in condizioni normali - pensiamo dunque alla stragrande maggioranza di persone che usa un browser cosi' com'e', l'attacco avrebbe successo. La pagina di Gmail verrebbe caricata nell'iframe nascosto, e poiche' l'utente e' gia' loggato in Gmail, esso verrebbe indotto a compiere un'azione indesiderata, senza saperlo, attraverso il dirottamento del suo click su un pulsante, con clickjacking.

2) Internet Explorer: il click dell'utente verrebbe dirottato, ma nulla accadrebbe all'account Gmail dell'ignaro utente. Questo perche' IE negherebbe alla pagina Gmail eseguita nell'iframe inserito nella pagina maligna, l'accesso ai cookies salvati dalla stessa applicazione Gmail, anche se il dominio della applicazione e' lo stesso e anche se l'utente e' gia' loggato in Gmail.
Quindi l'azione maligna non avrebbe successo.
By default, infatti, per Internet Explorer una applicazione non verrebbe eseguita in condizioni normali, in un iframe. Se una applicazione viene eseguita in un iframe, per IE e' molto probabile che di quell'applicazione venga fatto un uso inappropriato, forse illecito.

Se l'autore della applicazione web sa gia' o ha progettato che quella applicazione X verra' (o dovra') essere eseguita in finestre modali, finestre figlie, iframes, o frames, allora e' possibile "dire" ad Interner Explorer di consentire il caricamento normale anche se non nella finestra "top" (finestra principale). Questo si fa facendo si' che il server web utilizzato (IIS, Apache, ecc) invii un header del tipo:


nome header: 'P3P'
valore: 'CP="CAO PSA OUR'"

dove valore puo' comprendere una serie diversa (anche lunga) di sigle diverse a seconda delle istruzioni che si vogliono inviare ad Internet Explorer riguardo la P3P policy.
L'esempio mostrato sopra, dice ad IE, tra l'altro, che esso puo' consentire ad una applicazione di accedere ai suoi cookies anche se essa viene eseguita in un iframe o finestra dipendente di altro tipo.


Se avete inteso bene quello che ho scritto, avrete inteso che in condizioni normali i rischi con Internet Explorer in questo specifico caso di attacco, sono minimi nella maggioranza dei casi, poiche' nella maggioranza dei casi bisogna essere autenticati ad un sito - per mezzo di cookies - affinche' un attacco possa manipolare un nostro account.

Fortunatamente, il 99.99% degli sviluppatori non sa neanche dell'esistenza della P3P, motivo per cui la stragrande maggioranza dei siti non dovrebbe essere attaccabile in questo modo, usando Internet Explorer anche con Javascript attivato.

L'altro tipo di giochetto su cui sto lavorando e cui ho accennato in precedenza, beh, quello invece richiede si' Javascript, ma e' cross browser compatibile

Ho quasi la impressione che tra non molto, forse giorni o poche settimane, qualcuno (per es. MS? - di certo non Mozilla e compagnia ) fara' pubblicita' a questa cosa di cui ho parlato adesso.
In tal caso, ricordatevi di quest'altra anticipazione

Sisupoika

[W.S.]

Penso che stia facendo tanto rumore perché _finalmente_ ci si sta rendendo conto della fragilità del web. O meglio, gli addetti la conoscono da sempre ma solo ultimamente si è deciso di pensare ad un rimedio, pensando al rimedio sono state pubblicate opinioni, rischi e discusse possibilità, es:
http://lists.whatwg.org/pipermail/wh...er/016284.html

Ne è uscito che non ne usciremo tanto facilmente, niente di nuovo per gli addetti, una catastrofe per gli evangelizzatori del web2.0 e la stampa
Non c'è da stupirsi se c'è tanto rumore a riguardo

Che poi IE sia più o meno vulnerabile di altri browser poco importa, sono tutti vulnerabili perché la vulnerabilità non sta nei browser ma nell'architettura. I browser possono solo provare a mettere delle pezze ma per quanto funzionali tali restano. Se poi l'utente vuole avere i vantaggi del web2.0 ma la sicurezza di un browser senza script, (i)frame e plugin... c'è un bel lavoro da fare

[Sisupoika]

Ho visto quel post ieri, ma lo devo ancora leggere.

Cmq, sono d'accordo sul fatto che, come giustamente dici, e' una cosa che vista dall'alto interessa tutti i browser, ma non vedo perche' non sottolineare, na volta tanto, un aspetto positivo di Internet Explorer che di fatto lo rende meno vulnerabile di altri, in questo specifico caso.
Una pagina viene di nascosto caricata nella stessa finestra, senza che l'utente possa notarla? Fine, finche' queste due condizioni sono rispettate

1) il clickjacking nello specifico caso si appoggia ad un iframe invisibile (come detto, e' possibile fare altro anche senza un iframe)
2) il sito target non cambia le impostazioni predefinite per il P3P

allora ie e' meno vulnerabile degli altri, anche con Javascript attivato.
L'accesso ai cookies viene negato e l'utente non risulta loggato nell'iframe.
Dunque, nessun grosso pericolo in condizioni normali, con il 99.99% delle applicazioni.

Cmq ieri ho dimenticato, per tutti gli sviluppatori che siano interessati a "proteggere" le proprie applicazioni da attacchi di questo tipo e altri simili, ma anche per gli utenti curiosi di vedere come si comporta un sito in merito al P3P, e' possibile usare un validator messo a disposizione di W3C.

http://www.w3.org/P3P/validator.html

E' uno strumento vecchio ma dice se il sito ha specificato importazioni P3P attraverso il file di configurazione P3P.xml oppure mediante gli headers.

Sia chiaro, non e' una protezione definitiva perche':
- non evita attacchi di questo tipo, ma li rende inutili nella grande maggioranza dei casi
- funziona normalmente soltanto con Internet Explorer al momento (Firefox e Opera consentono l'accesso ai cookies anche in iframes.... and Safari, se non ricordo male, ignora completamente P3P )

Pero' visto che la stragrande maggioranza di utenti, soprattutto quelli "normali", usa IE... penso sia utile sapere questa cosa.

Fra l'altro, WS, una ulteriore dimostrazione che i principali players del web spesso non si curano minimamente di qualcosa finche' possono evitarla, c'e' da dire che anni fa (e sottolineo anni fa), era stato proposto da piu' parti di aggiungere l'attributo "target" al meta refresh, in modo da consentire di evitare che una applicazione venisse eseguita in un iframe, anche senza dover ricorrere a Javascript (proprio perche' Js puo' essere disabilitato).
Quella proposta fu ignorata.
Se oggi l'attributo "target" del meta refresh esistesse, si potrebbe renderlo attivo by default (a meno che lo sviluppatore stesso voglia l'applicazione eseguibile in iframe per es. widgets e simili) e il 99.999999999999% di questi attacchi non avrebbe neanche piu' senso, perche' le applicazioni non sarebbero eseguibili in iframes tranne se esplicitamente voluto da chi le fa.

[W.S.]

Vero, tra l'altro una delle soluzioni più gettonate è introdurre proprio un header opzionale tipo il target, non proprio la stessa cosa ma simile, in pratica al posto di dire dove può essere caricata, una pagine definisce tramite acl cosa può caricare (da che sorgenti esterne).

Il motivo per cui non si parla della protezione di IE... boh, solite questioni "politiche" immagino, so che si parla di FF+noscript perché la collaborazione tra i 2 americani e Maone è stata "pubblica" e quindi seguita fin dall'inizio.

[Sisupoika]

Originariamente inviato da W.S.

Vero, tra l'altro una delle soluzioni più gettonate è introdurre proprio un header opzionale tipo il target, non proprio la stessa cosa ma simile, in pratica al posto di dire dove può essere caricata, una pagine definisce tramite acl cosa può caricare (da che sorgenti esterne).

Il motivo per cui non si parla della protezione di IE... boh, solite questioni "politiche" immagino, so che si parla di FF+noscript perché la collaborazione tra i 2 americani e Maone è stata "pubblica" e quindi seguita fin dall'inizio.

Se proprio devo essere sincero, dopo aver letto qualcosa ho piu' l'impressione che Maone stesso stia cercando di "spingere" la cosa su Noscript mentre Grossman gli ha educatamente "fatto notare" che Noscript non e' la protezione definitiva di cui Maone sembra tanto parlare.
Fra l'altro non parlerei di collaborazione in senso proprio del termine, dal momento che Maone non e' a conoscenza di cosa Hansen e Grossman intendono per clickjacking.
Lui ha persino chiesto pubblicamente a Grossman di dirgli qualche dettaglio in privato "cosi' da migliorare Noscript" (LOL, imho), e Grossman gli ha educatamente risposto di no.
Al momento c'e' soltanto speculazione perche' le varianti possibili sono molte, e Maone non fa altro che spingere per Noscript affinche' la usino piu' persone possibile. Impossibile negare che Noscript puo' in teoria proteggere da un bel numero di possibilita' d'attacco, ma a me non e' mai piaciuto non solo perche' riporta il web indietro di anni, ma anche perche' e' troppo soggetto al tipo di ingegneria sociale piu' pericoloso: quello naturale derivante dalla usabilita' di un sito.
Quanti, mi chiedo, tra coloro i quali usano Noscript, non consentono mai l'esecuzione di scripts in un sito che piace o che hanno bisogno di utilizzare, o semplicemente perche' hanno fretta di usarlo e dunque non fanno altro che... un click su Noscript per usare il sito "normalmente"?
Oppure tutti gli utilizzatori di Noscript hanno la pazienza, e le conoscenze, per analizzare da cima a fondo un sito prima di consentire l'esecuzione di scripts?
Lo dubito fortemente
Inoltre la soluzione Noscript (che soluzione non e'), si appoggia al concetto di trusted publishers.
Ma quali sono i criteri secondo cui un utilizzatore di Noscript puo' "fidarsi" di un determinato sito? (a meno di analizzare tutto?)
Conoscere per nome un sito come hwup, per esempio, e' sufficiente perche' un utente lo metta in whitelist, secondo il funzionamento di Noscript?
Potrebbe anche accadere che un sito trusted venga compromesso per altre lacune in sicurezza, e Noscript sarebbe comunque inutile, oltre a compromettere l'usabilita' di una bella fetta del web.

[W.S.]

Certo che noScript non è La Soluzione. Ha diversi problemi alcuni legati alla sua architettura, come la facilità con cui si inganna l'utente, altri legati al web stesso: se un sito viene compromesso siamo fregati con o senza noScript dato che "il web" non ha un hash firmato a seguito di ogni pagina di cui ci si vuole fidare nemmeno quando si viaggia in https.
Però è una pezza tutto sommato funzionale e già pronta, limita alcune funzionalità che l'utente vuole perchè il problema di sicurezza è proprio legato a quelle funzionalità, o meglio al modo in cui sono state implementate.

Che Maone spinga verso un suo prodotto mi sembra scontato e mi stupirei del contrario. Ha fatto pure bene a chiedere maggiori informazioni, si occupa di un sistema di sicurezza (ok, niente di complicato ma di fatto di questo si tratta) e giustamente ha chiesto maggiori info, così come le hanno ottenute chi scrive browser avrebbe potuto ottenerle pure lui.
Personalmente sono per la full disclosure, anche in questo caso avremmo evitato una marea di speculazioni, allarmismi e sospetti. In fondo non sappiamo ancora di cosa si tratti davvero, non hanno pubblicato nulla, magari ci sono dettagli che finora ci sono scappati. Magari stiamo parlando di problemi conosciuti da tempo quando il clickjacking si basa anche su altro.

Per la collaborazione, Hansen stesso ha definito FF+noScript la migliore pezza disponibile, che copre il 99,99% dei casi. Ok, non hanno lavorato direttamente insieme a migliorare noScript, non chiamiamola collaborazione ma di fatto qualcosa c'è stato.

[Sisupoika]

Originariamente inviato da W.S.

Certo che noScript non è La Soluzione. Ha diversi problemi alcuni legati alla sua architettura, come la facilità con cui si inganna l'utente, altri legati al web stesso: se un sito viene compromesso siamo fregati con o senza noScript dato che "il web" non ha un hash firmato a seguito di ogni pagina di cui ci si vuole fidare nemmeno quando si viaggia in https.
Però è una pezza tutto sommato funzionale e già pronta, limita alcune funzionalità che l'utente vuole perchè il problema di sicurezza è proprio legato a quelle funzionalità, o meglio al modo in cui sono state implementate.

Che Maone spinga verso un suo prodotto mi sembra scontato e mi stupirei del contrario. Ha fatto pure bene a chiedere maggiori informazioni, si occupa di un sistema di sicurezza (ok, niente di complicato ma di fatto di questo si tratta) e giustamente ha chiesto maggiori info, così come le hanno ottenute chi scrive browser avrebbe potuto ottenerle pure lui.
Personalmente sono per la full disclosure, anche in questo caso avremmo evitato una marea di speculazioni, allarmismi e sospetti. In fondo non sappiamo ancora di cosa si tratti davvero, non hanno pubblicato nulla, magari ci sono dettagli che finora ci sono scappati. Magari stiamo parlando di problemi conosciuti da tempo quando il clickjacking si basa anche su altro.

Su questo non sono d'accordo per il semplice fatto che se si tratta, come sembra, di una tecnica possibile su qualunque browser, senza nessun browser con una protezione interna per contrastarla, una full disclosure porterebbe una miriade di soggetti a sfruttare tale tecnica, soprattutto con una cosa dal potenziale enorme come in questo caso.
Molto meglio cosi', imho, almeno non molti sanno di preciso di cosa si tratta.

[W.S.]

capisco i problemi che ne potrebbero derivare ma sono fatto così, preferisco la conoscenza.
Ci sarebbero anche una miriade di sviluppatori intenti a trovare una soluzione, mentre ora siamo tutti impegnati a immaginare, supporre, speculare.. non sappiamo ancora cosa abbiamo di fronte

[Sisupoika]

Originariamente inviato da W.S.

sono fatto così, preferisco la conoscenza.

anche molti malintenzionati, immagino

[riazzituoi]

.

[Sisupoika]

Certo, e noscript nella nuova versione interviene anche in questi casi.

Non l'ho negato.
Ho solo detto che non mi piace il suo approccio, e per me e' una pezza, non una soluzione.
Spiego meglio cosa intendo per soluzione: qualcosa di semplice, immediato, che non richiede nulla da parte dell'utente e sia gia' disponibile per tutti a prescindere dal browser utilizzato, e che non comprometta nuove funzionalita', troncandole.

Dipende da come uno difende/imposta il proprio browser...

appunto...
Sono certo tu conosca la % di utenti che usa un browser cosi' com'e', vero?

Proxomitron

Secondo cio' che intendo io per soluzione, come sopra esposto, si tratterebbe di un'altra pezza

Per quanto riguarda il p3p, questa policy è supportata anche da firefox già da anni

Non ho parlato di "mancato supporto", ma di "diversa implementazione", e di "comportamento by default".
Onde evitare di ripetere, rileggi il mio post

vedi sopra

a quale parte ti riferisci di preciso?

Infatti noscript è una soluzione solo per firefox

appunto

Maone ha avuto accesso in privato a info sulla questione, quindi ne sa più di noi (vedi secondo post)

Se e' poi riuscito a convincere i due a dirgli qualcosa di preciso in privato, non lo so, ma con l'ultimo tentativo che mi risulta abbia fatto almeno in pubblico mi pare che abbia ottenuto un educato no

sbagliato, perchè la protezione di noscript funziona indipendentemente da cosa ci hai messo nella white list (e anche questo aspetto è altamente configurabile)

ancora una volta... se leggessi quello che scrivo eviteremmo rimbalzi inutili

Noscript blocca tutti gli script by default. E' corretto cio' che dico, oppure e' cambiato qualcosa nell'ultimo anno?
Il mio discorso era: un utente X ha Firefox con Noscript. Carica un sito, e Noscript gli blocca tutti gli script per default. Utente X perche' si fida / ha fretta / e' eccitato di vedere quel sito, potrebbe non pensarci due volte prima di lasciare che Noscript consenta l'esecuzione degli script in quel sito.
Tu sicuramente ci penseresti tre volte perche' sei piu' attento e usi Noscript con cognizione di causa. Ma pensi che tutti facciano altrettanto?
Se si', beh... opinioni diverse.

[Sisupoika]

giusto per non inquinare la news
http://www.hwupgrade.it/forum/showth...0#post24446550

[riazzituoi]

.