Venerdì 24 Febbraio al Forlì Linux User Group terrò un talk sul Phishing dove analizzerò il fenomeno sempre crescente del Phishing con una simulazione.

Tutti noi riceviamo almeno quotidianamente eMail (e non solo) con il chiaro intento di rubarci le credenziali di accesso alla nostra vita digitale, che sia il conto corrente online, piuttosto che l’account social e così via.
Questo è il phishing, una truffa che come ogni tecnologia umana si sta evolvendo e questa serata ha come obbiettivo quello di spiegare in maniera chiara e precisa che cos’è, come funziona e come possiamo difenderci.
Vedremo anche con esempi pratici, come già avvenuto per la serata sul penetration test, esattamente come si può svolgere una campagna di phishing, quali sono gli attori coinvolti, un esempio di infrastruttura e come poter tutelarci da questi attaccanti.

Di seguito il programma più dettagliato del talk:

  • Presentazione
  • Introduzione al Phishing:
  • Cos’è,
  • Dati Statistici,
  • Tecniche,
  • Simulazione mediante due tecniche:
    • via eMail di Phishing ai danni di un ente normalmente soggetto ad attacchi di Phishing,
    • via SMS di Phishing con dominio creato ad-hoc per rendere maggiormente credibile SMS,
  • Analisi dei dati acquisiti nella simulazione e non solo:
    • IP
    • User Agent
    • Localizzazione
    • Credenziali
    • ecc…
  • Contromisure
  • Conclusione

La serata è aperta a tutti e non servono conoscenze tecniche, basta solo molta curiosità.

Ci vediamo il 24 febbraio presso la sede del FoLUG, la partecipazione è gratuita ma è richiesto la registrazione all’evento da qui.

Per chi non dovesse riuscire ad essere presente verranno pubblicate da Sabato 25 le slide e uno screencasting dell’evento.

Slide e Video

Le slide della serata sono disponibili qui: https://www.slideshare.net/drego85/phishing-analisi-simulazione-e-contromisure

Un’autenticazione a due fattori (o autenticazione a più fattori o strong authentication) è un metodo di autenticazione che si basa sull’utilizzo congiunto di due metodi di autenticazione individuale. {Wikipedia}

Ieri da un ReTweet di Federico Maggi ho appreso che WhatsApp aveva reso disponibile a tutti, e non solo ad un riestretto numero di utenti come avveniva dallo scorso novembre, l’autenticazione a due fattori. Questo ulteriore strato di protezione garantisce all’utente una maggior sicurezza e l’impossibilità di usare le vulnerabilità del protocollo telefonico SS7 per impossessarsi di un account WhatsApp altrui.

Il 2FA (two factor authentication) viene usualmente implementato mediante i seguente tre metodi:

  • pin/password (codice statico);
  • token/otp (password generata casualmente a cadenza temporale);
  • biometria (impronta digitale, iride, ecc).

WhatsApp ha scelto il primo metodo per implementare l’autenticazione a due fattori, probabilmente perché già il primo metodo è basato sull’autenticazione tramite One Time Password attraverso l’invio di un SMS al nuovo utente.

Sostanzialmente se un utente con 2FA cambia Smartphone dovrà inizialmente digitare il suo numero di cellulare, riceverà il primo codice OTP via SMS e successivamente digiterà la password del 2FA scelta in precedenza.

Comunemente il 2FA implementato tramite codice è una protezione “sconnessa” richiesta solo in una determinata azione, in questo caso l’autorizzazione ad abilitare un nuovo device. Non deve essere richiesta periodicamente altrimenti aumenta sensibilmente il rischio che tale codice possa essere esposto e quindi compromesso!

WhatsApp, come vedete nello screenshot di apertura, ha invece deciso di richiedere saltuariamente (al secondo giorno me l’ha già chiesto 2 volte) tale codice con l’intento di non farlo scordare all’utente. Oltretutto se veramente l’utente si scorda il codice e sta attivando un nuovo dispositivi è possibile effettuare l’attivazione via eMail!

Se state scuotendo la testa non avete visto ancora nulla, veramente!

