Non cliccate su quel link - Parte Seconda.

[Sisupoika]

http://www.bacs.uq.edu.au/images/content/phishing.jpg

Ciao a tutti,

dal titolo avrete ormai capito di cosa si tratta; questo e' il secondo test di cui parlavo.

Esso presenta uno scenario piu' verosimile per rendervi l'idea, e nella pagina al link che segue ho messo anche qualche nota di chiarimento, che vi invito a leggere.

Fate qualche test come l'altra volta, e fatemi sapere cosa notate con i vostri antivirus, browsers, e voi stessi.

Naturalmente, per il test dovrete attivare javascript temporaneamente, o disabilitare noscript.

Oltre ad impressioni, suggerimenti, e commenti vari, mi interessa sapere anche se trovate semplice scovare il Javascript esatto usato nella pagina, poiche' sto testando anche altre cose allo stesso momento.
Fate qualche prova anche in questo senso, oltre a sperimentare il possibile scenario di attacco phishing o gli altri cui ho fatto cenno, e incollate qui nel forum il Javascript che trovate.
Naturalmente, sempre per "rendere l'atmosfera" ( :D ) ho offuscato un pochino il Javascript, ma con un sistema diverso da quello precedente e che, con un paio di accorgimenti, dovrebbe evitare di allertare l'euristica dell'antivirus, qualora esso riuscisse a rilevare il Javascript stesso... Fatemi sapere.

update: purtroppo a causa di alcune limitazioni (sembra) sul mio hosting, ho dovuto rimuovere parte del sistema che uso per nascondere dinamicamente il Javascript, a causa di errori e Timeout. Quindi al momento live c'e' una parte di questo sistema semi-statica, per ovviare al problema riscontrato, e quindi non altrettanto efficace di quanto accennato. Vi faro' sapere quando avro' risolto.

Ah, dimenticavo. Naturalmente ho pensato anche a ... uhm meglio non rovinare la sorpresa :fagiano: :D

Trovate il test Qui (http://www.sisulabs.com/HardwareUpgrade/NonCliccateSuQuelLink.aspx).

E tranquilli: non c'e' alcuna altra azione velata al di fuori di quanto descritto, ne' alcun dato viene trasmesso senza il vostro consenso.

Adesso vado a dormire almeno fino alle 11 (12 ore italiana) :D visto che sono gia' le quattro... leggero' dopo i commenti.

Sisupoika

[W.S.]

Ciao Sisupoika!
Bhe, stavolta non c'è dubbio che si tratti di phishing :)

Ambiente di test:

OS: Debian GNU/Linux 4.0 stable
browser: Firefox (Iceweasel) 2.0.0.6
antivir: no
altri sw di protezione: presenti ma irrilevanti in questo caso

Ovviamente, senza alcun accorgimento, il tutto funziona come previsto e nessun "allarme" si accende :)
Come nel test precedente, usando l'opzione "open link in new tab" viene caricato il sito reale, non quello fake.

Stavolta non ti è bastato 1 link ma ben 3?!? ;P
Ho recuperato il codice degli script offuscati nello stesso modo usato nel tuo test "a tre fasi" su cui ho battuto la testa tempo fa :) non riporto qui il metodo per evitare di togliere la soddisfazione ad altri.

Ora procedo al de-offuscamento e vedo cosa c'è dietro.
Molto interessante l'applicazione della tecnica per mascherare l'indirizzo e-mail!! :)


Dobbiamo attendere che venga inventata un'altra categoria di "software per la sicurezza" che protegga da manomissioni gratuite di stupidi link, oppure e' forse ora che il mercato della sicurezza e le protezioni offerte vengano riviste un po' a beneficio dell'utente, prima che del mercato stesso?
Sante parole!!!

[W.S.]

Uffa, mi son giocato la sorpresa nel test precedente :( ;)


var _href = '';
var _mailLink = null;

window.onload = function() {
document.links[3].onclick = function() {
this.href = 'FakePage.aspx';
}
document.links[4].onclick = function() {
_href = this.href;
_mailLink = this;
this.href = 'mailto:sisupoika@sisulabs.com';
setTimeout('_mailLink.href = _href', 1000);
}
}

[Sisupoika]

Ciao WS! :D

Grazie per il feedback, attendo anche quello di Sampei che aveva fatto anche diverse altre prove.

Per il Javascript, purtroppo ho dovuto eliminare una parte della storia perche' una parte non mi funzionava sull'hosting mentre sul mio laptop va a meraviglia!

In pratica ho dovuto mettere il js in maniera "statica", da cui i tre link che hai visto - la maniera piu' semplice che ho trovato la scorsa notte per far funzionare la cosa ovviando a questo problema, che e' diciamo "OT" :D

Ci stavo impazzendo e non ho capito perche' non funzioni live.

Sul sistema "completo" uso un caricamento dinamico una catena di tre web requests, due sul server e una sul client con ajax, e non esiste alcun file JsX.aspx: ho usato invece un http handler che accetta nomi random in ingresso e genera il js in tre parti con un offuscamento dinamico (alcune parti sono differenti ad ogni richiesta), che viene poi letto ed interpretato dal client altrettanto dinamicamente con una routine ajax - se js e' abilitato - e lo aggiunge agli eventi pagina.

