Il caso Tper e i consigli per reagire alle fughe di dati

Le fughe di dati sono all’ordine del giorno e quella che ha coinvolto gli utenti dell’app Roger di Tper non sarà l’ultima da consegnare alla cronaca.

Tuttavia, ogni fuga di dati è un’occasione preziosa per le organizzazioni che possono migliorare i rispettivi assetti difensivi e le procedure di risposta e, parallelamente, lo è anche per le persone i cui dati vengono violati che devono sapere cosa fare e come farlo. Ciò equivale a proteggere i propri dati, spesso consegnati a chi dimostra di non saperne avere cura.

Perché, al di là dello strapotere del cyber crimine, le organizzazioni hanno a disposizione un discreto assortimento di tecniche e di tecnologie per evitare il peggio e limitare i danni ma, ancora oggi, mancano la sensibilità e la cultura necessarie a fare sì che la protezione dei dati venga considerata con la dovuta cura.

La regola non scritta è tanto disarmante quanto semplice: chi aderisce a servizi digitali deve abbracciare l’idea di doversi prendere cura dei propri dati perché ci sono reali possibilità che l’azienda a cui li consegna non sarà in grado di proteggerli.

Tper, Roger e la fuga di dati

Tper è acronimo di Trasporto Passeggeri Emilia-Romagna Spa, società di trasporto pubblico che gestisce treni regionali e servizi di mobilità in diverse aree dell’Emilia-Romagna.

Roger è un’app per la vendita di titoli di viaggio e di servizi di mobilità integrata lanciata dalla stessa Tper e che permette principalmente di:

• Acquistare biglietti e abbonamenti
• Pianificare percorsi
• Conoscere gli orari in tempo reale dei mezzi di trasporto
• Pagare parcheggi
• Accedere a servizi di car sharing e scooter sharing

La versione più recente di Roger include anche un wallet digitale.

Considerando che, stando a quanto riporta la stessa Tper, l’app Roger è stata prelevata 450mila volte, l’interesse dei criminal hacker assume un senso. Ciò che si fa fatica a inquadrare è la (presunta) assenza di cifratura dei dati a riposo.

La società che ha sviluppato e gestisce l’infrastruttura tecnologica dell’app Roger è myCicero Srl, della quale torneremo a parlare più sotto e che, al pari di Tper, si è attivata per assolvere gli obblighi normativi e legali imposti dal caso.

I fatti in breve

La fuga di dati è avvenuta tra il 29 e il 30 marzo del 2025 e, come da prassi, la violazione è stata notificata ai sensi dell’articolo 34 del GDPR. Tper, inoltre, ha costantemente aggiornato le utenze coinvolte, comunicando anche a quali rischi potenziali può condurre un’esfiltrazione di dati.

Se ne torna a parlare oggi perché Tper ha fornito ulteriori informazioni all’inizio del mese di dicembre.

Diciamo subito che i dati relativi ai mezzi di pagamento non sono stati esfiltrati. Nello specifico, i dati sottratti sono:

• I dati identificativi degli utenti, ossia nome, cognome, codice fiscale o numero della partita Iva, indirizzo email e numero di telefono
• Username e password sono stati pure esfiltrati ma quest’ultime non erano conservate in chiaro da Tper, che ha adottato una protezione hash (della quale parleremo in seguito)
• I dati relativi ai titoli acquistati e le informazioni a questi associati, incluse le targhe dei veicoli e le zone in cui questi sono stati parcheggiati durante le 64 ore precedenti l’attacco. Tper ha fatto sapere che i dati più datati sono anonimizzati.

I dati sottratti espongono gli utenti a rischi di phishing e di furto di identità ma il fatto che i dati finanziari non sono stati esfiltrati riduce – almeno nell’immediato – il rischio di frodi.

L’impatto e i rischi per gli utenti

I rischi principali di cui gli utenti coinvolti dovrebbero tenere conto sono:

• Phishing e social engineering: i dati esposti possono favorire campagne fraudolente
• Furti di identità: i criminali possono usare i dati sensibili quali numeri di documenti di identità, codici fiscali, indirizzi email e dati anagrafici per impersonare la vittima
• Credential stuffing: se le credenziali sottratte sono utilizzate anche su altri servizi online, il rischio di compromissione aumenta
• Reputazione e fiducia: l’incidente mette alla prova la credibilità di Tper e, più in generale, la fiducia degli utenti nei confronti dei servizi digitali.

Quando ci si iscrive a un servizio online, è opportuno leggere le privacy policy, spesso saltate a piè pari e invece ricche di informazioni determinanti.

Se chi eroga il servizio applica politiche di cifratura dei dati tende a evidenziarlo, perché è sia una garanzia di serietà sia una prova di trasparenza.

Cosa fare quando i propri dati vengono violati

A prescindere dal servizio violato – questi suggerimenti valgono anche per Roger – è opportuno che gli utenti i cui dati sono stati potenzialmente esposti, si comportino come spiega l’ICT Security manager Enrico Morisi: “La compromissione di un account deve ovviamente essere sempre contestualizzata: potrebbe, infatti, risultare più o meno critica, e richiedere interventi differenti, a seconda dei sistemi e servizi coinvolti, e delle autorizzazioni concesse.

