Nuovo attacco: Clickjacking

[riazzituoi]

.

[riazzituoi]

.

[c.m.g]

ripreso da punto informatico:

http://punto-informatico.it/2419482/PI/Commenti/clickjacking-tutti-browser-vulnerabili.aspx

e webnews:

http://www.webnews.it/news/leggi/9228/allarme-clickjacking-sul-web/

[riazzituoi]

.

[Ignorante Informatico]

Novità by Giorgio Maone (sviluppatore di NoScript)..
Merita tutti i consensi che ha ed ogni donazione effettuata a suo favore.


http://software.informaction.com/data/noscript/logo.png

Buon NoScript a Tutti ;)

[Sisupoika]

Nuovo? :D

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 (http://www.hwupgrade.it/forum/showpost.php?p=18841286&postcount=25) 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 :D

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 :D
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 :D

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 :D
Ma, credetemi: Internet Explorer e' al momento piu' sicuro degli altri browser contro molte varianti di clickjacking :D

Non sto scherzando!!! :D
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 :asd:

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

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/whatwg-whatwg.org/2008-September/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 :D
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 :D

[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 :D)

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]

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 :fagiano:
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]

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. :D
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 :D

[Sisupoika]

sono fatto così, preferisco la conoscenza. :D

anche molti malintenzionati, immagino :D

[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? :fagiano:

Proxomitron

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

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? :confused:

Infatti noscript è una soluzione solo per firefox

appunto :fagiano:

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 :D

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/showthread.php?p=24446550#post24446550

[riazzituoi]

.

[Sisupoika]

pochi..

:mbe: mi sfotti? :D

è utile anche in molte altre situazioni, quindi ben vengano queste pezze

evvabbe che ti devo dire, accattatavill (o come diavolo si scrive) :D

di default hai ragione, però volevo sottolineare che è possibile ottenere lo stesso risultato con firefox

l'importante e' che alla fine ci capiamo :D

leggendo questo sembrerebbe di si:
http://blogs.zdnet.com/security/?p=1973

"I had access to detailed information about how this attack works"

uhm... questo e' cio che dice lui, ma sul ha.ckers.org abbiamo:

# Giorgio Maone Says:
September 19th, 2008 at 2:02 pm

@Jeremiah, RSnake:
could you share privately some more details with me?
Maybe NoScript could reach a perfect 100% ;)
# Jeremiah Grossman Says:
September 20th, 2008 at 7:35 am

Hi Giorgio, not right now, sorry. Soon though we hope.

However, I believe those running NoScript and other security plug-ins like it really have a low probability of being impacted.


Almeno fino ad oggi 6 Oct non ho trovato nessuna traccia di una "ufficiale" collaborazione tra Hansen&Grossman e Maone. Non ho trovato da nessuna parte dove Hansen o Grossman dicono di aver spiegato tutto a Maone affinche' egli aggiorni Noscript di conseguenza.

Che possiamo dire in merito? Boh.. :D

[riazzituoi]

.

[Sisupoika]

"As I hinted in my original clickjacking article "

link => "Sorry, no posts matched your criteria." :mbe: :D

Cmq se e' vero che c'e' stata collaborazione, tanto meglio per lui e soprattutto chi usa Noscript ;)

[eraser]

Da quello che ho capito (da persone più esperte di me in questo specifico settore) questa tipologia di attacco è abbastanza vecchia, addirittura alcuni esempi sono datati 2005

[Sisupoika]

Da quello che ho capito (da persone più esperte di me in questo specifico settore) questa tipologia di attacco è abbastanza vecchia, addirittura alcuni esempi sono datati 2005

Non so di preciso da quand'e' che si sono visti i primi esempi, cmq di certo non risale ne' a Settembre 2008, ne' a Settembre 2007 quando ne facevo cenno qui :D

Cmq devo preparare un'altra demo su una variante :asd:

[Chill-Out]

Demo

http://www.planb-security.net/notclickjacking/iframetrick.html

[Sisupoika]

Demo

http://www.planb-security.net/notclickjacking/iframetrick.html

