Rischio di Cybersecurity nei dispositivi Bluetooth Low Energy (BLE)

Autori: Ramakrishnan Lakshminaryan e Jasper Nota

I dispositivi con connessione Bluetooth Low Energy (BLE) sono oggi molto diffusi. Tuttavia, potrebbero essere poco sicuri da usare. Questo accade quando il BLE è implementato in modo insicuro. Per dimostrare il rischio di cybersecurity di tali dispositivi, abbiamo scelto un dispositivo medico che può essere ordinato dai consumatori in diversi negozi web famosi.

Nota: prima di pubblicare questo articolo, sono stati fatti diversi tentativi per informare il produttore di apparecchiature originali (OEM) sulle vulnerabilità scoperte e sulle conseguenze che ne derivano. Purtroppo, non è stata ricevuta alcuna risposta dall'OEM. Bureau Veritas Cybersecurity ha scelto di pubblicare questo articolo per aumentare la consapevolezza della sicurezza tra i produttori e gli utenti.

Molteplici problemi di sicurezza

Nel corso della breve indagine condotta, sono stati osservati diversi problemi di sicurezza. Ai fini di questo articolo, saranno resi noti solo i rischi legati alla funzionalità BLE.

Il dispositivo medico

Il Dispositivo Sotto Test (DUT) è un dispositivo certificato dal punto di vista medico che consente agli utenti di alleviare il dolore, rilassare o rafforzare i muscoli attraverso gli elettrodi. Questo dispositivo può essere controllato utilizzando l'applicazione Android associata (v4.3.15 al momento del test di questo dispositivo).

L'intera funzionalità dipende dall'intensità impostata dal dispositivo centrale o periferico. In base al valore di intensità [min = 0; max = 60], la vibrazione può essere percepita sul corpo tramite gli elettrodi patch. A seconda della parte del nostro corpo in cui vengono applicati gli elettrodi patch, ci sono rispettivamente una serie di programmi di allenamento, relax e recupero.

I test sono iniziati attaccando i cerotti alle braccia o alle gambe. L'osservazione (durante il test sul braccio) è stata che dopo che il valore dell'intensità ha superato 25, il braccio ha subito un violento scuotimento. L'intensità controllava il movimento del braccio, rendendo difficile resistere al movimento. Queste vibrazioni possono diventare scosse gravi a intensità più elevate o durante i cambiamenti improvvisi di intensità.

I nostri servizi e le caratteristiche

È stata avviata una scoperta BLE per identificare l'indirizzo Media Access Control (MAC) associato al DUT. Una volta identificato, è stato possibile enumerare i servizi e le caratteristiche, che sono oggetti nidificati responsabili della gestione dei dati trasmessi:

Notare come più maniglie abbiano la proprietà WRITE indicata per il DUT. Ciò significa che questi handle accettano i dati in arrivo dal dispositivo centrale, che in questo caso è il telefono cellulare.

Tra gli handle elencati con accesso in scrittura, ce n'erano diversi interessanti, che sono elencati di seguito:

(1) Maniglia 0007 - Flag privacy periferica

Questo flag è esplicitamente legato alla funzione di privacy del dispositivo periferico. In altre parole, è il flag che determina se la periferica supporta la privacy - abilitata o disabilitata. Verificare se questo handle può essere sovrascritto/toccato sarebbe una delle cose interessanti per un aggressore.

(2) Maniglia 000b - Indirizzo di riconnessione

Questo handle contiene informazioni relative all'indirizzo da utilizzare al momento della riconnessione a un dispositivo privato. Poiché questo handle è anche un punto di interesse dal punto di vista di un aggressore, volevamo verificare se può essere sovrascritto.

(3) Maniglie 0010, 0011, 0012, 0013 - Relative alle intensità di vibrazione

Questi handle contengono valori di intensità delle vibrazioni e anche in questo caso sarebbero interessanti da sovrascrivere per un aggressore.