Tra le azioni più urgenti e più comuni da intraprendere sono annoverabili sicuramente:

• la segnalazione a tutti i presidi di sicurezza previsti (per esempio, servizi di Incident Response, di Threat Intelligence, SOC, NOC, e così via)
• il reset della password o, prima ancora, la disabilitazione temporanea dell’account nei casi più gravi
• il reset della MFA, verificando dispositivi accreditati e accessi consentiti
• la chiusura di tutte le sessioni aperte coinvolte
• la verifica delle autorizzazioni concesse all’account
• la verifica e l’approfondimento continuo di tutte le connessioni tracciate, in ingresso e in uscita, soprattutto quelle ritenute anomale e conseguenti ad un accesso andato a buon fine o, comunque, ad una penetrazione all’interno del ‘perimetro’”.

Tutto ciò, ribadisce Enrico Morisi, contestualizzando caso per caso: “Chiaramente, ogni incident richiede una risposta adeguata alla sua tipologia, complessità e criticità, che devono essere opportunamente valutate.

La rapidità sia nel riconoscere la compromissione di un account sia nel rispondere adeguatamente all’incident, è cruciale e deve essere supportata da persone opportunamente formate e informate, che adottino comportamenti virtuosi, da appropriati processi, policy e procedure e da idonee soluzioni tecnologiche.

I principi da perseguire sono noti e vanno dal ‘least privilege’ e ‘need to know’, alla ‘defence in depth’ e allo ‘Zero Trust – Never Trust, Always Verify’, cercando di abbandonare, dove possibile, il modello ‘fossato e castello’ delle tradizionali VPN, e abbracciando invece modelli identity-centric e cloud-native come, ad esempio, SASE (Secure Access Service Edge) per garantire un approccio ‘granulare’ agli accessi, con verifiche basate sulla continua ispezione e validazione delle richieste”.

La cifratura dei dati

Abbiamo contattato Tper per capire se i dati esfiltrati fossero cifrati, ovvero impossibili da leggere, e ciò avrebbe avuto un impatto molto diverso tanto dal lato pratico quanto dal lato reputazionale.

Infatti, se i dati fossero cifrati, gli utenti avrebbero molti meno patemi e l’immagine dell’azienda violata potrebbe persino uscirne rafforzata perché, fermo restando che nessuna organizzazione è immune alle attenzioni del cyber crimine, è altrettanto vero che si può fare molto affinché i malintenzionati raccolgano un magro e misero bottino.

Tuttavia, Tper ci ha risposto in modo sbrigativo, liquidando la nostra richiesta affermando che la gestione dell’app Roger non rientra nelle proprie competenze, invitandoci a contattare l’assistenza, senza specificare un contatto a cui rivolgerci.

Atteggiamento che ognuno giudicherà come meglio crede, basandosi anche sul fatto che l’assistenza dell’app Roger non ha risposto alla nostra richiesta.

L’unica cosa certa è che le password degli account utente sono protette da hash che, per principio almeno, è una buona cosa. Nonostante ciò, l’hashing può non essere garanzia assoluta nei contesti in cui non c’è salt, le password sono deboli o gli algoritmi usati sono obsoleti.

In breve, quando un utente crea un account, la password che sceglie non viene memorizzata in chiaro ma viene calcolato e salvato un hash, ovvero un valore di lunghezza fissa generato da una funzione crittografica non reversibile.

Nel momento in cui l’utente accede all’account, il sistema ricalcola l’hash della password inserita e controlla che il valore corrisponda a quello memorizzato.

Come evidenzia Enrico Morisi, “La tattica che prevede di gestire le password utilizzando un loro hash al posto del tradizionale ‘plaintext’, è certamente essenziale ma non è, ovviamente, sufficiente a garantirne la protezione: il ricorso alle cosiddette ‘one-way’ function per generare hash che siano crittograficamente sicuri, adottando algoritmi resistenti alle collisioni, deboli o forti che siano, non costituisce di per sé una garanzia che le password non possano essere evinte.

Il ricorso ai brute force attack costituisce un valido esempio di minaccia alla buona pratica dell’hashing.

Possono essere di tipo tradizionale, basati su dizionari o su interi DB di credenziali rubate (credential stuffing) di tipo password spraying, per aggirare le contromisure di ‘slow down’ adottate (account lockout/lockdown, rate limiting, CAPTCHA, e così via) o ibridi, e sono tutt’altro che desueti, grazie alla semplicità, alla versatilità e all’efficacia che li contraddistinguono.

Inoltre, possono essere condotti anche offline, su repository di hash esfiltrati”.

Ci sono altri aspetti che collaborano potenzialmente a minare la sicurezza dell’hashing e, tra queste, l’esperto mette in evidenza: “ Le moderne tecnologie di IA rendono poi la difesa ancora più ardua, introducendo l’imitazione del comportamento umano, soprattutto via browser, e automazioni prima impensabili.