Senza entrare troppo in dettaglio, il giochetto che ho fatto fa in modo che il Js non possa essere salvato con curl o wget per esempio, funzionando solo nel browser - questa era la novita' cui avevo accennato in privato a proposito, se ricordi.
Inolte l'offuscamento e' fatto in modo che anche se usi ethereal etc non ci capiresti una mazza perche' non ci sono caratteri di inizio e fine o altri elementi che possono aiutare ad individuare qual'e il js. E anche se ci si riesce, si tratta solo di stringhe crittografate (non piu' solo offuscate dunque!) e decodificabili dal client sempre attraverso il giochetto delle web requests a catena.
Per quanto ne sappia io, non conosco al momento un modo per ritrovare il js originale in questo modo, ma spero di risolvere i problemi che ho trovato con l'hosting cosi' da postare un aggiornamento e invitarti e invitarvi a provare.

Il problema che ho con l'hosting e' che in pratica sembra bloccare le due web requests lato server facendo finire tutta storia in Timeout e rovinando il gioco. :D
Penso, ma non sono sicuro, che si tratti di un problema di restrizioni di sicurezza sulle loro macchine, ma al momento non ne ho la piu' pallida idea del come.
Il problema e' che non so se contattarli o meno...non e' che posso scrivere loro una mail dicendo "ho problemi nel testare un attacco phishing o drive-by sul vostro hosting, mi aiutate a risolvere?" :D
Quindi mi tocca trovare un rimedio; inoltre la libreria che ho scritto per quel sistema di crittografia di cui ti parlavo, che usa la stringa stessa come una delle due chiavi, neanche funziona live ritornandomi una non meglio specificata "unhandled exception" :muro:
Ma che azz vuol dire? .NET e' fantastico ma non immune alle cazzate di mamma Ms in merito ai messaggi di errore, mai helpful :D

Per risolvere la cosa temporaneamente e far funzionare almeno il discorso della simulazione di phishing, tema del thread, ho in pratica eliminato tutte le web requests prendendo i response gia' generati da un run sul mio laptop, e menttendoli statici col solo controllo delle variabili di sessione. Ovviamente gia' questo rovina tutta la parte dinamica; inoltre ho dovuto eliminare anche la web request che uso per caricare al volo il sito "vittima" (hwupgrade) ed effettuare la riscrittura dinamica di hrefs, srcs ecc proprio come un web proxy ( :D ) e sfruttando la pagina reale del sito vittima invece di crearne una copia come quelle spesso mal fatte usate negli attacchi di phishing veri. E questa e' una figata, perche' riflettendo il sito vittima com'e' esattamente in quel momento, rende piu' difficile l'individuazione che si tratti di un clone.
Anche in questo caso, ho purtroppo eliminato la web requests e la riscrittura dinamica, per il problema di cui sopra, e messo sul server una copia gia' pronta generata dal mio laptop, come semplice file di testo da leggere come sorgente. Hai provato anche ad immettere dati di login e farti loggare nel forum? A parte l'alert che non ci sarebbe in un attacco vero, il tutto procederebbe normalmente e un utente comune non si accorgerebbe di nulla.

Cmq vedo di risolvere quei problemi e non appena riesco (hopefully) aggiorno la cosa cosi' potete provare il sistema completo.

Per ora l'importante e' che riesca a rendere l'idea del sistema di phishing :)

Ciaps!

S

[W.S.]

Senza entrare troppo in dettaglio, il giochetto che ho fatto fa in modo che il Js non possa essere salvato con curl o wget per esempio, funzionando solo nel browser - questa era la novita' cui avevo accennato in privato a proposito, se ricordi.
Inolte l'offuscamento e' fatto in modo che anche se usi ethereal etc non ci capiresti una mazza perche' non ci sono caratteri di inizio e fine o altri elementi che possono aiutare ad individuare qual'e il js. E anche se ci si riesce, si tratta solo di stringhe crittografate (non piu' solo offuscate dunque!) e decodificabili dal client sempre attraverso il giochetto delle web requests a catena.

:) Già in questo caso ho evitato wget e provato ad usare solo ethereal (si, mi ricordavo che volevi aggirarli, quini li ho evitati ;) ). In questo caso mi ha (ovviamente) permesso di vedere subito tutto, anche se offuscato.
Comunque non credo che riuscirai mai a nascondere completamente il funzionamento ad un utente accorto che usa uno sniffer. Ok, leggerà roba offuscata/cifrata, ma il modo per deoffuscarla/decifrarla lo troverebbe seguendo passo passo il comportamento del browser con il tracciato della connessione, altrimenti nemmeno il browser riuscirebbe ad interpretare i dati ricevuti (effettivamente speravo che utilizzassi il tuo algoritmo per questo, in modo da trovare una chiave di lettura per quelle maledette stringhe dell'altro test! ;) ).

Questo giochetto però può farlo solo un utente fisico (non un programma) preparato e disposto a decifrare quello che gli passa sotto il naso... in poche parole, durante un test come questo dove un utente sa che c'è sotto qualcosa. In una situazione reale tutto passerebbe senza lasciare alcuna traccia.
Per fronteggiare un attacco simile probabilmente andrebbe rivisto il funzionamento del browser e probabilmente pure qualcosina nel web 2.0... :rolleyes:

Il problema che ho con l'hosting e' che in pratica sembra bloccare le due web requests lato server facendo finire tutta storia in Timeout e rovinando il gioco. :D
Penso, ma non sono sicuro, che si tratti di un problema di restrizioni di sicurezza sulle loro macchine, ma al momento non ne ho la piu' pallida idea del come.
Ma web-requests "normali" funzionano senza problemi? Che hanno queste di diverso?

Quindi mi tocca trovare un rimedio; inoltre la libreria che ho scritto per quel sistema di crittografia di cui ti parlavo, che usa la stringa stessa come una delle due chiavi, neanche funziona live ritornandomi una non meglio specificata "unhandled exception" :muro:
Ma che azz vuol dire? .NET e' fantastico ma non immune alle cazzate di mamma Ms in merito ai messaggi di errore, mai helpful :D

E' (anche) per questo che adoro sviluppare sotto linux ed evito MS quasi quanto la morte :D
In questo non posso proprio esserti d'aiuto, .NET e asp so solo (e non del tutto) cosa sono. :)

Il copiare il sito al volo potrebbe essere veramente un bel problema per la difesa.

Ho provato ad inserire user "prova" pwd "prova" giusto per vedere cosa sarebbe successo, non me ne voglia l'utente "prova" di hwupgrade ;)
Cmq (dopo l'alert) mi diceva qualcosa del tipo "l'host deve essere ancora messo in whitelist" ... non so cosa significhi.

Cmq vedo di risolvere quei problemi e non appena riesco (hopefully) aggiorno la cosa cosi' potete provare il sistema completo.
Sempre a disposizione per verificare il sistema! :)

Per ora l'importante e' che riesca a rendere l'idea del sistema di phishing :)

La rende anche troppo bene! :D

[Sisupoika]

:) Già in questo caso ho evitato wget e provato ad usare solo ethereal (si, mi ricordavo che volevi aggirarli, quini li ho evitati ). In questo caso mi ha (ovviamente) permesso di vedere subito tutto, anche se offuscato.

