Questo sito utilizza cookie per raccogliere informazioni sull'utilizzo. Cliccando su questo banner o navigando il sito, acconsenti all'uso dei cookie. Leggi la nostra cookie policy.OK

Direttore responsabile Alessandro Longo

Sicurezza

Come proteggere la nostra identità digitale Spid da attacchi “man in the middle”

di Nicola Savino, CEO Seen Solution Srl e Alfonso Pisani, Digital Process Consultant Seen Solution Srl

25 Mag 2016

25 maggio 2016

Lo Spid è prima di tutto un processo digitale e in quanto tale ha bisogno di organizzare e pianificare le metodologie di sicurezza atte a garantire che non ci siano problematiche o falle nel sistema. Ecco qualche soluzione pratica

Alcuni giorni  fa nella distribution list del progetto Procedamus è stato segnalato un articolo sul sito punto informatico che referenziando una ricerca dell’Università di Amsterdam (documento in lingua inglese) illustra una potenziale criticità del sistema SPID proveniente dal mondo dei malware pensati per l’home banking.

Scopo del presente articolo non è di sottoporre a critica positiva o negativa lo SPID, ma dare un pò di informazioni complementari che siano di dettaglio sufficiente e non eccessivo sulla criticità in questione e che possano guidare, sotto questo punto di vista,  anche un cittadino nella valutazione dei servizi offerti.

Anzitutto richiamiamo anche qui i 3 livelli di sicurezza che attualmente sono proposti dallo SPID (sono implementati in realtà solo i primi 2):

IDENTITÀ SPID DI LIVELLO 1: Permette l’accesso ai servizi con nome utente e password

IDENTITÀ SPID DI LIVELLO 2: permette l’accesso ai servizi con nome utente e password insieme ad un codice temporaneo che ti viene inviato via sms o con app mobile dedicata (cosiddetta autenticazione a due fattori)

IDENTITÀ SPID DI LIVELLO 3: Permette l’accesso ai servizi con nome utente e password e l’utilizzo di un dispositivo di accesso

La criticità segnalata è della tipologia degli attacchi cosiddetti “man in the middle/man in the browser”.

Andiamo un attimo per gradi e vediamo il ruolo che ha il nostro browser nelle transazioni.

La figura seguente illustra il caso più semplice di una qualunque transazione web che possiamo fare dal nostro PC, da smartphone o da qualunque dispositivo connesso ad Internet usando un qualunque browser (Internet Explorer, Google Chrome, Firefox…ecc..)  

Il browser assume un ruolo fondamentale: raccoglie i dati di una transazione e li comunica al server web che eroga il nostro servizio. I dati della nostra transazione potrebbero essere tra i più svariati: dalla prenotazione di un volo, o di un biglietto del cinema o anche la semplice richiesta di una pagina web e contenere dati più o meno importanti e personali. Potremmo includere l’identità spid di livello 1 in questa tipologia di transazioni…le più semplici.

In moltissimi contesti, allo scopo di fornire un livello di sicurezza maggiore all’utente, viene impiegata la cosiddetta autenticazione a due fattori, ossia la conferma della transazione avviene tramite un codice di conferma che viene inviato all’utente tramite canali svariati: dalla mail, o altre specifiche app sullo smartphone all’invio di sms o telefonate da dispositivi automatici. Nei casi in cui la comunicazione avvenga usando canali differenti da quello utilizzato per la transazione (es. nel caso di sms si utilizza la rete telefonica) si parla di notifiche “Out Of Band” cioè fuori banda, appunto, usando un altro canale di comunicazione nel caso in cui quello web potesse essere in qualche modo “non affidabile”, perché magari qualcuno si è impossessato della nostra password e sta facendo una transazione a nostro nome.

In ogni caso, l’utente invierebbe tramite il browser il codice di controllo ricevuto per confermare la transazione.

La figura seguente illustra tale modalità:

 

Questa seconda modalità è quella adoperata per molte tipologie di transazioni bancari e per l’identità spid di livello 2.

Vediamo quindi i malware basati su attacchi del tipo man in the middle come agiscono. In qualche modo (tramite link ricevuti in email o perché si è visitata una particolare pagina web…ecc.) viene installato un software malevolo sul nostro dispositivo (PC, smartphone, tablet o altro) che riesce ad intercettare ed eventualmente modificare tutte le comunicazioni che il nostro browser fa verso il mondo esterno. Ha poca importanza che la connessione sia sicura o cifrata…l’intercettazione (e l’eventuale modifica) delle informazioni avviene prima che le stesse siano cifrate ed “escano” dal nostro dispositivo.

