Come facilitare il phishing combattendo lo spam

Questa è una mail che è arrivata a mio padre dal suo provider. Sia chiaro che ho cancellato il nome con XXXX non perché ci sia qualcosa di male a pubblicare la mail (ho ovviamente l’autorizzazione del destinatario), ma perché vorrei mantenere l’attenzione sulla forma anziché sul mittente, che ha solo la sfortuna di essere preso come esempio: altri, banche comprese, hanno la stessa cattiva abitudine.

Gentile cliente,

per frenare lo SPAM, XXXX ha attivato l’autenticazione SMTP, questo comporta la chiusura della porta 25 e l’apertura della porta 587, per tutti gli email che vengono inviati attraverso gli indirizzi forniti sia da XXXX che da altri provider.
Questo vuol dire che se usi un programma di posta (ad esempio Outlook Express) e hai uno o più indirizzi email che non sono forniti da XXXX (ad esempio un indirizzo aziendale) devi modificare la configurazione di questi indirizzi.

Ecco quello che devi fare per navigare con XXXX e usare indirizzi email non forniti da XXXX:

1) registrare almeno un indirizzo email @xxxx
Non è obbligatorio utilizzarlo, ma devi crearne almeno uno per consentire ai nostri server di riconoscerti quale cliente XXXX.
Se ancora non hai creato un indirizzo email di XXXX, vai subito alla pagina di registrazione http://reg.xxxx
Dopo aver creato il tuo indirizzo email, potrai configurare correttamente anche il tuo indirizzo personale o aziendale diverso da quello di XXXX.
Se nella pagina della registrazione ti viene richiesto di inserire nome utente e password, devi inserire quelli della tua connessione ADSL.

2) configurare correttamente il tuo indirizzo diverso da @xxxx
Segui la semplice procedura pubblicata sulla pagina: http://www.yyyy.xxxxinternet/?page=SUPPORT_PORTA_587_OLO

Cordiali saluti

Servizio Clienti XXXX

Vediamo prima cosa si vuole fare. La prima cosa, è richiedere ai propri utenti l’autenticazione per inviare i messaggi. È una cosa che molti provider fanno da anni. Viene però chiesto non semplicemente di attivare l’autenticazione, ma di cambiare porta tcp, passando alla 587. La cosa non sarebbe necessaria, ma qui viene la parte interessante: è necessario passare alla porta 587 anche (seguitemi bene) per le mail che si mandano a server di altri provider, che pure sono in ascolto sulla porta 25. In effetti, ho provato: ho tentato di contattare il mio server di posta sulla porta 25, ed ho ottenuto un errore di “Host unreachable”, mentre mi ha risposto felicemente sulla porta 587. Questo vuole dire che il mio traffico in uscita viene intercettato e bloccato se è verso la porta 25, rediretto alla 25 se è verso la 587. A me, queste cose danno un fastidio… ma perché prendersi questo disturbo? L’unica ragione che mi viene in mente è che si voglia rendere difficile la vita ai programmi che inviano spam direttamente dal client verso internet: non conoscendo il trucco, tentano di accedere alla porta 25 e vengono bloccati. Si tratta naturalmente di un trucchetto che può funzionare finché non è molto diffuso, dato che poi gli spammer impareranno a leggere queste informazioni dalla configurazione del mailer, se già non lo fanno. Tuttavia, dato che le guerre si vincono anche vincendo le battaglie, può anche non essere una cattiva idea; quando non funzionerà più si penserà a qualcos’altro.Veniamo però al problema: l’utente deve modificare la configurazione del proprio sistema in base ad una mail? No: l’utente deve andare sul sito del provider, e lì troverà come modificare la configurazione. Tuttavia:

  1. Non ci sono indicazioni di questo tipo: non si dice agli utenti di accedere al sito e dove trovare le istruzioni, gli si dice di seguire un link;
  2. il secondo link, quello che porta alla modifica alla configurazione, quindi la parte che l’utente capisce meno, non porta all’indirizzo principale del provider, ma ad uno che ha solo un nome simile; in questo caso, si tratta effettivamente di un sito del provider, ma per esserne sicuro e “autorizzare” mio padre a seguirlo ho dovuto usare whois.