http://www.hwupgrade.it/forum/showthread.php?t=1835819

:D

[Chill-Out]

http://www.hwupgrade.it/forum/showthread.php?t=1835819

:D

L'avevo visto ;)

[El Tazar]

Non ho capito una cosa,
di default IE7 sarebbe già al riparo?

Scusate ma non ho capito il passaggio :D

[Sisupoika]

Non ho capito una cosa,
di default IE7 sarebbe già al riparo?

Scusate ma non ho capito il passaggio :D

Non e' esattamente "al riparo" :D
E' meno vulnerabile degli altri se confronti i browser a condizioni e impostazioni di default.
Questo tipo di attacco avrebbe senso se portato contro un sito nel quale la vittima e' in quel momento loggato. Almeno per la maggioranza dei siti con autenticazione - e' probabile che dei cookies siano stati salvati nel browser nel momento in cui l'utente si e' loggato, in modo da evitare un nuovo login ad ogni volta (a parte discorso della scadenza dei cookies ecc).
In queste condizioni, l'attacco funzionerebbe con Internet Explorer soltanto se hai una sessione attiva del sito vittima, mentre visiti il sito diciamo "maligno".
In quel modo e' possibile, per il sito maligno, far si' che il sito vittima acceda ai suoi cookies anche dall'interno di un iframe.
Ma se non hai sessioni attive del sito vittima in quel momento, allora non dovrebbe avere successo poiche' il sito vittima stesso, quando eseguito in un iframe, non puo' accedere ai suoi stessi cookies a causa della implementazione di P3P di IE.
Con gli altri browsers, invece, in condizioni normali e' sufficiente che tu sia loggato e abbia ancora i cookies di autenticazione nel browser, perche' la cosa funzioni. Anche se non hai sessioni attive del sito vittima in quel momento.

[riazzituoi]

.

[Sisupoika]

Il fatto è che è praticamente impossibile non avere sessioni attive (tabbed browsing rulez :asd: )

Infatti

edit:
forse con IE8 non ci dovrebbe essere questo problema (intendo quello di chiudere completamente il browser)

Mi chiedevo lo stesso, ma non ho ancora avuto tempo per provarlo.

[El Tazar]

Ok adesso è chiaro :D

Ti ringrazio per la esauriente spiegazione :cool:

[Chill-Out]

http://www.adobe.com/support/security/advisories/apsa08-08.html

[Sisupoika]

http://www.adobe.com/support/security/advisories/apsa08-08.html

Attivare camera e microfono all'insaputa dell'utente...lol
Con questi trucchetti sembra che le applicazioni siano infinite :D
La seconda demo che stavo preparando riguarda java.
Ho messo un piccolo uploader Java nella pagina ed un falso link.
Se Java e' installato nel sistema, col falso click faccio fare upload del file desktop.ini della cartella Documents dell'utente (giusto un file a tromba come PoC :D)
Cmq stavo avendo problemi e l'ho temporaneamente lasciata perche' devo lavorare.
Ma il concetto e' chiaro: Java puo' essere anche piu' pericoloso di Flash in determinate condizioni.

[riazzituoi]

.

[Sisupoika]

