Non cliccate su quel link - Parte Seconda.

[Sisupoika]

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" ( ) 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

Trovate il test Qui.

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

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"

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.
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?"
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"
Ma che azz vuol dire? .NET e' fantastico ma non immune alle cazzate di mamma Ms in merito ai messaggi di errore, mai helpful

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 ( ) 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.]

Originariamente inviato da Sisupoika

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

Originariamente inviato da Sisupoika

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

Originariamente inviato da Sisupoika

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"
Ma che azz vuol dire? .NET e' fantastico ma non immune alle cazzate di mamma Ms in merito ai messaggi di errore, mai helpful

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.

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.

Originariamente inviato da Sisupoika

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!

Originariamente inviato da Sisupoika

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

La rende anche troppo bene!

[Sisupoika]

Originariamente inviato da W.S.

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.
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
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 ( ) 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 ) 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!
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.

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.

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.

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

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.

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.

Sempre a disposizione per verificare il sistema!

Ci contavo

La rende anche troppo bene!

[W.S.]

Originariamente inviato da Sisupoika

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.

mmm questa situazione mi pare vagamente familiare
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 )

Originariamente inviato da Sisupoika

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"

Originariamente inviato da Sisupoika

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.

Originariamente inviato da Sisupoika

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 (della serie... allegria!!! chi non fa una cosa del genere prima di aprire un sito!! )

Originariamente inviato da Sisupoika

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!

Originariamente inviato da Sisupoika

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.

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]

Originariamente inviato da W.S.

mmm questa situazione mi pare vagamente familiare
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 )

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

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 (della serie... allegria!!! chi non fa una cosa del genere prima di aprire un sito!! )

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

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!
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 ), 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!
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?
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]

Originariamente inviato da 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).

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

[Sisupoika]

WS, ho provato a spostare tutto su un altro dominio

(il nuovo indirizzo e' http://www.sisulabs.com/HardwareUpgr...uQuelLink.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!
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
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..




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]

Originariamente inviato da Sisupoika

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

Bravo Sisu,ecco un esempio di umorismo "inglese"

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.
Cmq mi rendo sempre più conto di quanto sia importante noscript!
Ciao

[Sisupoika]

Originariamente inviato da sampei.nihira

Bravo Sisu,ecco un esempio di umorismo "inglese"

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

Originariamente inviato da Gianky....! :D :)

Ank'io ho fatto velocemente il test ed in effetti non appare nessun avviso nè dell'av nè di firefox e co.
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.

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

Originariamente inviato da 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

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

Originariamente inviato da Sisupoika

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

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

[Sisupoika]

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

[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