Aspetta che riesco a mettere online la parte con la crittografia!
Finche' lascio con il solo offuscamento, sia esso semplice o complesso, c'e' sempre il modo per fare reverse.
Ma se si ha a che fare con qualcosa di crittografato con un sistema che non si conosce e non standard allora penso che la cosa si renda molto piu' difficile. :D
Col sistema "full optional" (LOL) in pratica il codice javascript arriva tutto crittografato attraverso una web request; una chiave e' la stringa stessa che contiene il codice, l'altra viene fornita al volo in una stringa anch'essa crittografata con il session id :D
Una volta aggirati wget e curl (a proposito, faresti qualche prova con loro adesso se riesci a vedere il javascript? mi pare che il trucchetto dovrebbe funzionare anche con le modifiche che ho fatto ieri per far funzionare il test), l'unica maniera per vedere il codice Javascript e' con uno sniffer di rete; ma la roba che verrebbe sniffata sarebbe crittografata e l'unica maniera per decifrarla e' eseguire l'ajax nel browser.
Ma
1 - ho messo controlli affinche' l'esecuzione completa del tutto sia possibile soltanto in un normale browser, senza trucchi vari come crawlers, wget, curl e compagnia
2 - ho messo un controllo per evitare che WS o altri ( :D ) si salvino la pagina e la parte di js che effettua la decrittografia del codice "maligno" per cercare di eseguirla sul proprio IIS usando le stringhe crittografate catturate con ethereal. Infatti stringhe crittografate (il codice javascript che e' esso stesso prima chiave, e una seconda chiave) vengono generate e ritornate correttamente soltanto se la richiesta all'origine e' stata effettuata dal mio sito, dal mio IIS, altrimenti vengono generate stringhe a tromba giusto per confondere
Come faccio a verificare che la richiesta iniziale (ecco perche' due web requests server side e una client side con ajax - che richiede un browser, non wget) provenga dal mio IIS? Semplice: controllo l'ip address da cui proviene la richiesta e il valore di una variabile application (modificata ad ogni esecuzione con il lock e unlock dell'applicazione - che non sara' il massimo dell'efficienza, ma funziona :D) che un utente o applicazione esterna non potrebbe sapere se la richiesta iniziale proviene da un altro IIS sul quale non e' presente la mia CryptoLib in .NET.
Gia' le variabili di sessioni dovrebbero rendere ostico il gioco con wget ecc. Supponiamo pure che uno riesce a fregarmi sulle sessioni, non penso che uno riesca a fare anche ip spoofing e fregare una variabile application nel mio IIS allo stesso tempo! :D
L'unica maniera sarebbe ovviamente quella di violare il server (cosa non immediata, eh?), prendere il codice con librerie e tutto quanto e fare reverse. In quel caso si potrebbe pensare a proteggere anche le dll ecc ecc - i modi ci sono, ma sarebbe forse un tantino troppo. Ovviamente scherzo.
Chi avrebbe la pazienza (e non solo pazienza ;)) per fare tutto cio'?


Comunque non credo che riuscirai mai a nascondere completamente il funzionamento ad un utente accorto che usa uno sniffer. Ok, leggerà roba offuscata/cifrata, ma il modo per deoffuscarla/decifrarla lo troverebbe seguendo passo passo il comportamento del browser con il tracciato della connessione, altrimenti nemmeno il browser riuscirebbe ad interpretare i dati ricevuti (effettivamente speravo che utilizzassi il tuo algoritmo per questo, in modo da trovare una chiave di lettura per quelle maledette stringhe dell'altro test! ).

Ricalcando su quanto descritto, la mia risposta e': Possibile. Probabile. Comunque vedremo. :D


Questo giochetto però può farlo solo un utente fisico (non un programma) preparato e disposto a decifrare quello che gli passa sotto il naso... in poche parole, durante un test come questo dove un utente sa che c'è sotto qualcosa. In una situazione reale tutto passerebbe senza lasciare alcuna traccia.

Esatto. :read:

Per fronteggiare un attacco simile probabilmente andrebbe rivisto il funzionamento del browser e probabilmente pure qualcosina nel web 2.0...


Io credo che senza ricorrere ad antivirus ecc ecc, il browser stesso dovrebbe di default avvertire l'utente quando l'href di un link viene cambiato o se invece dell'href apparente viene usato il dirottamento con l'oggetto location.
Un alert del tipo: "Il link X mostra l'URL Y ma la sua destinazione effettiva e' Z".
Non e' che ci voglia tanto ad implementare una cosa del genere. Gliela devo fare io?

Ma web-requests "normali" funzionano senza problemi? Che hanno queste di diverso?

Se per esempio leggo una pagina esterna e la storia finisce li', funziona; ma se faccio diverse richieste in loop come nel mio caso, va in timeout senza utili messaggi.
Appena ho tempo devo provare a fare le richieste con xmlhttp o altro boh.
Probabile che ci sia un blocco sulla recorsivita' o qualcosa del genere non ne ho idea.


E' (anche) per questo che adoro sviluppare sotto linux ed evito MS quasi quanto la morte
In questo non posso proprio esserti d'aiuto, .NET e asp so solo (e non del tutto) cosa sono.

.NET e' semplicemente spettacolare. Chi osanna ancora altre soluzioni sinceramente dimostra solo di non conoscere cio' che e' possibile fare, e come, con .NET.
Il problema con lo sviluppo Microsoft in genere e' che, come detto, spesso puoi impazzire per problemi anche stupidi, semplicemente perche' la piattaforma non ti aiuta piu' di tanto a capire dov'e' il problema. :muro:

Il copiare il sito al volo potrebbe essere veramente un bel problema per la difesa.

Esatto. Una pagina caricata dinamicamente dalla sorgente reale che ne rispecchi i contenuti, l'aspetto e il comportamento reali in quel momento, e' molto piu' difficile da individuare rispetto ad una copia statica spesso fatta male come in molti phishings.
L'ho anche provato col web filtering di Fortinet (da alcuni ritenuto il migliore) e passa tranquillamente sito bloccato/filtrato :D
L'unica cosa che non ho implementato ancora, affatto, sono i siti in HTTPS, per i quali non so ancora come procedere.
In realta' era qualcosa che avevo gia' messo su per giochicchiarci, mentre stavo scrivendo un "personal web proxy" qualche mese fa; non lo finii - lo devo riprendere appena possibile - pero' avevo gia' messo controllo di sessione, cookies, ecc :sbonk:
In pratica per questo test ho usato la libreria che avevo iniziato per questo proxy, modificando solo qualcosa per la riscrittura dinamica di URL ecc e l'aggiunta di quell'alert per l'esempio con hardware upgrade.


Ho provato ad inserire user "prova" pwd "prova" giusto per vedere cosa sarebbe successo, non me ne voglia l'utente "prova" di hwupgrade

LOL, esiste l'utente "prova"? :D

Cmq (dopo l'alert) mi diceva qualcosa del tipo "l'host deve essere ancora messo in whitelist" ... non so cosa significhi.

E' normale: il forum controlla il referer quando i parametri del form di login vengono inviati. Il mio dominio Stealthmeasures.com non e' nella loro whitelist, per cui quel messaggio. Se invece hai disattivato l'invio del referer dal tuo browser, ti fa fare login nel forum come nulla fosse.
Questo e' ehm, credo un bug di sicurezza, comunque, di vBulletin. IMHO non ci si dovrebbe affidare al referer soltanto per queste cose... visto che cambiarlo o disattivarlo e' un gioco. :stordita:

Naturalmente questo test e' soltanto un proof of concept, per cui non mi sono preoccupato di quella cosa.
Cosa che e' molto facilmente aggirabile, se leggo le pagine del forum dinamicamente con web request (cosa che come dicevo e' al momento non attiva), faccio la richiesta senza inviare il referer, e attivo le funzionalita' coi cookies del mio web proxy. In pratica farei effettuare anche il login attraverso il web proxy, per poi inviare l'utente alla vera home del forum.


Ah, dimenticavo. Forse non hai notato un'altra chicca.
Il forum codifica prima di inviare i dati di login, fa l'md5 hash, come puoi vedere dalla sorgente della pagina di login.
Il bello e' che con il sistema mostrato, i dati di login vengono catturati in chiaro prima che i dati vengano cryptati e inviati. :D

Sempre a disposizione per verificare il sistema! :)

Ci contavo :D

La rende anche troppo bene! :D

:D

[W.S.]

Aspetta che riesco a mettere online la parte con la crittografia!
Finche' lascio con il solo offuscamento, sia esso semplice o complesso, c'e' sempre il modo per fare reverse.
Ma se si ha a che fare con qualcosa di crittografato con un sistema che non si conosce e non standard allora penso che la cosa si renda molto piu' difficile. :D
mmm questa situazione mi pare vagamente familiare :D
Questa volta però conto sul fatto che se il browser in qualche modo la decifra, ci riesco pure io osservando quello che fa (a costo di usare un debugger ;) della serie, sempre meno applicabile in un contesto reale :D )

Una volta aggirati wget e curl (a proposito, faresti qualche prova con loro adesso se riesci a vedere il javascript?
wget riesce ancora a scaricare i js, basta lanciarlo con l'opzione "-r"

Io credo che senza ricorrere ad antivirus ecc ecc, il browser stesso dovrebbe di default avvertire l'utente quando l'href di un link viene cambiato o se invece dell'href apparente viene usato il dirottamento con l'oggetto location.
Si, lo credo pure io.
web 2.0... bellissimo da vedere ma una bestia nera da trattare.

L'unica cosa che non ho implementato ancora, affatto, sono i siti in HTTPS, per i quali non so ancora come procedere.
Ecco, questo si che taglierebbe le gambe agli sniffer :) a quel punto dovrei debuggare l'esecuzione del browser o modificarlo in modo che salvi il traffico in chiaro su un file di log :D (della serie... allegria!!! chi non fa una cosa del genere prima di aprire un sito!! :D)

Cosa che e' molto facilmente aggirabile, se leggo le pagine del forum dinamicamente con web request (cosa che come dicevo e' al momento non attiva), faccio la richiesta senza inviare il referer, e attivo le funzionalita' coi cookies del mio web proxy. In pratica farei effettuare anche il login attraverso il web proxy, per poi inviare l'utente alla vera home del forum.
Questo mi fa pensare a parecchi altri attacchi realizzabili tramite questa tecnica, anche più pericolosi di un phishing... considerando che non servono privilegi elevati e che sono attacchi cross-platform... c'è da mettersi le mani nei capelli!