Come si può vedere nella figura precedente, il Flag Privacy Periferica [Maniglia 0007] è stato sovrascritto. Quindi, si conclude che può essere disabilitato e abilitato. Allo stesso modo, anche il campo 'Indirizzo di riconnessione [Maniglia 000b]' potrebbe essere sovrascritto, come mostrato nella figura seguente. Le figure relative alla sovrascrittura dei valori di intensità della vibrazione sono mostrate nella prossima sezione di questo articolo.

Esistono diversi metodi per analizzare il traffico BLE tra i dispositivi, utilizzando vari strumenti hardware e software.

Uno dei primi che abbiamo preso in considerazione è stato quello di catturare passivamente il traffico BLE utilizzando Ubertooth One e successivamente analizzare i pacchetti con Wireshark. Di seguito è riportata una schermata che mostra la cattura di un pacchetto con Wireshark. È stato possibile esaminare le informazioni relative al valore dell'intensità della vibrazione, al tipo di protocollo utilizzato e alle informazioni delle maniglie:

Nella schermata precedente, si può notare che i pacchetti catturati utilizzano il protocollo ATT. ATT, noto anche come protocollo Attribute, fa parte dello stack BLE, che definisce rigorosamente come i dati devono essere rappresentati in un database del server BLE e definisce anche il modo in cui i dati possono essere letti o scritti.

Un altro approccio per analizzare le comunicazioni BLE consiste nell'utilizzare la tecnica di snooping HCI su un cellulare Android rooted. Fondamentalmente, un dispositivo Android rooted è un dispositivo modificato che consente all'utente l'accesso come superutente. Il processo di rooting di un dispositivo consiste nell'infrangere una serie di limitazioni prestabilite dal produttore del dispositivo, per ottenere il controllo completo del sistema operativo. In questo modo, si eleva ai privilegi di amministratore. Una volta stabilito l'accoppiamento/comunicazione BLE, i registri di snoop possono essere estratti dal dispositivo radicato per analizzare i pacchetti catturati.

I metodi sopra menzionati erano per lo più uno sniffing passivo della comunicazione BLE per raccogliere informazioni sul processo di accoppiamento, sul tipo di protocolli in atto, sull'indirizzo MAC del DUT, sui diversi handle, ecc.

Per interagire attivamente con i diversi handle, è stato utilizzato lo strumento Bettercap, in combinazione con un dongle Bluetooth. I risultati di questo approccio sono presentati in precedenza in questo articolo.

Dirottare la comunicazione

Ora che la comunicazione tra il dispositivo centrale e quello periferico è stata analizzata, si è cercato di stabilire una posizione Man-in-the-Middle (MiTM).

Lo screenshot qui sotto mostra come una connessione BLE legittima tra il dispositivo mobile e il DUT sia stata dirottata con successo. Ciò significa che il dispositivo centrale è ora la macchina dell'aggressore, invece del telefono cellulare:

Quando il dirottamento BLE è in corso, sullo schermo del cellulare e sul pannello frontale del DUT appaiono delle indicazioni che indicano un comportamento non regolare.

Indicazione 1: il DUT è acceso; nessun programma di allenamento è attivo sull'applicazione Android. Normalmente, se un utente abbandona l'allenamento, il DUT dovrebbe spegnersi dopo pochi secondi (comportamento regolare). Pertanto, è impossibile che il dispositivo sia in stato ON quando l'applicazione non esegue alcun programma, a meno che non sia mantenuto ON da una connessione BLE attiva da un altro dispositivo centrale. Questo dimostra che l'applicazione Android non controlla più il dispositivo, ma che l'aggressore ha ora il controllo del dispositivo.

Indicazione 2: il DUT è acceso; l'applicazione Android cerca di riconnettersi al DUT, ma fallisce con un messaggio che dice che l'utente deve accendere il DUT. Tuttavia, il DUT è già acceso e l'attaccante sta eseguendo un programma di allenamento attivo.

Quindi, le indicazioni di cui sopra indicano che l'aggressore stabilisce una posizione MiTM.

