E’ da parecchio tempo che vengo invitato a scrivere le mie impressioni sull’APP “IMMUNI”, sinceramente fino ad adesso, ho sempre rifiutato questo invito perché ritenevo che la situazione epidemica in cui ci siamo imbattuti necessitasse di un sistema di tracciamento che consentisse di gestire, in maniera immediata, i contatti di coloro che fossero contagiati.

Adesso che la fase epidemica ha superato il suo punto massimo e la vita ordinaria si riaffaccia ad uno stato di semi normalità ho iniziato a pormi delle domande sia dal punto di vista morale che da quello tecnico.

Moralmente, l’utilizzo di una APP di tracciamento (Google, Whatsapp, Facebook etc. etc.) , non incontra, in tempi normali, il mio favorevole consenso in quanto consente, sia a chi istituzionalmente ne necessita  sia a coloro che in maniera fraudolenta accede a queste informazioni, di tracciare passo passo i miei spostamenti e incontri violando così, in maniera netta, il mio diritto alla riservatezza e consentendo di ricostruire modi e abitudini della vita quotidiana e lavorativa, orari, spostamenti, conoscenze e via di seguito.

Adesso, purtroppo, non stiamo vivendo in un periodo di vita normale ma sottoposto a talune restrizioni dovute al COVID-19 e essere tracciati nei propri spostamenti ed incontri è fondamentale per circoscrivere una possibile infezione da contatto, di conseguenza per educazione civica devo , da questo punto di vista, personalmente approvarne l’utilizzo per l’insieme della civile convivenza, anche se questa applicazione ha in se un limite intrinseco che impone la volontarietà della comunicazione da parte dell’utente (ovvero se positivo ai test posso pure non comunicarlo tramite l’APP rendendo quindi inutile il suo utilizzo) cosa che di per se stessa è contraria a uno schema di salute pubblica, se a questo aggiungiamo anche i ritardi della pubblica amministrazione nell’esercitare quei controlli (tamponi , blood screening , etc) che, nel caso di un avviso di contatto a rischio,tormentano l’utenza segregandola in una quarantena spesso inutile ma a volte tardiva dato il ritardo in cui vengono emessi gli avvisi di contatto che a volte sfiorano i nove-dieci giorni ( se effettivamente fossi stato a contatto con un positivo e avessi contratto il COVID-19, e se i miei ricordi  liceali di biologia non mi tradiscono, nel periodo di incubazione sarei contagioso anche prima del conclamarsi della malattia).

Da un punto di vista tecnico, devo invece constatare che questo sistema impiega, per scambiare dati di contatto, il sistema radio del Bluetooth in modalità BLE (Bluetooth Low Energy) in maniera costante per rilevare i contatti di prossimità e scambiare i dati di contatto tramite protocolli quali :

DP-3T del Consorzio Mondiale,

PEPP-PT del Consorzio Europeo,

ROBERT  del gruppo Inria – Fraunhofer.

L’utilizzo del bluetooth espone però ad una serie di problematiche legate intrinsecamente al sistema che nascendo per altri scopi porta in se i conseguenti limiti o bugs.

Di seguito una piccola lista delle possibili vulnerabilità accertate (www.cve.mitre.org):

  • Link Layer Length Overflow (CVE-2019-16336, CVE-2019-17519) —These allow attackers in radio range to trigger a buffer overflow by manipulating the LL Length Field, primarily leading to a denial of service attacks.
  • Link Layer LLID deadlock (CVE-2019-17061, CVE-2019-17060) — These trigger deadlock state when a device receives a packet with the LLID field cleared.
  • Truncated L2CAP (CVE-2019-17517) — This flaw results due to a lack of checks while processing an L2CAP packet, causing a denial of service and crash of the device.
  • Silent Length Overflow (CVE-2019-17518) — A buffer overflow occurs when a certain packet payload with higher than expected LL Length is sent, the peripheral crashes.
  • Invalid Connection Request (CVE-2019-19195) — When devices do not properly handle some connection parameters while the central attempts a connection to the peripheral, they could lead to Deadlock state.
  • Unexpected Public Key Crash (CVE-2019-17520) — This bug is present in the implementation of the legacy pairing procedure, which is handled by the Secure Manager Protocol (SMP) implementation, and can be used to perform DoS and possibly restart products.
  • Sequential ATT Deadlock (CVE-2019-19192) — This flaw lets attackers deadlock the peripheral by sending just two consecutive ATT request packets in each connection event.
  • Invalid L2CAP fragment (CVE-2019-19195) — improper handling of the PDU size of the packets can lead to deadlock behavior.
  • Key Size Overflow (CVE-2019-19196) — This overflow in the device memory issue is a combination of multiple bugs found during the pairing procedure of devices, resulting in a crash.
  • Zero LTK Installation (CVE-2019-19194) — This critical vulnerability is a variation of one of the Key Size Overflow. It affects all products using Telink SMP implementation with support for secure connection enabled.
  • BLUEFRAG (CVE-2020-0022) —  In reassemble_and_dispatch of packet_fragmenter.cc, there is possible out of bounds write due to an incorrect bounds calculation. This could lead to remote code execution over Bluetooth with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-8.0 Android-8.1 Android-9 Android-10Android ID: A-143894715

Quindi un malintenzionato che si trovi fisicamente  nelle vicinanze ai dispositivi vulnerabili può  abusare di una o più  vulnerabilità per attivare in remoto deadlock, DoS, crash e persino bypassare la sicurezza nei prodotti con privilege escalation, consentendogli di accedere in modo arbitrario a lettura o scrittura alle funzioni del dispositivo, in quanto alla prossimità dell’attaccante non sono sicuro che la distanza debba essere così minima (viene indicata nel BLE di circa 1 metro) in quanto le effettive distanze possono essere notevolmente maggiori, nello standard Bluetooth il segnale contenente il proprio UIID (Identificativo univoco) dovrebbe poter raggiungere una distanza di circa 10 metri che può essere però influenzata da fattori locali come ostacoli, alberi persone o altro, ma altresì gli strumenti usati da un attaccante possono utilizzare sistemi trasmissivi di maggiore potenza e sensibilità ricettiva portando questi limiti a qualche centinaio di metri ( da motociclista il sistema di interfono bluetooth che utilizzo su i miei caschi copre oltre 500 metri ……) .

Immuni quindi provvede a scambiare , in modalità criptata, il proprio identificativo con il device che si trova in prossimità consentendo uno scambio di informazioni sicuro, la vulnerabilità non risiede quindi nell’applicazione ma nel sistema di comunicazione.

Mitigare queste vulnerabilità mantenendo attiva questa ( o altre) applicazione risulta alquanto difficoltoso, anche se i produttori cercano di aggiornare i loro device per tamponare queste falle, come suggerimento agli sviluppatori proporrei che i sistemi almeno segnalassero i tentativi di “pairing” (connessione di devices bluetooth) ogni qualvolta vi sia un tentativo soprattutto  se non viene richiesta una chiave di accesso

Per quanto esposto il bilanciare la necessità di tracciamento (volontario) di “IMMUNI” e i rischi di un attacco al Bluetooth rimane delegato alla responsabilità civica di ognuno di noi ma, al contempo, impone agli sviluppatori di provvedere, per quanto possibile, alla protezione del sistema di comunicazione (il BLE) per mitigare anche quelle minacce che oggi giorno sono comunemente presenti nella nostra vita cibernetica.

Leave a reply