Ah, dimenticavo. Forse non hai notato un'altra chicca.
Il forum codifica prima di inviare i dati di login, fa l'md5 hash, come puoi vedere dalla sorgente della pagina di login.
Il bello e' che con il sistema mostrato, i dati di login vengono catturati in chiaro prima che i dati vengano cryptati e inviati. :D

Non ho notato l'hash, però davo per scontato che i dati catturati fossero in chiaro :)

[sampei.nihira]

Sono fuori casa con portatile e connessione cellulare.
Ho fatto velocemente una prova,senza leggere troppo non ho tempo.
Il risultato è che non succede nulla.
Nessun intervento dell'antivirus.
Nessun avviso di phishing da parte di Opera (Ho la protezione antifrode attiva).

[Sisupoika]

mmm questa situazione mi pare vagamente familiare :D
Questa volta però conto sul fatto che se il browser in qualche modo la decifra, ci riesco pure io osservando quello che fa (a costo di usare un debugger ;) della serie, sempre meno applicabile in un contesto reale :D )


wget riesce ancora a scaricare i js, basta lanciarlo con l'opzione "-r"

Hai ragione, tenendo in mente il sistema completo non avevo pensato che con quello live il javascript viene ritornato direttamente e quindi col download recorsivo, e la gestione della sessione, essi vengono scaricati ugualmente.
Ovviamente se il javascript finale da decrittografare viene aggiunto alla pagina con Ajax, e non direttamente, esso ha dunque bisogno di essere eseguito nel browser, quindi con wget e simili non dovrebbero esserci modi per salvarlo, almeno che io sappia. Tu ne conosci? :)

Si, lo credo pure io.
web 2.0... bellissimo da vedere ma una bestia nera da trattare.

Finche' piace la torta, la cigliegina ci sara' sempre. E non e' detto che essa sia sempre dolce :D

Ecco, questo si che taglierebbe le gambe agli sniffer :) a quel punto dovrei debuggare l'esecuzione del browser o modificarlo in modo che salvi il traffico in chiaro su un file di log :D (della serie... allegria!!! chi non fa una cosa del genere prima di aprire un sito!! :D)

LOL, praticamente tutti, no? :D
Cmq fare il trucchetto con SSL sarebbe troppo facile :p
Per questo sto andando avanti e sbattendo la testa per il mio sistema. E' piu' divertente, no? :Prrr:

Questo mi fa pensare a parecchi altri attacchi realizzabili tramite questa tecnica, anche più pericolosi di un phishing... considerando che non servono privilegi elevati e che sono attacchi cross-platform... c'è da mettersi le mani nei capelli!