Una volta stabilita una posizione MiTM, è stato possibile osservare la comunicazione tra il cellulare e il DUT in formato HEX.

Si è osservato che, per lo stesso valore di intensità di vibrazione, nei pacchetti BLE catturati c'erano due formati di dati HEX:

1. Dati dal dispositivo periferico al dispositivo centrale -> Formato dati 1 o DF1.
2. Dati dal dispositivo centrale al dispositivo periferico -> Formato dati 2 o DF2.

Per esempio, consideriamo il valore di intensità della vibrazione 31.
Per lo stesso valore, sono stati osservati due diversi formati di dati durante i test.

Il DF1 per il valore 31 è stato acquisito come mostrato di seguito:
Dati LL: 06 1b 17 00 04 00 1b 12 00 4e 4f 54 49 46 59 20 73 74 72 65 6e 67 74 68 20 33 31 0d 0a

Il DF2 per il valore 31 è stato acquisito come mostrato di seguito:
Dati LL: 02 10 0c 00 04 00 52 55 00 3e 73 74 72 20 33 31 0d 0a
Dati LL: 0a 0f 0b 00 04 00 1b 55 00 73 74 72 3d 33 31 0d 0a

Entrambi i formati indicano che la forza o l'intensità della vibrazione sui patch elettrodici deve essere 31.

La percentuale di successo è stata maggiore con DF2, mentre si cercava di sovrascrivere l'handle che contiene il valore dell'intensità della vibrazione. Questo avrebbe senso, in quanto il dispositivo dell'aggressore è il nuovo dispositivo centrale dopo aver dirottato la connessione BLE, e quindi DF2 funzionerebbe in questo caso. Tuttavia, si sono verificati alcuni scenari interessanti basati sull'approccio di cui sopra.

1. Mentre si trovava a un valore di intensità o forza più alto e si sovrascriveva la maniglia 0x12 con un valore più basso, ha funzionato, in quanto c'è stato un cambiamento notevole nell'intensità della vibrazione, che poteva essere percepita sulla parte del corpo in cui sono stati bloccati gli elettrodi patch [mano/gamba]. Tuttavia, è tornata al valore originale dopo un certo periodo di tempo.
   
2. Anche se la presenza di un valore di intensità o forza inferiore e la sovrascrittura dell'impugnatura 0x12 con un valore più alto hanno funzionato, è durata solo per un periodo di tempo molto limitato prima di tornare al valore originale. Inoltre, questo accadeva quando il delta/differenza tra il valore originale e il valore sovrascritto era piccolo.
3. Mentre l'intensità o il valore di forza più basso e la sovrascrittura della maniglia 0x12 con un valore più alto con un grande delta/differenza rispetto all'intensità originale, non ha causato alcuna differenza visibile nella vibrazione del corpo. Come pensiero forte, questo potrebbe essere dovuto a qualche valore di soglia delta impostato nel DUT. Non abbiamo approfondito questa parte della sperimentazione, poiché il dirottamento della comunicazione BLE era il nostro obiettivo e scopo.

I seguenti dati HEX sono stati inviati al dispositivo:

Dopo la sovrascrittura dell'handle 0x12, la modifica dell'intensità della vibrazione poteva essere percepita sulla parte del corpo a cui erano collegati gli elettrodi. Questo dimostra che un aggressore ha il pieno controllo sull'intensità impostata per gli elettrodi.

Conclusione

Abbiamo dimostrato come un aggressore possa abusare delle comunicazioni BLE quando i fornitori implementano BLE in modo insicuro, il che potrebbe causare gravi danni agli utenti finali.

Molti altri dispositivi smart presenti sul mercato hanno ancora un'implementazione insicura del Bluetooth Low Energy (BLE). Lei è nel settore dei dispositivi intelligenti basati su BLE? Le consigliamo vivamente di valutare i suoi prodotti sia dal punto di vista funzionale che della sicurezza.