Per la prima volta ho dimostrato sul campo, con una simulazione, un’importante vulnerabilità riguardante l’app Immuni: ho dimostrato la possibilità di generare false notifiche di rischio che potrebbero essere usate impropriamente per fini terroristici. È il replay attack. Sì, già noto e intrinseco nel protocollo usato da queste app, ma questa è la prima simulazione effettiva.
Come funziona Immuni
Prima di approfondire la recente vulnerabilità, ricapitoliamo a sommi capi come funziona l’app Immuni.
La grande maggioranza delle app di contact tracing oggi in uso, così come Immuni, utilizza il protocollo e le corrispettive librerie messe a disposizione da Apple e Google (Google Apple Exposure Notification – GAEN). L’utilizzo di queste librerie è necessario, tra altre cose, affinché l’applicazione possa funzionare correttamente in background e senza scaricare eccessivamente la batteria.
Come tutte le app basate su GAEN, Immuni utilizza la tecnologia BLE (Bluetooth Low Energy) per rilevare la prossimità tra dispositivi. I telefoni trasmettono continuamente via BLE degli pseudonimi pseudocasuali detti RPI (Rolling Proximity Identifier), che variano approssimativamente ogni 10 minuti e registrano gli pseudonimi in ingresso assieme ad una indicazione temporale sulla loro ricezione, la durata del contatto e altri dati utili per il calcolo del rischio. Gli pseudonimi usati durante una giornata sono generati a loro volta, tramite tecniche crittografiche, a partire da un unico seme casuale detto TEK (Temporary Exposure Key). La TEK è anche utilizzata anche per cifrare informazioni utili a stimare la distanza tra i due telefoni, tali informazioni cifrate dette Encrypted Metadata vengono inviate assieme agli RPI.
Quando un utente risulta positivo e decide di segnalarlo anche attraverso Immuni, l’app manda al server centrale le TEK utilizzate durante i giorni precedenti, assieme alle relative date di utilizzo. Per controllare un’eventuale esposizione a rischio, gli smartphone scaricano periodicamente le nuove TEK distribuite dal server e ne derivano una sequenza ordinata di RPI. Ciascun RPI ha una durata stimata di circa 10 minuti, il primo RPI corrisponde per convenzione ad uno specifico orario ovvero la mezzanotte UTC, i successivi corrispondono a incrementi di circa 10 minuti da tale orario (il secondo RPI corrisponde alle 00:10 UTC e così via). Lo smartphone controlla il proprio database interno alla ricerca di RPI uguali a quelli derivati al passo precedente, e se vi sono uno o più corrispondenze e la decifratura degli Encrypted Metadata rispetta dei criteri allora l’utente è stato a contatto con un infetto e quindi l’app segnala una notifica di rischio all’utente.
Replay attacks contro GAEN/Immuni
In un replay attack, lo scopo di un avversario è far ricevere notifiche di rischio fake agli utenti dell’app di contact tracing.
Nello specifico, un avversario può intercettare uno o più RPI inviati da un utente di Immuni in una determinata posizione dello spazio e ritrasmetterli ad un’altra posizione dello spazio più o meno allo stesso tempo. Per es. un avvesario potrebbe piazzare un dispositivo A (che può essere un telefono o anche un dispositivo dedicato delle dimensioni di una moneta) nei pressi di un ospedale e catturare tramite esso tutti gli RPI che i pazienti di questo ospedale trasmettono nelle vicinanze. Il dispositivo A potrebbe inoltre ritrasmettere questi RPI ad un altro dispositivo B piazzato dall’avversario al tornello di uno stadio. Il dispositivo B ritrasmetterà tutti gli RPI ricevuti da A a tutti gli spettatori che passano al tornello. Come risultato, se uno dei pazienti dell’ospedale sarà diagnosticato positivo nei giorni seguenti, tutti gli spettatori dello stadio passati nelle vicinanze del dispositivo B riceveranno una notifica di rischio.
Le conseguenze di un replay attack potrebbero essere devastanti. Migliaia di persone penseranno di essere a rischio, chiederanno di sottoporsi a tampone e non andranno a lavorare. Un replay attack può altresì essere effettuato da un avversario contro un utente specifico che l’avversario desidera mettere in quarantena o terrorizzare.
La critica di alcuni esperti: “ma è un attacco senza senso”
Secondo alcuni esperti, però, il replay attack non ha fondatezza pratica. Lo fa notare Matteo Flora e un professore esperto di cyber che preferisce restare anonimo. “L’aggressore deve prendere in mano il tuo telefono. Cambiare l’ora. Tenere il beacon a meno di due metri dal tuo telefono per 15 minuti. Ripristinare l’ora. Sperare che il tuo telefono nel mentre non sincronizzi l’ora con la cella. Ma che attacco sarebbe?”, dice. “Semplicemente non è una minaccia perché l’uso che se ne potrebbe fare è surreale”.
La contro replica
Su queste critiche, Iovino ha fatto pervenire una contro risposta: “Prima di tutto deve essere chiaro che anche mandare una notifica fake di rischio al proprio telefono è un attacco in sé. Perché? Per due ragioni. Mostrare la notifica al proprio datore di lavoro potrebbe consentire non andare a lavoro o può essere usata per ingenerare panico tra i propri amici e familiari. In Svizzera una notifica di rischio per es. ha un certo valore legale e permette priorità al tampone. Secondo ma non meno importante, il Ministero della Salute mantiene un contatore su quanti cittadini hanno ricevuto una notifica di rischio. Un hacker malevolo o una potenza straniera potrebbe aumentare questo contatore di migliaia di unità allertando il nostro Ministero su focolai inesistenti. Ora discutiamo riguardo all’attaccare telefoni che non siano il proprio. Non è inverosimile pensare che un avversario abbia accesso al telefono di una vittima per 15 minuti. In questo caso, la nota di Flora riguardo la “sincronizzazione con la cella” è erronea perché l’avversario che effettua l’attacco può (e deve) disabilitare la sincronizzazione del telefono dalla rete”.
“Come suggerito da Martin Vuagnoux, esperto nel campo, si può cambiare la data e ora del telefono a distanza senza accesso al telefono della vittima o usando base station o anche più semplicemente da Wifi usando un time server nel caso che la vittima sia collegata alla wifi dell’avversario. Riguardo alla distanza, sì, è vero che questi attacchi funzionano solo se l’avversario è poco distante dalla vittima. Ma in diverse situazioni quotidiane sediamo e sostiamo in luoghi pubblici come bar e stazioni ferroviarie per più di 15 minuti. Inoltre il segnale bluetooth oltrepassa muri quindi l’avversario potrebbe porre il dispositivo trasmittente dietro la porta di casa della vittima o al lato della sua stanza di albergo. Per finire, la “macchina del tempo” è un attacco in sé ma ricordo che è stata ideata per simulare un replay attack reale. L’essere riuscito a realizzare un replay attack retrodatando la data del telefono, implica che che ci sarei riuscito ance se l’attacco fosse stato in “tempo reale” ricevendo RPI per es. da un ospedale e inoltrandoli ad uno stadio. Quindi sono dell’opinion di Rosario Gennaro, professore al City college di New York, secondo cui è necessario spegnere queste app durante i periodi elettorali per evitare la soppressione di voti ed altri attacchi terroristici”.
Redazione
La nuova vulnerabilità: replay attack via “viaggi nel tempo”
Infatti, per eseguire un replay attack è necessario catturare RPI di utenti che poi risulteranno infetti, il che è illegale. Inoltre la piattaforma GAEN non è open source e per testarla è necessario una particolare autorizzazione riservata alle autorità sanitarie. Per questa ragione, non erano replay attack concreti riportati da studiosi per soli motivi di test e ricerca.
In quanto ricercatore e hacker etico ho invece dimostrato la fattibilità dei replay attack con un esperimento ingegnoso e facendo ciò ha anche scoperto quella che è a tutti gli effetti una vulnerabilità nuova dell’app Immuni.
Ho preso un RPI ricavabile pubblicamente dai dati disponibili sul server di Immuni. Tale RPI è associato ad una data e ora, diciamo il 20 settembre alle ore 8:00. Dopo alcuni accorgimenti tecnici, ho retrodatato il proprio telefono a quella data e ora in una sorta di viaggio all’indietro del tempo e ho usato un dispositivo per trasmettere quell’RPI al telefono per un numero sufficiente di minuti.
Successivamente ho reimpostato la data e l’ora corretta così che l’app ha controllato se tra gli RPI ricevuti il 20 settembre alle ore 8 ci fosse quello di un infetto ed essendo proprio così l’app mi ha segnalato la notifica di rischio.
Oltre ad essere una simulazione di fattibilità un replay attack, questo attacco mostra una vulnerabilità aggiuntiva di Immuni. Chiunque può generare sul proprio telefono una notifica di rischio. Non solo, chiunque può generare una notifica di rischio sul telefono di una vittima avendo la possibilità di cambiare data e ora di questo telefono.
Generare una notifica di rischio anche verso sé stessi può avere ripercussioni sociali e legali. In Svizzera per esempio la notifica di rischio può essere usata per avere priorità al tampone.
Inoltre, in Italia il Ministero della Salute tiene traccia di quanti cittadini hanno ricevuto notifiche di rischio, quindi questi attacchi mostrano che queste statistiche possono essere completamente falsate da hacker malevoli e organizzazioni criminali.
Vulnerabilità confermata anche per l’app Svizzera SwissCovid e pericoli per le elezioni americane.
L’attacco è stato documentato sul forum dell’app Immuni.
Nello stesso forum il ricercatore svizzero Martin Vuagnoux ha confermato di essere riuscito ad eseguire lo stesso attacco all’app Svizzera SwissCovid che inoltre suggerisce che l’attacco può essere “migliorato” usando dispositivi per alterare la data e ora del telefono anche a distanza (senza bisogno di tenere il beacon vicino alla vittima).
Probabilmente, l’attacco riguarda tutti i sistemi basati su GAEN, incluse le app introdotte negli Stati Uniti.
In reazione alla scoperta del nuovo attacco, il professore dell’Università City College of New York Rosario Gennaro ha twittato chiedendo di spegnere le app di contact tracing durante le due settimane precedenti alle elezioni che si svolgeranno il prossimo Novembre. Infatti questi replay attack, sia reali che con “la macchina del tempo”, potrebbero essere abusati per inviare false notifiche di rischio ai cittadini così da costringerli a casa impedendogli di andare a votare.
Tutti i dettagli sono riportati nella sezione issue del Github di Immuni: https://github.com/immuni-app/immuni-app-android/issues/278
Al momento nessuna risposta è pervenuta dagli sviluppatori di Immuni e dal Ministero dell’Innovazione e Tecnologia responsabile del progetto.