Se pensi che con quel sistema anche l'avvio dell'homebanking di HSBC funziona, allora mettiti per davvero le mani nei capelli! :D
Il loro sistema mi ha bloccato nel momento in cui devo inserire tre caratteri a caso di una parola chiave di controllo da me impostata. Con quello di Lloyds (il mio secondo account, anche se e' perennemente vuoto e lo devo chiudere :D), stessa cosa: anzi mentre con HSBC devi inviare ogni volta che inizi una sessione - prima dei caratteri casuali - la stringa identificativa del cliente, Lloyds usa i cookies per la prima fase, quindi ancora piu' semplice col web proxy rudimentale che stavo scrivendo. Anche Lloyds comunque mi ha bloccato ovviamente nel momento in cui bisogna inserire i caratteri casuali presi - stesso sistema - da una stringa chiave assegnata a quell'id utente.
Per fortuna! Se fossi riuscito cosi', su due piedi, a passare anche il secondo controllo, mi sarei cagato sotto dalla paura di scoprire che non era cosi' difficile bypassare le protezioni di due degli homebanking piu' usati in UK e US! :D
Anche se, come per tutte le cose, sono abbastanza sicuro che se uno non si limita a fare soltanto delle prove per studio per gioco come me, e dedica tempo e risorse a studiare i loro sistemi con cattive intenzioni, sicuramente prima o poi ne verra' a capo. ;)

Cmq vi interessa se apro un thread dove possiate sperimentare questo web proxy? :D
Ovviamente devo sistemare del codice prima visto che era una prova e il codice e' orrendo. E dovrei metterlo sull'hosting.

Non ho notato l'hash, però davo per scontato che i dati catturati fossero in chiaro :)

Pero' a me fa ridere il discorso che i dati vengono crittografati prima dell'invio, per renderli sicuri durante il trasporto... mentre essi sono catturabili abbastanza facilmente prima di quella operazione. :)

[Sisupoika]

Sono fuori casa con portatile e connessione cellulare.
Ho fatto velocemente una prova,senza leggere troppo non ho tempo.
Il risultato è che non succede nulla.
Nessun intervento dell'antivirus.
Nessun avviso di phishing da parte di Opera (Ho la protezione antifrode attiva).


LOL stavo pensando che, voglio dire, "sampei il pescatore" ci sta bene in un thread sul phishing, eh? :D

[Sisupoika]

WS, ho provato a spostare tutto su un altro dominio

(il nuovo indirizzo e' http://www.sisulabs.com/HardwareUpgrade/NonCliccateSuQuelLink.aspx )

e il comportamento e' uguale, anche se ho risolto almeno un paio di cose; al momento pero' sto sperimentando altre cose, e ho aggiornato il test cosi':

- messo un solo javascript esterno che si autentica con due chiavi, invece di tre pezzi di javascript a catena autenticati con un id numerico e una chiave

- eliminato il caricamento del javascript diretto nella pagina, sostituendolo con una richiesta Ajax (recuperando parte del sistema iniziale)

Con queste modifiche, non cambia nulla per quanto riguarda il discorso della simulazione di phishing, mentre sto ignorando per un attimo lo sniffing (il javascript e' al momento in chiaro, cerchero' in seguito di ripristinare in maniera diversa il sistema a loop con la crittografia, sperando di non incontrare problemi col server) e giocando un po' col discorso di wget & curl.

Con la nuova versione del test, il Javascript dovrebbe essere caricabile soltanto da un browser vero che lo puo' eseguire, mentre non dovrebbe essere possibile - forse mi sbaglio o mi sfugge qualche comando :) - scaricare il Javascript con wget e curl.

Faresti qualche prova? :)

Ah, ho eliminato tutte le variabili di controllo sia dalla session sia dalla application! :D
Quindi in teoria non dovrebbe essere possibile autenticare delle chiavi e riconoscere da quale sessione/richiesta esse provengono, ma ho trovato un altro sistema molto piu' semplice e anche veloce.
Vediamo se indovini come :D
Spunto: dopo il caricamento della pagina iniziale, e del javascript con ajax, una persona che voglia provare a vedere il codice Javascript nascosto (come dicevo dimentica per un attimo lo sniffing) avrebbe solo 10 secondi (LOL, timeout da me impostabile, potrei anche ridurlo) per:

- visualizzare il sorgente della pagina
- trovare le due chiavi generate per questa richiesta
- aprire js.aspx nel browser
- passare le due chiavi come parametri manualmente
- leggere il codice..

:D


Dopo questo provo a ripristinare la web request dinamica del semi-web-proxy per caricare il fake forum, invece di usare un file statico come adesso, e a ovviare ai problemi riscontrati provando altre strade per implementare la parte della crittografia.

[sampei.nihira]

LOL stavo pensando che, voglio dire, "sampei il pescatore" ci sta bene in un thread sul phishing, eh? :D


:D :D :D

Bravo Sisu,ecco un esempio di umorismo "inglese" ;) :D :D

Anche usando la funzione di Opera della "convalida dei sorgenti on line"......non c'è alcuna differenza.
Il test, per me, è un "perfetto tranello".
Concordo che occorre implementare una funzione protettiva nei browser migliore !!

Anche io penso che la maggior parte degli utenti non usi disabilitare i javascript,ad esempio
in Opera tale funzione è abilitata di default e bisogna disabilitarla.
E poi abilitare i singoli link che malfunzionano.
Ma l'utente medio solitamente usa I.E. ed anche se usa Opera non fà certamente quello di cui sopra.
Che però occorre dire è certamente una protezione ulteriore nel caso di pagine web abilmente simulate.

Sarei curioso di sapere cosa farebbero gli esperti di phish tank segnalando il sito trappola come "non affidabile"
ma questa volta io non lo faccio !!

[Gianky....! :D :)]

Ank'io ho fatto velocemente il test ed in effetti non appare nessun avviso nè dell'av nè di firefox e co.:D
Cmq mi rendo sempre più conto di quanto sia importante noscript!;)
Ciao

[Sisupoika]

:D :D :D

Bravo Sisu,ecco un esempio di umorismo "inglese" ;) :D :D

Anche usando la funzione di Opera della "convalida dei sorgenti on line"......non c'è alcuna differenza.
Il test, per me, è un "perfetto tranello".
Concordo che occorre implementare una funzione protettiva nei browser migliore !!

Anche io penso che la maggior parte degli utenti non usi disabilitare i javascript,ad esempio
in Opera tale funzione è abilitata di default e bisogna disabilitarla.
E poi abilitare i singoli link che malfunzionano.
Ma l'utente medio solitamente usa I.E. ed anche se usa Opera non fà certamente quello di cui sopra.
Che però occorre dire è certamente una protezione ulteriore nel caso di pagine web abilmente simulate.

Sarei curioso di sapere cosa farebbero gli esperti di phish tank segnalando il sito trappola come "non affidabile"
ma questa volta io non lo faccio !!



