Paparazzi attack, l’app Immuni è a rischio di violazione dati: tutti i dettagli

Qualche giorno fa è stata rilasciata su GitHub la documentazione di Immuni, l’app di contact tracing progettata per combattere la pandemia di Covid-19: da una prima analisi e in attesa di effettuarne un’altra più approfondita sui sorgenti appena rilasciati è venuto fuori, però, che l’infrastruttura tecnologica usata per Immuni espone l’app ai cosiddetti Paparazzi attack che potrebbero causare gravi violazioni di dati dei contatti positivi al nuovo coronavirus.

Il protocollo di funzionamento di Immuni

In particolare, la documentazione conferma l’utilizzo del modello semi decentralizzato, ovvero i dati degli utenti non lasceranno i loro smartphone e non verranno raccolti in un server centrale, fatta eccezione per gli identificativi dei contatti positivi.

Semplificando, possiamo riassumere il funzionamento del protocollo in queste tre fasi:

• Fase 1, lo scambio degli identificativi anonimi. Bob e Alice non si conoscono, ma si trovano a pochi metri di distanza sulla metro ed entrambi hanno installato l’app Immuni nei loro smartphone. L’app di Bob, tramite Bluetooth rileva l’identificativo anonimo di Alice (una stringa o un numero casuale che viene generato ogni ora a partire da una chiave, che viene invece generata ogni 24 ore) e lo conserva nella memoria del suo smartphone. L’app di Alice fa contemporaneamente la stessa cosa, ovvero rileva l’identificativo anonimo di Bob e lo conserva nella memoria del suo smartphone.
• Fase 2, l’invio dell’alert. Il giorno dopo Bob va dal medico e scopre di essere positivo alla Covid-19. Il medico gli chiede dunque se vuole procedere alla condivisione dei suoi dati (chiavi e identificativi anonimi) al fine di avvisare le persone che hanno avuto un contatto con lui negli ultimi giorni. Se Bob accetta, le sue chiavi e quindi i suoi identificativi anonimi vengono caricati sul server centrale.
• Fase 3, la ricezione dell’alert. A questo punto l’app di Alice, che controlla periodicamente le chiavi dei positivi interrogando il server centrale, la avvisa di essere stata a contatto con un positivo, perché ha trovato l’identificativo anonimo di Bob sul server centrale, lo stesso identificativo che lei aveva già memorizzato sul suo smartphone quel giorno in metro. Da questo momento in poi, Alice potrà seguire le procedure che il servizio sanitario nazionale le indicherà.

I limiti del protocollo e il Paparazzi attack

Uno dei limiti di questo protocollo consiste nel fatto che sebbene gli identificativi siano anonimi, sono comunque leggibili da tutti. Quindi, se io sono in grado di identificare in qualche modo una determinata persona, posso associare il suo identificativo (ed anche quelli futuri) al suo nome. Il Paparazzi attack sfrutta proprio questo principio, perché gli identificativi delle persone infette sono pubblici, conservati sul server centrale.

Paparazzi attack: attacco ad ampia scala

Sfruttando le stesse falle è possibile eseguire anche attacchi ad ampia scala oltre che su singoli individui. Su GitHub è presente un PoC che mostra come sia possibile mettere a punto un attacco di questo tipo.

Nello specifico, il PoC simula la presenza di 300 persone che passeggiano nell’area di Helsinki e traccia i movimenti degli individui positivi alla Covid-19 ipotizzando la presenza di 400 Bluetooth sniffer (dispositivi capaci di intercettare le informazioni che viaggiano sulla rete Bluetooth) piazzati in una griglia da 20×20 in un’area di 1.500 m². I risultati sono preoccupanti e vengono descritti dall’immagine seguente in cui:

• i cerchi rossi corrispondono ai segnali registrati di individui positivi alla Covid-19, persone che come Bob hanno volontariamente condiviso la loro condizione di positività caricando i dati sul server centrale;
• i cerchi blu sono i segnali registrati di persone non positive (o che non hanno condiviso la loro diagnosi).

Come si evince dalle linee che collegano i punti rossi, il percorso di ciascun individuo positivo che ha deciso di condividere i suoi dati può essere ricostruito dettagliatamente.

Paparazzi attack: attacco locale

Ma non è finita qui, perché questa debolezza può essere sfruttata anche in contesti locali in cui sono già presenti altri sistemi di identificazione. Di seguito qualche esempio.

Supponiamo di avere un datore di lavoro particolarmente curioso. Accostando un Bluetooth Sniffer accanto al lettore di badge che registra entrate e uscite, è possibile dare un nome e un cognome all’identificativo anonimo che genera l’app Immuni. Il badge, infatti, non è anonimo e può essere associato all’identificativo anonimo che genera l’app, rendendo di fatto inutile l’anonimato di quest’ultimo.

E dato che gli identificativi e le chiavi degli infetti sono “pubblici”, il datore di lavoro della nostra “Evil Corp” (il nome dell’azienda è, ovviamente, di fantasia) potrà sapere nome e cognome dei dipendenti positivi alla Covid-19, annullando tutto l’impianto di privacy previsto dall’app.

Vale lo stesso meccanismo per tutti i contesti in cui avviene un qualche tipo di identificazione: pensiamo ad hotel, shopping, ma anche bancomat e POS.

Attenzione alle librerie di terze parti

Sia la versione iOS, sia la versione Android di Immuni utilizzano librerie open source di terze parti. Anche se nella maggior parte dei casi questo non rappresenta un problema, nel caso di Immuni, che godrà di un’attenzione mediatica enorme, è facile ipotizzare che un grande numero di malintenzionati proverà a trovare e sfruttare tutte le vulnerabilità dell’applicazione, comprese quelle in librerie di terze parti.

In uno scenario di questo tipo è dunque quantomeno inopportuno l’uso di alcune librerie di terze parti, perché aumentano la superficie di attacco dell’applicazione senza un reale beneficio in termini di funzionalità.

Nell’elenco di librerie usate da Immuni ve ne è qualcuna che ha infatti scopi puramente estetici (ad esempio Lottie, una libreria che permette di implementare in modo facile animazioni 3D).

Giusto per fare un esempio, gli istituti bancari, che per ovvi motivi sono particolarmente attenti alle questioni di sicurezza, generalmente evitano di introdurre codice di terze parti nelle loro applicazioni (a meno che non sia strettamente necessario) proprio per limitare il più possibile la superficie di attacco. Non potremmo forse fare a meno delle animazioni 3D in cambio di un minore rischio in termini di sicurezza?

Il problema dei fake data

Un altro punto aperto all’attenzione degli analisti è la possibilità di iniettare dati fake.

Il sistema, per come è costruito, permette il caricamento di dati in forma anonima. Questo vuol dire che non c’è alcuna identificazione e quindi nessun controllo sulla veridicità dei dati. Cosa succederebbe se un malintenzionato caricasse massivamente nel sistema identificativi e chiavi di infetti fake? Potremo fare qualche ipotesi analizzando i sorgenti nel dettaglio.

Open beta e analisi sorgenti

Oggi sono stati finalmente rilasciati i sorgenti, ed un’attenta fase di analisi ci dirà qualcosa in più. Ma data la delicatezza della questione, ritengo di fondamentale importanza una fase di Open Beta, in cui si simuli massivamente l’uso del sistema prima della definitiva pubblicazione dell’app.