Phishing, l'attacco ora è real-time

I password-token forniti dagli istituti di credito per i servizi di e-banking salvano dai phisher? Non sempre: girano le prime aggressioni che neutralizzano questo fattore di sicurezza aggiuntiva

Los Angeles (USA) - Gli esperti di Secure Science Corporation hanno descritto nelle scorse ore un nuovo tipo di attacco utilizzato nelle operazioni di "phishing", le truffe telematiche che solitamente colpiscono gli utenti dei servizi di e-banking.

L'attacco in cui si sono imbattuti i ricercatori è studiato per neutralizzare la sicurezza aggiuntiva fornita dai password-token, i dispositivi prodotti da RSA ed altre imprese che, sincronizzati coi server centrali della banca, forniscono una nuova password ad intervalli regolari.

Alcuni phisher sono infatti riusciti a creare pagine-trappola dove gli utenti ignari vengono spinti ad inserire tutti i dati necessari all'autenticazione bancaria: numero di conto, password personale e codice numerico generato dal token. Attraverso un sofisticato script, i phisher si connettono in tempo reale alla banca della vittima e sfruttano il codice generato dal token prima che diventi inefficace. In questa finestra temporale, che può durare anche solo pochi secondi, i truffatori sarebbero in grado di trasferire fondi o effettuare qualsiasi altro tipo di operazione bancaria.
"Questo tipo di attacchi può essere utilizzato per rendere inefficace qualsiasi tipo di sistema di sicurezza a doppia chiave", dicono gli esperti di F-Secure. I tecnici di Symantec sono più ottimisti: "È molto difficile che questo tipo di attacchi sofisticati, almeno per il momento, possano diventare estremamente diffusi". C'è solo una banca che finora è stata attaccata in questo modo e si tratta dell'americana Citibank. Quando gli attacchi "in tempo reale" prenderanno piede, avverte però Zulfikar Ramzan di Symantec, "i password-token diventeranno quasi inutili".
34 Commenti alla Notizia Phishing, l'attacco ora è real-time
Ordina
  • Ma se le banche invece di dare quei stupidi password-token incominciassero ad usare le smart card o le chiavette usb fatte apposta si risolverebbero una volta per tutte stì maledetti attacchi...

    Con le smart card per autenticarsi nel sito della banca bisognerebbe proprio averla fisicamente, perchè la chiave privata che usa la banca per indentificarti è lì dentro e non si può tirare fuori, quindi è impossibile che i phisher riescano a prenderla. Occhiolino

    Oppure più semplicemente basta che la banca dice a tutti gli utenti di controllare che la pagina dove sono sia protetta con l'ssl prima di scrivere le loro password, ma purtroppo rimane sempre quel 20% di utonti che non lo faranno mai Perplesso
    non+autenticato
  • > Oppure più semplicemente basta che la banca dice
    > a tutti gli utenti di controllare che la pagina
    > dove sono sia protetta con l'ssl prima di
    > scrivere le loro password, ma purtroppo rimane
    > sempre quel 20% di utonti che non lo faranno mai
    >Perplesso

    illuso... io credo che l'80% non lo farebbe mai!!!

    bye
    non+autenticato
  • che tenga.
    Perche' se gli arriva una mail dalla sua banca dicendo che deve sfregare le chiappe sul monitor lo fa senza pensarci due volte. Deluso
    non+autenticato

  • - Scritto da:
    > che tenga.
    > Perche' se gli arriva una mail dalla sua banca
    > dicendo che deve sfregare le chiappe sul monitor
    > lo fa senza pensarci due volte.
    >Deluso

    Oops, quindi non avrei dovuto farlo? Occacchio.Imbarazzato
    non+autenticato

  • - Scritto da:
    > che tenga.
    > Perche' se gli arriva una mail dalla sua banca
    > dicendo che deve sfregare le chiappe sul monitor
    > lo fa senza pensarci due volte.
    >Deluso

    winutonto?
    non+autenticato
  • La banca odveva usare un sito fatto molto male

    La mia banca mi chiede di effettuare l'inserimento del codice del token solo nel momento in cui faccio un pagamento/operazione non quando faccio login.

    Pre questo non basta mettere su un portale finto, ma devi mirrorare tutto un sito o almeno una sua parte significativa, ora se io entro loro come fanno a farmi vedere le pagine interne con i miei dati del conto senza avere questi dati? (L'utente deve proprio essere scemo a no accorgersi che i saldo è diverso!)

    Se un sito è fatto il token è sicuro.
    Per fatto bene deve intendo

    - protetto da wrapper
    - criptato con abbastanza bit
    - protetto da sql injection

    non+autenticato
  • Sono molto felice di vedere che finalmente qualcuno si è accorto delle vulnerabilità dei password-token.

    E' quasi un anno che sto lavorando ad un sistema di stronmg autenthentication alternativo basato su One Time Password che sia invulnerabile al phishing.
    In pratica la password (che in questo caso può essere usata solo una volta ed ha un validità temporale limitata) viene generata da un cellulare Java Enabled (su cui è stato installato uno speciale software di generazione).

    Si tratta in relatà di un sistema tipo challenge-response dove il response, che è la One Time Password, viene generata dal cellulare a partire dal challenge sfruttando la crittografia delle curve ellittiche.
    Per questo motivo, anche l'ultimo attacco rivolto ai password-token sarebbe inefficace.

    Una demo è disponibile a:
    http://www.hostingjava.it/-monkeybs

    Per provarlo occorre registrarsi e farsi spedire il software per il cellulare via SMS.

    Per maggiori info visitate il mio sito:
    http://www.ugosweb.com

    Ciao,

    Ugo Chirico
    http://www.ugosweb.com

  • > Si tratta in relatà di un sistema tipo
    > challenge-response dove il response, che è la One
    > Time Password, viene generata dal cellulare a
    > partire dal challenge sfruttando la crittografia
    > delle curve
    > ellittiche.
    > Per questo motivo, anche l'ultimo attacco rivolto
    > ai password-token sarebbe
    > inefficace.

    Non mi risulta che il tuo sistema ti protegga dal MIM attack.

    Se l'utente clicca sul link di phishing, il server truffatore può connettersi alla banca la quale gli lancia il challange (diciamo "X1B3Z4") il server-truffa propone "X1B3Z4" all'utente il quale convinto di parlare con la banca gli calcola il response (diciamo "Q9D1V7") col tuo sistema. Ora il server truffa manda "Q9D1V7" alla banca e l'autenticazione è già fatta.






    > Una demo è disponibile a:
    > http://www.hostingjava.it/-monkeybs
    >
    > Per provarlo occorre registrarsi e farsi spedire
    > il software per il cellulare via
    > SMS.
    >
    > Per maggiori info visitate il mio sito:
    > http://www.ugosweb.com
    >
    > Ciao,
    >
    > Ugo Chirico
    > http://www.ugosweb.com
    non+autenticato
  • E' già, è probabilissimo che accada, magari in una notte di plenilunio,davanti al castello di Grayskull, con la spada stagliata di fronte al cielo e gridando casualmente: "A me il potere!".
    Dai siamo seri, quante probabilità ci sono che succeda una cosa come questa? Già mi sembra incasinato il discorso token, figuriamoci con il sistema del cellulare....
    -----------------------------------------------------------
    Modificato dall' autore il 14 luglio 2006 11.40
    -----------------------------------------------------------
    4724

  • - Scritto da: Ics-pi

    > Dai siamo seri, quante probabilità ci sono che
    > succeda una cosa come questa? Già mi sembra
    > incasinato il discorso token, figuriamoci con il
    > sistema del
    > cellulare....


    Ha più o meno la stessa complicazione dell'attacco al sistema con token. Richiede solo la scrittura di uno script neanche tanto complesso.
    non+autenticato
  • > Ha più o meno la stessa complicazione
    > dell'attacco al sistema con token. Richiede solo
    > la scrittura di uno script neanche tanto
    > complesso.

    Boh ho visto diverse fake pages e non ci sarei cascato nemmeno morto (lo so che non esisto solo io sul web, ma faccio l'esempio della mia esperienza).
    1 I collegamenti non funzionavano correttamente
    2 I link erano strampalati e verso IP invece che verso nomi di dominio con delle cartelle/pagine proprio fantasiose
    3 La grammatica poco corretta
    4 Le motivazioni molto flebili, poco credibili

    Ovvio che, come dicevo sopra, magari la signora Pina ci potrebbe pure cascare...speriamo non attivi mai l'home banking. A bocca storta
    4724
  • > 1 I collegamenti non funzionavano correttamente
    > 2 I link erano strampalati e verso IP invece che
    > verso nomi di dominio con delle cartelle/pagine
    > proprio
    > fantasiose
    > 3 La grammatica poco corretta
    > 4 Le motivazioni molto flebili, poco credibili
    >
    > Ovvio che, come dicevo sopra, magari la signora
    > Pina ci potrebbe pure cascare...speriamo non
    > attivi mai l'home banking.
    >A bocca storta

    Ehi! hai descritto il 90% dei siti in Internet
    non+autenticato
  • Rispondo alle critiche ricevute nei precedenti messaggi:

    >Quella che ti fornisce il token è una "one >time password" ed è pure più sicura della tua, >perché è calcolata e non riproducibile se non >conosci l'algoritmo che RSA usa per crearla, e >quindi "non viaggia".
    >Non ho capito quale vantaggio abbia il tuo >sistema, che esposto agli stessi attacchi.

    Il mio sistema si basa sull protocollo di autenticazione con OTP descritto nel RFC2289.
    Basta leggere l'RFC2289 per convincersi che è un protocollo valido.

    L'uso della crittografia delle Curve Ellittiche poi consente di potenziare il protocollo RFC2289 per renderlo invulnerabile all'unico attacco di phishing (di tipo tradizionale) applicabile a tale protocollo.
    (per maggiori info basta fare un ricerca su google su RFC2289 e sui possibili attacchi).

    >Non mi risulta che il tuo sistema ti protegga >dal MIM attack.

    >Se l'utente clicca sul link di phishing, il >server truffatore può connettersi alla banca >la quale gli lancia il challange >diciamo "X1B3Z4") il server-truffa >propone "X1B3Z4" all'utente il quale convinto >di parlare con la banca gli calcola il >response (diciamo "Q9D1V7") col tuo sistema. >Ora il server truffa manda "Q9D1V7" alla banca >e l'autenticazione è già fatta.

    L'attaccabilità con MIM attack è dovuta al fatto che il challenge e il response viaggiano sullo stesso canale.

    Il mio sistema prevede due modalità.
    Una cost-less dove challenge e response viaggiano sullo stesso canale (le pagine web). L'utente legge il challenge dalla pagina web, lo digita sul cellulare, legge la OTP generata e la scrive nella pagina web (questa modalità è quella implementata su http://www.hostingjava.it/-monkeybs).
    Questa modalità è vulnerabile a MIM attack come riportato sopra.

    La seconda modalità è invece più sicura e invulnerabile a MIM attack perchè challenge e response viaggiano su canali diversi ma ha dei costi per ciascuna autenticazione.
    In pratica il challenge non viene visualizzaato nella pagina web (quindi un MIM non potrà mai conoscerlo) ma: 1) o viene inviato all'utente via SMS (il costo dell'autenticazione è a carico del server/banca); 2) o viene letto dal cellulare mediante una connessione GPRS al server (il costo dell'autenticazione è a carico dell'utente)
    L'utente quindi legge la OTP generata e la scrive nella pagina web.

    Per quanto riguarda invece l'usabilità del sistema basta provarlo per convincersi che è realmente user-friendly.

    Ciao,

    Ugo Chirico
    http://www.ugosweb.com
  • guarda onestamente a me gia' sta sul ca22o dover usare un token (dovevo fare un bonifico, ma ero al lavoro e il token a casa...bella inculat4...) figurati se devo anche portarmi appresso sempre anche il cellulare...non e' mica una appendice, eh!
    non+autenticato
  • Quella che ti fornisce il token è una "one time password" ed è pure più sicura della tua, perché è calcolata e non riproducibile se non conosci l'algoritmo che RSA usa per crearla, e quindi "non viaggia".

    Non ho capito quale vantaggio abbia il tuo sistema, che esposto agli stessi attacchi.
    non+autenticato

  • - Scritto da:
    > Quella che ti fornisce il token è una "one time
    > password" ed è pure più sicura della tua, perché
    > è calcolata e non riproducibile se non conosci
    > l'algoritmo che RSA usa per crearla, e quindi
    > "non
    > viaggia".
    >
    > Non ho capito quale vantaggio abbia il tuo
    > sistema, che esposto agli stessi
    > attacchi.

    Il vantaggio per Ugosweb è che tu compri il SW da luiOcchiolino
    4724
  • Grazie per i vostri feedbak.

    Il mio sistema è ancora in sperimentazione ed in evoluzione, pertanto, ho bisogno di feedback esterni validi (magari per vedere ciò che io do per scontanto o che non riesco a vedere).

    Datemi un po' di tempo per pensarci e risponderò alle vostre critiche.

    Ciao,

    Ugo Chirico
    http://www.ugosweb.com


  • Notoriamento attacco difficile da eludere soprattutto da un servizio pubblico come un server web per molti utenti.
    La soluzione, temporanea, potrebbe essere quella di limitare i tentativi dallo stesso ip.
    Ma poi i phisher inizierebbero a usare spambot di cui sfruttare gli ip e saremmo punto a capo.
    non+autenticato

  • - Scritto da:
    > Notoriamento attacco difficile da eludere
    > soprattutto da un servizio pubblico come un
    > server web per molti
    > utenti.
    > La soluzione, temporanea, potrebbe essere quella
    > di limitare i tentativi dallo stesso
    > ip.
    > Ma poi i phisher inizierebbero a usare spambot di
    > cui sfruttare gli ip e saremmo punto a
    > capo.

    già per https, se il sito ha un certificato firmato da una CA riconosciuta (thawte, verisign, ecc), l'attacco man in the middle è inutile perchè individuabile.
    Quindi non è così semplice
    non+autenticato
  • ma per creare una pagina https, non basta inserirci un'icona con un lucchetto? Scherzi a parte, in parecchi ci credono.
CONTINUA A LEGGERE I COMMENTI
Successiva
(pagina 1/2 - 7 discussioni)