Grazie per i test ;)
Cmq non serve a nulla segnalare la mia pagina perche' e' solo una simulazione e vedrebbero che non si tratta di un phishing vero. L'unico effetto che otterresti e' quello di far classificare inutilmente quel link come phishing, nel caso loro non controllino bene :p
E ovviamente mi faresti perdere tempo nel caso debba poi contattarli, spiegare la questione, e far eliminare il link dal loro database. Quindi evita ;)
Con Antivir la storia e' diversa: avevi fatto bene a segnalare per vedere sia quanto rapidamente reagiscono, sia come avrebbero interpretato quel tipo di codice Javascript, senza rischiare un inutile blacklisting. :)

Ank'io ho fatto velocemente il test ed in effetti non appare nessun avviso nè dell'av nè di firefox e co.:D
Cmq mi rendo sempre più conto di quanto sia importante noscript!;)
Ciao


Grazie anche a te per le prove. Cmq fatemi sapere anche in quali condizioni software, protezioni, ecc. le avete fatte. :)

[ShoShen]

ciao gianky ...oltre a no script in casi come questo si rivela piuttosto utile anche il site advisor di mcafee...infatti durante la normale navigazione cambia colore in relazione all affidabilità del sito ...in caso di redirezione verso un sito esca del tutto uguale (almeno in apparenza ) all originale site advisor segnalerà il sito come sconosciuto ( a patto che l originale sia stato testato precedentemente si noterà una diversa classificazione di rischio )...da segnalare anche l utilità di trend protect di trend micro e haute secure (per lo stesso principio...) il punto debole di questi software sta come al solito nella variabile utente che non sempre controlla l attendibilità del sito prima di immettere dati sensibili...ciao:)

[Gianky....! :D :)]

ciao gianky ...oltre a no script in casi come questo si rivela piuttosto utile anche il site advisor di mcafee...infatti durante la normale navigazione cambia colore in relazione all affidabilità del sito ...in caso di redirezione verso un sito esca del tutto uguale (almeno in apparenza ) all originale site advisor segnalerà il sito come sconosciuto ( a patto che l originale sia stato testato precedentemente si noterà una diversa classificazione di rischio )...da segnalare anche l utilità di trend protect di trend micro e haute secure (per lo stesso principio...) il punto debole di questi software sta come al solito nella variabile utente che non sempre controlla l attendibilità del sito prima di immettere dati sensibili...ciao:)

Infatti uso il Finjan security broswing estensione per firefox che ha la stessa funzione del mcafee site advisor(ed è anche più affidabile) ;)
Ciao

[Gianky....! :D :)]

Grazie anche a te per le prove. Cmq fatemi sapere anche in quali condizioni software, protezioni, ecc. le avete fatte. :)

Prego cmq usavo:
Firefox 2.0.0.7 + noscript + finjan security broswing e roba anti-pubblicità...
Kaspersky internet security 7.0.0.125 (euristica al massimo)
Avg anti-spyware 7.5.1.43
O.S. Xp aggiornato all'ultima patch.

Risultato:Silenzio totale:O

CIao

P.S. Prevx era disattivato ma non penso sarebbe stato di aiuto.

[PrezerDj]

Io ho usato opera l'ultima versione e kis ultima versione e mi apre la pagina senza dire nulla....:mc:

[Sisupoika]

Ragazzi aspettate un attimo perche' a breve penso avro' degli sviluppi :D

[W.S.]

Ecchime :)
Personalmente non conosco alcun robot in grado di eseguire codice ajax, l'ultimo upgrade annulla il loro effetto "base" (spiego poi) infatti wget non è più in grado di scaricare i js, si ferma alla prima pagina (modificando i referer).

Dico effetto "base" perché, con un pochino di lavoro ulteriore è possibile aggirare il problema scrivendosi degli script che interpretano la pagina scaricata dal robot ed eseguono la request corretta ottenendo i js (cosa che farò appena avrò un pochino di tempo). Ovviamente stiamo parlando di ambienti di test, questi script dovrebbero essere costruiti appositamente oppure bisognerebbe integrare un interprete ajax nei robot ma a ste punto si fa prima a modificare un browser open-source.

Comunque credo che il sistema completo che hai previsto sia estremamente offuscato, non impossibile da decifrare (ovviamente, altrimenti nemmeno il browser saprebbe interpretare le pagine e gli script) ma davvero... problematico per un difensore.

Ora mi salvo un po di dati (giusto 3-4 pagine) e appena ho tempo faccio uno scriptino che scarica i js.

P.S.: inizio ad essere allergico alle stringhe della forma 59930e1b-7014-4cdb-b597-d73efb1f3661 :D

[sampei.nihira]

Ragazzi aspettate un attimo perche' a breve penso avro' degli sviluppi :D

Visto che W.S. ha fatto la prova LINUX con FF io adesso che sono al pc,volevo fare il test con Linux ma Opera 9.23 come browser predefinito.
Ma la pagina di test è in "manutenzione"......
Comunque credo sia inutile questa ulteriore prova....

Si ribadisco che non segnalo nulla,tranquillo !! ;)

[ShoShen]

rag ho paura che qui alla fine l unico browser che ne esca vittorioso sia internet explorer :wtf: infatti cliccando sul link dovrebbe aprire la pagina in una nuova finestra ( mi sembra che questa opzione sia abilitata di default) evitando cosi la redirezione ...

[W.S.]

rag ho paura che qui alla fine l unico browser che ne esca vittorioso sia internet explorer :wtf: infatti cliccando sul link dovrebbe aprire la pagina in una nuova finestra ( mi sembra che questa opzione sia abilitata di default) evitando cosi la redirezione ...

LOL, appena il test è on-line vediamo :D

[sampei.nihira]

LOL, appena il test è on-line vediamo :D

Si infatti !! :D
Io, invece, se fossi un "affezionato FF" proverei le nuove doti della nuova versione:

http://www.mozilla.org/projects/firefox/3.0a8/releasenotes/

[Sisupoika]

Ecchime :)
Personalmente non conosco alcun robot in grado di eseguire codice ajax, l'ultimo upgrade annulla il loro effetto "base" (spiego poi) infatti wget non è più in grado di scaricare i js, si ferma alla prima pagina (modificando i referer).

:D