Ora, se io volessi fare del phishing, prenderei la mail così com’è, e direi qualcosa del tipo: a partire dal primo febbraio, solo gli utenti che avranno confermato i dati inseriti potranno continuare ad inviare posta. Vi invito a collegarvi al sito http://www.yyyy.internetxxxx/?page=SUPPORT_PORTA_587_OLO e confermare i dati inseriti con la mail del 31/01/2006.

Cosa c’è di diverso? che la mail originale parla di www.yyyy.xxxxinternet, questa di www.yyyy.internetxxxx, che ovviamente non è registrato dal provider. Un utente però non è in grado di riconoscere la differenza, e d’altra parte ha già dovuto seguire una procedura di questo genere, e il risultato sarebbe che molti utenti seguirebbero il link. Questo perché tuttora chi offre servizi continua a non seguire delle regole elementari come:

  1. non usare indirizzi strani per i propri rapporti con i clienti, ma solo quello ufficiale e noto (in questo caso, www.xxxx)
  2. indicare sempre di accedere al sito, senza fornire il link nella mail; sulla pagina del sito deve essere in bell’evidenza il link da seguire.
Posted in Sicurezza | Comments Off on Come facilitare il phishing combattendo lo spam

Newsletter CLUSIT

In questo numero ci sono un paio di articoli che interessano certamente tutti. Mi piace in particolare quello di Mattia Monga sui tastierini per l’home banking (che non ho ancora mai provato). A proposito di sicurezza delle password per l’home banking e di Password Safe, sarebbe preferibile che le banche che usano come unica protezione un codice utente e password, non presentassero la richiesta in un modo che il browser la riconosca come “inserimento di nome utente e password”. In questo modo l’utente non avrebbe la tentazione di memorizzare la password nel browser stesso ma sarebbe costretto ad appoggiarsi a programmi esterni.

Posted in Sicurezza | Comments Off on Newsletter CLUSIT

Decreto su pedopornografia e altri aggiornamenti

Grazie al blog di Mantellini abbiamo (o almeno, io ho) finalmente la possibilità di leggere il decreto, seppure in bozza. Nota a margine, ma è così complicato pubblicare una cosa che è già stata firmata?