L’utilizzo di una stessa password per più sistemi e servizi, o il suo riuso nel tempo costituiscono altri esempi di elevata esposizione al rischio di accessi non autorizzati, indipendentemente dal fatto che siano state implementate opportune soluzioni di hashing.

Le policy base dovrebbero prevedere sempre l’adozione di password uniche (non usate altrove) mai usate prima e di adeguata complessità, possibilmente passphrase, quindi molto lunghe, e l’introduzione di almeno un secondo fattore di autenticazione, privilegiando soluzioni di MFA ‘phishing resistant’, come quelle sviluppate e promosse da FIDO Alliance e W3C, in abbinamento anche all’uso di attributi biometrici, tenendo sempre ben presente, però, che non rappresentano in alcun modo una ‘panacea’ e potrebbero essere compromesse”.

Ulteriori misure di mitigazione

Le tecniche di hash da sole non sono sufficienti. Infatti, come illustra Enrico Morisi: “All’hashing delle password è poi fondamentale associare altre misure di mitigazione del rischio come, per esempio, il ricorso al Single Sign-On (SSO) e ai Web Application Firewall (WAF) il monitoring e il logging continuo degli accessi e dei comportamenti, l’adozione di un password manager di livello enterprise, accuratamente selezionato e conforme, per esempio, alle linee guida del NIST, al fine anche di favorire l’applicazione delle suddette policy, e l’introduzione, se possibile, di soluzioni predittive di Threat Intelligence, provvedendo al cambio immediato della password, alla chiusura di tutte le sessioni attive e al reset dell’MFA, qualora risultino evidenze di compromissione di un dato account (per esempio, il furto di credenziali)”, sottolinea Morisi.

Un tema che merita un ulteriore approfondimento, non per demonizzare l’hash in quanto tale ma per dimensionarne l’efficacia e l’attendibilità in modo puntuale: “Infine, le tecniche di hashing prevedono tipicamente l’aggiunta di cryptographic salt, una possibile contromisura agli attacchi basati sulle cosiddette ‘rainbow table’, vale a dire su liste di hash precalcolati che vengono semplicemente confrontati con quelli da compromettere, nella speranza di ottenere una corrispondenza.

I continui ed estremamente rapidi progressi nell’ambito delle tecnologie di calcolo hanno spinto, però, enti autorevoli come il NIST a raccomandare l’uso di algoritmi crittografici più complessi, come il Key Derivation Function (KDF) sempre nell’ottica di rallentare l’attacco a tal punto da renderlo poco appetibile, non ‘economico’ e, in definitiva, non conveniente.

Il tema è particolarmente serio e critico perché è noto che, grazie anche all’esplosione del ricorso al cloud, in tutte le sue declinazioni, ai mobile device, al remote working, e così via, l’identità digitale rappresenta ormai, di fatto, il nuovo ‘perimetro’ della sicurezza, e una password, anche se è una semplice ‘chiave’, la inseriamo in una ‘serratura’ che, oltre a ‘definire’ la chiave stessa, è lo specchio del livello di Cultura della Sicurezza delle Informazioni di una data organizzazione”, conclude Enrico Morisi.

Lo scarico di responsabilità e la (traballante) idea di trasparenza

Abbiamo contattato, nell’ordine, Tper Spa che, come scritto sopra, ha dichiarato di non avere a che fare con la gestione dell’app Roger. Su questo aspetto torneremo tra poco.

Il servizio clienti di Roger non ha risposto alla nostra email, ci siamo così rivolti a MyCicero Srl, l’azienda che ha sviluppato l’app Roger.

A tutte tre le organizzazioni abbiamo chiesto per quale motivo i dati a riposo non sono stati cifrati, con l’unica eccezione delle password degli account, sottoposte ad hashing.

Le mancate risposte non rientrano nei canoni della chiarezza e della trasparenza e, a volere essere pignoli, la posizione di Tper Spa è difficilmente difendibile perché, come si legge qui, l’azienda è contitolare del trattamento dei dati degli utenti e, in tale veste, avrebbe potuto rispondere senza rimbalzarci altrove.

A questo punto le domande irrisolte sono due: non c’è modo di sapere se i dati a riposo fossero cifrati (o, al limite, perché è stato deciso di non cifrarli) e, contemporaneamente, occorre chiedersi a cosa serve designare un titolare del trattamento dei dati degli utenti se questo fa spallucce o finge di non esserlo.

L’idea di trasparenza

C’è una trasparenza normativa e una pragmatica. Le aziende vittime di un attacco informatico sono obbligate alla trasparenza principalmente da normative europee (GDPR, Direttiva NIS2) e da leggi nazionali (in Italia, tra queste, figura la Legge 90/2024 sulla cybersicurezza).

C’è poi una trasparenza il cui obbligo morale non si estingue con l’applicazione di leggi e norme. Un obbligo che coincide appieno con il diritto degli utenti di sapere anche se, per legge, non coincide appieno con il dovere delle aziende di informare.