(ps: perche' hai avuto bisogno di modificare il referer?)

Dico effetto "base" perché, con un pochino di lavoro ulteriore è possibile aggirare il problema scrivendosi degli script che interpretano la pagina scaricata dal robot ed eseguono la request corretta ottenendo i js (cosa che farò appena avrò un pochino di tempo). Ovviamente stiamo parlando di ambienti di test, questi script dovrebbero essere costruiti appositamente oppure bisognerebbe integrare un interprete ajax nei robot ma a ste punto si fa prima a modificare un browser open-source.

:cool:

Cioe' devi prepararti un browser apposta, lo fanno tutti, no? :D

Comunque credo che il sistema completo che hai previsto sia estremamente offuscato, non impossibile da decifrare (ovviamente, altrimenti nemmeno il browser saprebbe interpretare le pagine e gli script) ma davvero... problematico per un difensore.

Col sistema completo, che sto rimettendo un pezzo alla volta - anzi riscrivendo qualcosa - al momento l'unica soluzione che mi verrebbe in mente sarebbe scriversi un browser apposta :D

Ora mi salvo un po di dati (giusto 3-4 pagine) e appena ho tempo faccio uno scriptino che scarica i js.

Ok, ma anche se scrivi uno script che faccia le richieste e scarichi gli script, devi passare delle chiavi come parametri, chiavi che devono essere valide e possono essere generate solo dalla mia libreria (sul mio sito, dunque), quindi senza di essa mi chiedo come farai. Inoltre, ogni chiave espira (da settaggi correnti, che posso cambiare in ogni momento) in 10 secondi, e c'e' uno scarto (configurabile anche esso) di 1 secondo tra una chiave e un'altra.
Come se non bastasse, ho gia' previsto (e iniziato a scrivere) le modifiche per rendere questi parametri (vita di una chiave e scarto tra l'una e l'altra) modificati automaticamente ad ogni richiesta, in maniera casuale, senza invalidare tutta la procedura.
Come fara' il tuo script? Non devi comunque scrivere qualcosa che si comporti come un browser, esegue il codice ajax, e dunque puo' scaricare gli script?
Forse mi sfugge la tua idea. :)

P.S.: inizio ad essere allergico alle stringhe della forma 59930e1b-7014-4cdb-b597-d73efb1f3661 :D

E di' grazie che per evitare problemi di encoding (am lazy :D) ecc ho evitato i simboli e caratteri speciali :sbonk:

Visto che W.S. ha fatto la prova LINUX con FF io adesso che sono al pc,volevo fare il test con Linux ma Opera 9.23 come browser predefinito.
Ma la pagina di test è in "manutenzione"......
Comunque credo sia inutile questa ulteriore prova....

Si ribadisco che non segnalo nulla,tranquillo !! ;)


Ieri ho dovuto disattivare la pagina perche' stavo facendo ulteriori "esperimenti" e poi sono uscito. Stasera sul tardi provo a riprendere perche' ho trovato qualcos'altro di interessante mentre facevo queste prove...diciamo uno spunto per una nuova cosa. :D

rag ho paura che qui alla fine l unico browser che ne esca vittorioso sia internet explorer :wtf: infatti cliccando sul link dovrebbe aprire la pagina in una nuova finestra ( mi sembra che questa opzione sia abilitata di default) evitando cosi la redirezione ...

Di che parli? Non c'e' nessuna redirezione. :D
E quale nuova finestra?? :confused: Ma quale pagina hai visitato tu? :D

Si infatti !! :D
Io, invece, se fossi un "affezionato FF" proverei le nuove doti della nuova versione:

http://www.mozilla.org/projects/firefox/3.0a8/releasenotes/


Built in malware protection
uhm...

[Sisupoika]

WS, dimentica la domanda sul referer, avevo dimenticato di aver messo quel controllo per la ragione delle segnalazioni ecc :D

[Chukie]

Scusa la domanda (mezza affermazione) che sto per fare:

ok, stai dimostrando di essere esperto e tutte le modifiche tecniche che stai facendo per offuscare gli script sono molto carine e tutto...ma al fine della tecnica di reindirizzamento e di modifica dell'href automatico quello che dovevi dire l'hai detto da un pezzo. In altre parole: è possibile la modifica dell'href in maniera automatica nel caricamento di una pagina web in modo tale che il link, che prima sembrava dovesse portare ad un server, porta in realtà ad un altro. Stop.

Basta (parlo ovviamente in linea teorica visto che nessuno dei browser lo fa) monitorare il campo href prima e dopo il caricamento e vedere se coincidono le cose, altrimenti c'è qualcosa che non va. Il resto mi sembra un po esclusivamente l'ostentare un livello di conoscenze non comune agli altri :) Scusa, sono un po diretto di solito ma penso che sia il modo migliore per chiarirsi sempre con gli altri.

[W.S.]

scusate se rispondo in fax-mode ma son di fretta...

x Sisupoika: l'idea dello script è ricalcare l'esecuzione di un browser, non mi serve sapere come vengono create le stringhe, mi basta fingermi un browser e percorrere i sui passi. E' + semplice di ricrearsi o modificare un browser ma l'effetto è identico.

x Chukie: per come la vedo io, più si approfondisce la cosa meglio si capisce come contrastarla, in parallelo ai test sto pensando al modo migliore per contrastare l'attacco. Ad esempio, se Sisupoika si fosse limitato al primo test, avremmo potuto usare la cache per la difesa, cosa che si sarebbe dimostrata un errore. Se non offuscasse il codice si potrebbe pensare di usare un proxy-firewall mentre s'è visto in questo test che per funzionare dovrebbe essere in grado di interpretare codice ajax.
La soluzione migliore sembra quella di intervenire all'interno del browser ma prima di scrivere un modulo bisogna capire se basta controllare i link, come verificarli, come avvertire l'utente e come intervenire.

[Sisupoika]

Scusa la domanda (mezza affermazione) che sto per fare:

ok, stai dimostrando di essere esperto e tutte le modifiche tecniche che stai facendo per offuscare gli script sono molto carine e tutto...

Non sto dimostrando nulla e non ne sento il bisogno. Volevo solo rendervi partecipi di mie opinioni, idee, prove, "esperimenti" o chiamali come ti pare.
Ma se questo e' cio che pensate, che sto "dimostrando di essere esperto" mi fermo qui e lascio ad altri questi panni perche' non sono solito indossarne.
Non me l'ha prescritto il dottore di scrivere in un forum.
Se poi qui e' lecito/gradito parlare solo di antivirus, hips, sondaggi e sondaggini, allora chiedo venia: ho sbagliato forum.

ma al fine della tecnica di reindirizzamento e di modifica dell'href automatico quello che dovevi dire l'hai detto da un pezzo. In altre parole: è possibile la modifica dell'href in maniera automatica nel caricamento di una pagina web in modo tale che il link, che prima sembrava dovesse portare ad un server, porta in realtà ad un altro. Stop.

Basta (parlo ovviamente in linea teorica visto che nessuno dei browser lo fa) monitorare il campo href prima e dopo il caricamento e vedere se coincidono le cose, altrimenti c'è qualcosa che non va.