Chiedendo scusa ai più tecnici per il linguaggio non proprio perfetto e perché magari ad occhi puristi l’attacco man in the middle deve avere solo particolari caratteristiche, segnaliamo che una buona serie di video tutorial per chi vuole saperne di più anche in termini di dettagli tecnici è reperibile al canale Sourcefire (in lingua inglese).

Vediamo quindi i vari casi in cui un attacco man in the browser potrebbe creare problemi e le conseguenze.

Nel primo caso illustrato di seguito abbiamo una transazione via web semplice, senza invio di codici confermativi da inserire.  

 

Il malware si limita ad intercettare i dati della transazione e ad inviarli ad un terzo soggetto. La motivazione potrebbe essere “semplicemente” scoprire qualcosa sulle nostra navigazioni allo scopo di invio di materiale pubblicitario o, molto peggio, impadronirsi delle nostre password.

Un altro caso è quello in cui il malware modifica le informazioni della nostra transazione prima di inviarle all’esterno allo scopo, ad esempio, di cambiare i dati di un bonifico bancario o di un pagamento per permettere ad un terzo di trarne profitto come illustrato nella figura seguente:

 

Tutti i casi di attacco visti finora sono sempre senza l’invio di un codice di conferma, e quindi assimilabili all’uso di identità spid di livello 1.

In realtà una volta che un malware riesce ad intercettare e modificare le nostre transazioni ben poco può fare il codice di conferma in quanto l’utente vedrebbe nella finestra del proprio browser i dati che lui ha immesso per la transazione, mentre il malware potrebbe inviare questi dati a terzi o modificarli immediatamente prima che essi viaggino su Internet come illustrato dalla figura seguente per il caso in cui ci sia modifica dei dati.

Le misure di protezione per ridurre i rischi di attacchi di questa tipologia sono svariate e nessuna di esse può totalmente prescindere da una corretta condotta dell’utente vittima potenziale.

Ovviamente vale sempre il solito avviso, purtroppo ancora spesso sottovalutato dall’utenza, di aggiornare i database degli antivirus e applicare tutti gli aggiornamenti di protezione per il proprio dispositivo fisso o mobile e in particolare per i browser.

Dal punto di vista del fornitore della soluzione di autenticazione le misure possono variare dal fornire dei browser dedicati per le transazioni che siano quindi rafforzati (hardened) contro certe tipologie di attacchi al prevedere, nel caso di autenticazione a due fattori come per lo SPID di livello 2, che la comunicazione del codice di conferma avvenga ad esempio per via telefonica indicando anche gli estremi della transazione che si sta per confermare in modo da far scoprire alla vittima eventuali modifiche. Quest’ultima misura sarebbe sicuramente risolutiva e preferibile ad un sms o ad un app ricevente il codice di conferma e riepilogativi della transazione considerando che, anche se più improbabile, lo smartphone potrebbe essere a sua volta oggetto di attacco. Ci sarebbe, ovviamente, da discutere dal punto di vista dell’accessibilità di una soluzione del genere rispetto alla cd Legge Stanca del 2004 sull’accessibilità degli strumenti informatici in particolare se si parla di PA.

Ancora altra soluzione potrebbe essere l’invio di un documento firmato digitalmente contenente il codice di conferma ed il riepilogo della transazione. Questa soluzione è anche quella più sicura, in quanto garantisce l’integrità e l’autenticità dei dati e delle informazioni contenute e rispetterebbe anche i dettami del rapporto tra cittadino e Pubblica Amministrazione, come sancito dal Codice dell’Amministrazione Digitale. Inoltre visto l’enorme mole di documenti che dovranno essere sottoscritti, potrebbe essere interessante avere a disposizione un servizio/server HSM per la firma remota massiva , in modo tale da automatizzare il processo di sottoscrizione digitale e permettere una rapida generazione in modo automatico di tali documenti. Sarà necessario avere evidentemente un servizio certificato secondo le ultime disposizioni legislative per quanto concerne gli HSM utilizzati e il server di firma remota massiva. Il documento firmato digitalmente, andrebbe poi sottoposto ad un processo di conservazione digitale a norma e non sostitutiva, essendo un documento nativamente digitale e facilitando dunque i procedimenti.