NoScript si aggiorna con una nuova funzionalità anti-clickjacking (indipendente dall'opzione forbid iframe):

Hello ClearClick, Goodbye Clickjacking! (http://hackademix.net/2008/10/08/hello-clearclick-goodbye-clickjacking/)


PS
ho fatto una prova veloce con IE8, e ho notato che l'attacco funziona solo se si forza la compatibilità (vista compatibilità), altrimenti anche con la sessione attiva non accede al cookie.

Compatibilita'? a che ti riferisci di preciso?

Cmq sembrerebbe confermato che si tratta dei trucchetti di cui parlavamo, o comunque di quel genere di cose. Perche' e' stata fatta passare per cosa nuova, se e' questo il caso? :confused:

[riazzituoi]

.

[Sisupoika]

In IE8 c'è un pulsante vicino la barra degli indirizzi, per forzare la compatibilità dei siti. Non mi sono documentato, quindi non so come funzioni di preciso, però l'attacco riesce solo se è attivata la compatibilità (e ovviamente c'è la sessione attiva).

Se la compatibilità non è attivata l'attacco (parlo della tua demo) non riesce, anche se c'è la sessione attiva.

capito. non l'ho visto ancora, e non ho la piu' pallida idea di come sia

come la scoperta dell'America

forse e' meglio attendere qualche dettaglio in piu'.
Puo' anche darsi che questo clickjacking sfrutti roba vecchia ma in un modo completamente nuovo. Se riesco ad avere tempo daro' una occhiata anche a Noscript, per vedere cosa implementa e come si comporta; ad una veloce lettura del post di Maone a riguardo, la soluzione mi sembra carina, intendo quel genere di alert cosi' bene esplicativo.
Come gia' detto diverse volte non mi piacciono molti aspetti di Noscript, pero' se l'autore riuscisse a trasformarlo in una sorta di hips con alerts fatti bene come questo "ClearClick", allora si' che sarebbe figo!
Significherebbe che un sito potrebbe funzionare normalmente, e che Noscript interverrebbe soltanto quando un'azione potenzialmente pericolosa avviene.
Ma per forza di cose una simile soluzione e' molto difficile, sempre se possibile, da realizzare. Tra Javascript e CSS, e tutte le infinite modalita' di scrittura e offuscamento possibili... hai voglia :D

Piccolo OT: un paio di giorni fa ho visto una vulnerabilita' nei Gadgets di Google nella gestione del mash up tra i diversi domini... non ho letto ancora niente in proposito quindi non so se si sa gia'.
Cmq in pratica da un gadget puoi compromettere il comportamento di un altro gadget (se questo e' presente nella stessa pagina).
Nelle prove che ho fatto avevo il gadget di Google Docs e quello di prova nella stessa pagina, e dal mio ho letto la lista dei documenti dall'altro gadget.
Questa cosa gia' da sola... lol. O blocchi tutto e dimentichi mashups fatti in questo modo, rinunciando a tutte le funzionalita' connesse, o rischi sempre e comunque. La vedo dura realizzare una soluzione tipo hips come dicevo prima :D
Ieri poi leggevo la draft dell'html 5, circa gli aggiornamenti sull'integrazione di un sistema per il cross domain scripting.

STRA-LOL: :D

E' gia' vulnerabile alla base, all'origine del concetto: si baserebbe su una sorta di autorizzazioni a livello di domini (cioe' potrai, per esempio, autorizzare il dominio A ad inviare messaggi al dominio B), ma il bello e' che i domini vengono trasmessi come semplici stringhe nello scambio di messaggi.
E quanto ci vuole, in questo modo, a fare fake requests o inviare messaggi facendosi passare per un altro dominio? :D

[W.S.]

Ieri poi leggevo la draft dell'html 5, circa gli aggiornamenti sull'integrazione di un sistema per il cross domain scripting.

STRA-LOL: :D
A questo affiancaci lo storage lato client e vedi che bel casino salta fuori :D

Non ci si scappa, l'architettura alla base è troppo debole, si ha pensato troppo alle funzionalità e troppo poco alla sicurezza. Ora ne hai voglia di metterci pezze.

Un hips per verificare il comportamento del codice web penso sarebbe ancora più complesso rispetto a quelli che conosciamo. Buona l'idea, ne ho sentito parlare anche un annetto fa, da qui ad implementarla... è una grande sfida.

[Sisupoika]

A questo affiancaci lo storage lato client e vedi che bel casino salta fuori :D

Non ci si scappa, l'architettura alla base è troppo debole, si ha pensato troppo alle funzionalità e troppo poco alla sicurezza. Ora ne hai voglia di metterci pezze.

Un hips per verificare il comportamento del codice web penso sarebbe ancora più complesso rispetto a quelli che conosciamo. Buona l'idea, ne ho sentito parlare anche un annetto fa, da qui ad implementarla... è una grande sfida.

secondo me before long si comincera' a parlare di una riscrittura del sistema :D

[W.S.]

secondo me before long si comincera' a parlare di una riscrittura del sistema :D

Eh, sarebbe cosa buona e giusta :D

Ma quanti anni ci vorranno prima di realizzarla?

[Sisupoika]

Eh, sarebbe cosa buona e giusta :D

Ma quanti anni ci vorranno prima di realizzarla?

Uhm...vediamo. Se penso che IPv6 e' ancora li' ad aspettare... uhm... non la vedo bene :asd:

[riazzituoi]

.

[Sisupoika]

Issue #1 STATUS: Unresolved. Clickjacking allows attackers to subvert clicks and send the victim’s clicks to web-pages that allow themselves to be framed with or without JavaScript. One-click submission buttons or links are the most vulnerable. It has been known since at least 2002

:fagiano:

If you like Michael Zalewski’s term “UI redress attack”

"UI redress attack" suona piu' figo :fagiano:

Issue #2 STATUS: Unresolved. ActiveX controls are potentially susceptible to clickjacking if they don’t use traditional modal dialogs, but rather rely on on-page prompting. This requires no cross domain access, necessarily, which means iframes/frames are not a prerequisite on an attacker controlled page.

Anche questo e' noto da anni. Uhm...

Turning off microphone access in the BIOS and unplugging/removing controls to the camera are an alternative.

Oppure, se si ha un microfono USB, si puo' impostare l'ingresso mic della scheda audio come predefinito, e attivare quello usato soltanto nelle applicazioni che lo usano :asd:

La webcam? La giri contro la parete quando non la usi :asd:

Issue #2c STATUS: To be fixed in Flash 10 release. All versions of Flash on IE7.0 and IE8.0 can be overlayed by opaque div tags. Using an onmousedown event handler the object click registers as long as the divs are removed by the onmousdown event handler function. Demo here of stealing access to the microphone.

Come dicevo in un altro post, questo e' un esempio di come si possono sfruttare tecniche vecchie, in modalita' del tutto nuove. Geniale, cmq. :)

Issue #3 STATUS: To be fixed in the final release candidate. Flash on IE8.0 Beta is persistent across domains (think “ghost in the browser”). This would be a much worse vulnerability except for the fact that it beta and almost no one is using it.

LOL

Issue #4 STATUS: Unresolved. Framebusting code does not appear to work well on some sites on IE8.0 Beta. Instead it is marked as a popup which is blocked by the browser - disallowing the frame busting code from executing.

Azz, IE8 sembra iniziare bene :D
Ma dico, neanche le basi? :asd:

Issue #5 STATUS: Unresolved. State of clicks on other domains can be monitored with JavaScript (works best in Internet Explorer but other browsers are vulnerable too) which is cross domain leakage and can allow for more complex multi-click attacks. For example a page that has a check box and a submit button could be subverted upon two successful clickjacks. Additionally, this can make the attack completely seemless to a user by surrendering control of the mouse back to the user once the attack has completed.

Questa suona figa..uhm... bisogna fare delle prove :D


Issue #6 STATUS: Unresolved. “Unlikely” XSS vulnerabilities that require onmouseover or onmousedown events on other parts of pages on other domains are suddenly more likely. For example if a webpage has a XSS vulnerability where the only successful attacks are things like onmouseover or onmousedown, etc… on unlikely parts of the page, an attacker can promote those exploits by framing them and placing the mouse cursor directly above the target XSS area. Therefore, otherwise typically uninteresting or unlikely XSS exploits can be made more dangerous.

Questa e' una altra conseguenza del trick datato, non vedo perche' considerarla a parte :mbe:

ecurity=restricted as a way to break frame busting code, and that is true, although it also fails to send cookies, which might break any significant attacks against most sites that check credentials.

Infatti, ma non si e' parlato per niente di P3P. :mbe:
Vado a lasciare un commento. A dopo :D

[Sisupoika]

Ho lasciato un commento. Sono curioso di capire se c'e' un motivo per cui P3P (e cio' che avrebbe dovuto essere) non e' stato neanche menzionato in occasione di questa "scoperta".
Forse mi sono perso qualcosa...

[riazzituoi]

.

[riazzituoi]

.