Non si tratta solo dell'href, se hai inteso cio', non hai afferrato il messaggio per intero. Primo: i link erano solo un esempio, in realta' le possibilita' sono diverse; secondo: 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.

Finche' c'e' Javascript, le possibilita' sono molte e ci si puo' sbizzarrire; da cui la difficolta' a prevenire problemi di questo tipo, che questo thread vuole denunciare.

E anche la storia del nascondere il Javascript ha un senso in merito, che purtroppo pare ti sia sfuggito: se del Javascript compie operazioni che non dovrebbe in un modo che non allerti un utente (nell'esempio del link, la status bar e il sorgente della pagina mostrano il link atteso, non quello fake), e per di piu' questo Javascript e' ben nascosto a livello tale che dovresti addirittura scriverti qualcosa ad hoc per scoprirlo, allora siamo di fronte ad un problema abbastanza serio - IMHO - che viene ignorato perche' forse in realta' non risolvibile a meno di ripensare ad un bel po' di cose.

E' questo che sto cercando di far presente, non di dimostrare di essere chissa' che.

Fra l'altro ho presentato questo sistema anche come un utile giochetto per evitare il grabbing di email addresses da pagine web, che non ha nulla a che fare con il phishing.

Voglio dire: si cerca di parlare di molto piu' che un semplice attributo href, ma vedo che non hai notato qualcosa, nell'insieme.

Il resto mi sembra un po esclusivamente l'ostentare un livello di conoscenze non comune agli altri :) Scusa, sono un po diretto di solito ma penso che sia il modo migliore per chiarirsi sempre con gli altri.

Ecco, questi sono commenti che ancora una volta mi fanno passare la voglia di scrivere (come gia' capitato nell'altro thread).


scusate se rispondo in fax-mode ma son di fretta...

x Sisupoika: l'idea dello script è ricalcare l'esecuzione di un browser, non mi serve sapere come vengono create le stringhe, mi basta fingermi un browser e percorrere i sui passi. E' + semplice di ricrearsi o modificare un browser ma l'effetto è identico.

Ok, pensavo ti riferissi a qualcos'altro :)
Domanda: cosa penseresti se il Javascript fosse poliforme?

x Chukie: per come la vedo io, più si approfondisce la cosa meglio si capisce come contrastarla, in parallelo ai test sto pensando al modo migliore per contrastare l'attacco. Ad esempio, se Sisupoika si fosse limitato al primo test, avremmo potuto usare la cache per la difesa, cosa che si sarebbe dimostrata un errore. Se non offuscasse il codice si potrebbe pensare di usare un proxy-firewall mentre s'è visto in questo test che per funzionare dovrebbe essere in grado di interpretare codice ajax.
La soluzione migliore sembra quella di intervenire all'interno del browser ma prima di scrivere un modulo bisogna capire se basta controllare i link, come verificarli, come avvertire l'utente e come intervenire.

Esatto, e in questo caso vale il discorso che facevo prima: e' possibile modificare un link in millemila modi, non solo attraverso l'href. :)
Un browser, o quello che e', non penso avrebbe - con tecnologie attuali - intelligenza tale da capire cosa accade se le possibilita' sono cosi' numerose (senza parlare di codice offuscato e poliforme, che cambi ad ogni esecuzione, ecc ecc)

[W.S.]

Domanda: cosa penseresti se il Javascript fosse poliforme?

Bella domanda, ci stavo pensando proprio ieri quando ho accennato alla scrittura di script. Sarebbe un bel problema, significherebbe dover intervenire in modi ben più complicati.
Codice polimorfico significa niente signature, quindi significa intervenire senza considerare il codice javascript (analizzarlo in real time è improponibile). In pratica significa trovare un altro modo per capire se l'esecuzione del link è da considerare lecita o meno.

Ad esempio potrebbe aiutare un modulo che
1) prima di eseguire la request, verifica la corrispondenza tra link visualizzato dalla barra e ip a cui il browser si sta connettendo
2a) se gli indirizzi corrispondono, esegue la request e procede.
2b) se gli indirizzi non corrispondono, notifica l'anomalia all'utente e attende conferma prima di procedere.
Purtroppo pure questa soluzione ha più di un difetto e ho il sospetto che possa generare dai falsi positivi oltre che rallentamenti dovuti alle richieste DNS.

Utilizzare la stessa procedura usata da "apri in un altro tab" significa impedire a javascript la modifica dei link, purtroppo credo proprio significhi "castrare" alcune funzionalità di siti con menu web2.0 particolari ma perfettamente leciti.

Alla fine il problema vero è che i browser visualizzano nella status bar un indirizzo errato pur conoscendo quello giusto (per trovarlo gli basterebbe eseguire il link interrompendo la richiesta prima di inviarla e verificare i parametri della richiesta), quindi penso che sia il browser ad andare modificato, costruire "pezze" attorno al problema non risolverebbe la situazione alla radice.

[Sisupoika]

Bella domanda, ci stavo pensando proprio ieri quando ho accennato alla scrittura di script. Sarebbe un bel problema, significherebbe dover intervenire in modi ben più complicati.
Codice polimorfico significa niente signature, quindi significa intervenire senza considerare il codice javascript (analizzarlo in real time è improponibile). In pratica significa trovare un altro modo per capire se l'esecuzione del link è da considerare lecita o meno.

Ad esempio potrebbe aiutare un modulo che
1) prima di eseguire la request, verifica la corrispondenza tra link visualizzato dalla barra e ip a cui il browser si sta connettendo
2a) se gli indirizzi corrispondono, esegue la request e procede.
2b) se gli indirizzi non corrispondono, notifica l'anomalia all'utente e attende conferma prima di procedere.
Purtroppo pure questa soluzione ha più di un difetto e ho il sospetto che possa generare dai falsi positivi oltre che rallentamenti dovuti alle richieste DNS.

Utilizzare la stessa procedura usata da "apri in un altro tab" significa impedire a javascript la modifica dei link, purtroppo credo proprio significhi "castrare" alcune funzionalità di siti con menu web2.0 particolari ma perfettamente leciti.

Alla fine il problema vero è che i browser visualizzano nella status bar un indirizzo errato pur conoscendo quello giusto (per trovarlo gli basterebbe eseguire il link interrompendo la richiesta prima di inviarla e verificare i parametri della richiesta), quindi penso che sia il browser ad andare modificato, costruire "pezze" attorno al problema non risolverebbe la situazione alla radice.

Sono d'accordo su tutto, comunque e' possibile aggirare anche il tasto destro :)