Infine potrebbe essere una buona soluzione se la transazione avvenisse attraverso l’uso di distribuzioni live di sistemi tipo linux “preconfezionati” per far partire direttamente all’avvio del dispositivo un sistema operativo minimale per la transazione da effettuarsi (e saremmo già ad una soluzione di livello 3 nel caso dello SPID con l’uso di una chiavetta per la distro da avviare). Questa soluzione è oggi di fatto già possibile grazie ai numerosi servizi online di fornitura di OS in cloud. Molti sono anche gratuiti o open source, ma sufficientemente sicuri da garantire la robustezza e l’integrità della transazione. I vantaggi di questa soluzione è che sarebbe impossibile avere una falla di sicurezza, in quanto il browser utilizzato sarebbe quello del OS in cloud e già disponibile nella distribuzione, invece di far fare al client del nostro pc tale richiesta. Con questa soluzione sarebbe inoltre possibile aggiungere la cifratura sicura dei dati e delle informazioni gestite ed inviate durante tutto il percorso della transazione e quindi della richiesta. Anche in questo caso sarà necessario conservare in maniera digitale i log della transazione per garantire integrità ed immodificabilità del dato e il suo valore probatorio nel tempo.

E’ chiaro che, in generale, queste soluzioni non sono le uniche né sono mutuamente esclusive e per quanto concerne lo SPID esse dovranno tanto più essere prese in considerazione quanto più lo SPID stesso diverrà uno strumento diffuso e quindi “appetibile” per attacchi.

Dal punto di vista normativo ci sentiamo di segnalare questo articolo a proposito delle possibili responsabilità della vittima che in qualche modo potrebbero diventare sempre più connesse alle sue competenze informatiche. 

In conclusione tanti strumenti che, si prevede e si spera, si diffonderanno sempre di più nel panorama europeo, ma che porteranno sicuramente in primo piano le problematiche della sicurezza, non possono prescindere da una nuova cultura digitale dell’individuo che anche lo stesso codice dell’amministrazione digitale (d.lgs. 82/2005 e s.m.i.) ritiene fondamentale. Ci aspettiamo, pertanto, che le iniziative formative siano sempre più diffuse per l’utenza in un’era in cui il linguaggio giuridico e quello informatico devono confrontarsi ed uscire da nicchie ristrette di soggetti.

  • sinetqnlap

    2FA (Two-factor authentication) implementato solo come invio di un SMS-PIN è una soluzione semplice, ma al contempo debole da svariati punti di vista: uso di un canale di trasmissione di una o più terze parti, presentazione in chiaro dell’SMS (e del PIN) ricevuto sullo schermo del cellulare, anche quando quest’ultimo è bloccato …

    In particolare per contrastare una minaccia “man-in-the-browser” e mantenere comunque semplice la user experience(1), è necessario un protocollo di scambio dati più sicuro.

    Una delle possibilità è quella di utilizzare un’App su smartphone; l’uso dello smartphone permette sia di implementare un token virtuale One-Time-Password, sia la possibilità di implementare protocollo “Challenge/Response”

    In pratica il servizio on-line, per validare la transazione, invia tramite browser all’utente un codice di transazione (challenge) che e’ connesso/derivato dai dati della transazione stessa (codice conto, importo, data …)
    Quando lo user, utilizzando il Token virtuale tramite l’App sul suo smartphone, digita questo challenge insieme -ad esempio- alle ultime 6 cifre del codice di conto ed al valore della transazione, l’App fornisce all’utente in risposta, non più una semplice One-Time-Password, ma un Response connesso al Challenge, che l’utente può inserire nel form presente nel browser.

    Questo significa che anche in caso di malware nel browser, la transazione modificata da quest’ultimo non potrà essere validata dal servizio on line, in quando i dati variati dal malware non corrisponderanno più al challenge/response e dati di transazione tra utente e servizio.

    Per l’utente rimane tutto trasparente, ma la sicurezza della transazione viene blindata.

    (1)la semplicità di utilizzo da parte dello user, rafforza e stabilizza le misure di sicurezza implementate: nulla di complicato lato utente, rimane sicuro per molto tempo.

  • calamarim

    Al link allegato, un articolo di risposta ai commenti dell’autore, ed un invito a dibattere la questione ad e-privacy 2016, che sara’ dedicato appunto alla SPID.

    http://punto-informatico.it/4321700/PI/Commenti/lampi-cassandra-spid-un-dibattito-indispensabile.aspx

    http://e-privacy.winstonsmith.org/

Articoli correlati