Tanto per cominciare, il decreto definisce i requisiti tecnici per i fornitori di connettività; sono esclusi quindi da questo decreto i fornitori di servizi di hosting. Poi, sembrano esclusi i, diciamo così, fornitori di connettività non iscritti, almeno leggendo l’art. 3 comma 1. Ad esempio, ricordo un post di qualche giorno fa, da qualche parte, relativo al fatto che dalle università e da molte PA sono raggiungibili i siti di gioco d’azzardo stranieri che sono bloccati dai normali ISP. Sembrerebbe che qui si riproponga lo stesso problema. Punto importante, si parla di siti (non di indirizzi IP), il cui concetto è definito all’interno del decreto. In effetti, guardando le definizioni del Codice delle Comunicazioni Elettroniche, il “sito” non sembra definito (anche se il termine è utilizzato ad esempio all’art. 23 comma 4, forse è definito altrove?). Non che quella del decreto sia una definizione usabile in senso generale, dato che fa riferimento specificamente alla pedopornografia. L’art. 3 non credo presenti grossi problemi: si tratta di stabilire dei canali protetti fra Centro e ISP, tecnicamente non dovrebbe essere un problema. Non mi è chiaro il problema al quale si riferisce Nuti, e riportato dal Corriere, riguardo all’implementazione della tecnologia da parte di Telecom, che almeno in questa bozza non è citata. Forse il problema sta nella garanzia di consegna, e nella validazione dell’orario che farà fede per il trascorrere delle 6 ore. Per problemi di questo tipo, forse una soluzione è un meccanismo di hartbeat. L’art. 4 comincia ad affrontare il nocciolo della questione. Come fa un ISP a inibire l’accesso a un sito “a livello di nome di dominio”? Purtroppo questo punto sembra molto ambiguo. L’ISP in generale non vede i nomi di dominio, solo il traffico IP. Vede le richieste ricorsive ai propri server DNS, per la risoluzione di domini gestiti da altri, o vede traffico dns in uscita verso altri server DNS. Mentre inibire la risoluzione di un dominio sui propri sistemi è, direi, abbastanza facile, inibile la risoluzione da parte di terzi richiede l’analisi del traffico a livello applicativo. Peggio ancora se le richieste http sono fatte ad un proxy di un altro ISP (non italiano), nel qual caso è nuovamente necessario entrare nel traffico applicativo, per di più di una quantità enorme di traffico. Immagino che l’intenzione fosse di indicare solo che i server dns del provider non devono risolvere il nome di quel sito. Dato che non è sperabile che questo impedisca l’accesso “determinato” al sito, ma solo quello casuale, bloccare la risoluzione sui propri server per evitare che qualcuno capiti sul sito “per sbaglio” può bastare. Peraltro, io non sono mai capitato per caso su un sito di pedopornografia, e dire che Internet la uso… il blocco a livello IP sembra una misura eccezionale: è certamente più efficace, ma rischia di causare maggiori disservizi, e quindi c’è da sperare che rimanga davvero una misura eccezionale. La specificazione dell’art. 5 comma 2 non mi sembra che aiuti in alcun modo a chiarire meglio la situazione. Mi crea invece qualche perplessità l’art. 5 comma 4: parlando di “linguaggi a marcatori” e “linguaggi di script” sembra fare esplicitamente riferimento ad un intervento a livello applicativo, ad esempio sulle richieste http. Temo che garantire questo sarebbe un onere notevole per gli ISP, e nello stesso tempo la realizzazione comporterebbe un’intromissione pesante anche nel traffico legittimo degli utenti onesti. Di nuovo però, non credo che sia questa l’intenzione del decreto: l’art. 8 pone tempi stretti (60 gg) per il filtraggio a livello di nome di dominio, 120 per l’indirizzo IP. Questo direi che stabilisce definitivamente che si sta parlando dei server DNS del provider.
Valutazione complessiva? Se la mia interpretazione è corretta, direi che l’applicabilità è ragionevole, l’impatto sugli ISP limitato, e lo stesso per quanto riguarda il traffico legittimo. Data la media delle norme viste fino a qui, direi che già non è poco. Per quanto riguarda l’efficacia, la vedo solo per quanto riguarda accessi casuali o “naïf”; per evitare situazioni spiacevoli, insomma. Importante l’art. 8 comma 3, che sottolinea l’utilità dei miglioramenti in corso d’opera e dell’interazione con gli ISP. Unico problema di questo approccio: sarebbe utile se le eventuali modifiche al decreto venissero pubblicate e discusse, non solo con gli ISP, prima di essere approvate. Tutto quello che riguarda il blocco o l’intercettazione di comunicazioni può infatti avere pesanti ripercussioni sulle libertà dei cittadini, e quindi non interessano solo gli ISP, che guardano all’aspetto tecnico, ma anche, e come minimo, il Garante della privacy, le associazioni dei consumatori ed i cittadini tutti. Intervenire per modifiche a decreti su questi temi lo vedo altrimenti molto rischioso.
Passando ad altro. A quanto pare il ripristino delle comunicazioni in Asia sarà più lungo e complicato del previsto.

E per quanto riguarda i dati dei cittadini EU che entrano in USA, forse ci eviteremo altre fonti di errori e seccature. Mi piace questo commento: “Bruce actually used the shortened name of the program. The full name is US-VISIT UR COUNTRY, U NOT-VISIT OURS.”

Posted in Sicurezza, Varie | Comments Off on Decreto su pedopornografia e altri aggiornamenti