Abbiamo finora capito che in linea teorica un codice statico sfruttato per il 2FA NON dovrebbe essere conservato digitalmente, ne portato appresso e generato casualmente come a rigor di logica dovrebbero essere tutti i codici/password. WhatsApp invece ti impone di ricordartelo spingendo l’utente ad usare un codice comune (una data di nascita, anniversario, ecc) o a memorizzarlo in qualche luogo facilmente raggiungibile (PostIt, Agenda, 1Password, ecc ecc) aumentando il rischio di esporre il codice.

Vi basta pensare che altri portali che sfruttano l’autenticazione a due fattori o magari anche tre richiedono di STAMPARE il codice e di conservarlo in un luogo sicuro come una CASSAFORTE. E ovviamente non ti chiedono di andare ad aprire la cassaforte tutti i giorni 🙂

Un esempio? Blockchain o 1Password!

Ma cosa succede se l’utente si scorda il codice della 2FA? Semplice basta cliccare su “Codice di accesso dimenticato” e per magia l’autenticazione a due fattori viene DISABILITATA! ?

Basito, e ovviamente non si riceve neanche un avviso via eMail di tale disabilitazione!

Proseguendo l’analisi una volta attivata la Verifica a due fattori (o in due passaggi) è possibile disattivarla dalle impostazioni, l’applicazione NON richiede il codice precedentemente impostato per procedere alla disattivazione. E ovviamente non invia una notifica all’eMail indicata durante l’attivazione.

Ricapitolando:

  • WhatsApp richiede all’utente di inserire saltuariamente (probabilmente ogni giorno) il codice del 2FA quando la best-practice prevede di richiederlo solo all’attivazione di un nuovo device;
  • Se l’utente si scorda il codice della verifica in due passaggi (sul device già attivo) con un semplice click viene disabilitato l’ulteriore livello di sicurezza;
  • L’utente o un malintenzionato possono disabilitare la verifica in due passaggi senza che venga richiesto il codice originario.

Concludo lasciandovi uno screenshot postato su Twitter da Konrad Iturbe in cui si evince che il codice del 2FA viene conservato e salvato in chiaro (deducibile dalla brevità del campo). Preciso che non ho verificato quest’ultima notizia.

Uno screenshot dell’applicazione TvhClient per iOS con la guida TV.

Gli amici che mi seguono sui Social sanno che in questi giorni sto configurando il mio Intel Nuc Skull Canyon che progressivamente sostituirà il mio “cluster” di Raspberry Pi sfruttati per lavoro e per hobby. Uno dei raspi era configurato con TVHeadend, un software Open Source per visionare la TV o ascoltare la radio in streaming sfruttando il proprio impianto televisivo.

La programmazione dei canali inviata tramite le frequenze DVB-T è molto carente, si limita al massimo alle successive 24h ma è facile trovare emettitori che rilasciano informazioni molto più brevi nell’arco delle 3h o che non le rilasciano proprio. Questo non permette di impostare una registrazione automatica dei canali.

Sfruttando invece i dati offerti dalla comunità VuPlus è possibile ottenere una guida TV più ampia, VuPlus offre la programmazione per diversi paesi ed è quindi possibile personalizzare il mio script con l’archivio desiderato.

Mi sono basato su un precedente script creato da Mathias F. Svendsen e l’ho personalizzato per le mie esigenze includendo miglioramenti complessivi nel codice.

In maniera predefinita TVHeadend eseguirà il download dei dati due volte al giorno, alle 00:04 e 12:04. In alcuni casi è possibile che il file XML scaricato dallo script contenga dei nomi TV leggermente diversi rispetto a quelli acquisiti dal vostro ricevitore TV e pertanto dovrete fare una associazione manuale dalle impostazioni della WebGUI di TVHeadend.

Il mio script e le istruzioni per l’installazione sono disponibile su GitHub, ogni collaborazione è ovviamente ben accetta.

[LISTE AGGIORNATE AL 4 Novembre 2017]

Vi lascio infine la fonte di tutte le Guide TV Italiane offerte da VuPlus Community in formato XMLTV:

  • http://www.vuplus-community.net/rytec/rytecIT_Basic.xz
  • http://www.vuplus-community.net/rytec/rytecIT_Sky.xz
  • http://www.vuplus-community.net/rytec/rytecIT_SportMovies.xz