Red Hot Cyber
La cybersecurity è condivisione. Riconosci il rischio, combattilo, condividi le tue esperienze ed incentiva gli altri a fare meglio di te.
Fernando Curzi : 18 Gennaio 2022 15:40
Autore: Curzi Fernando L. (Cybersecurity analyst e Autore di Hackerpunk)
Data pubblicazione: 18/01/2022
Bluetooth BT è uno standard tecnico di trasmissione dati per reti personali senza fili chiamate WPAN Wireless Personal Area Network. Si basa sulla comunicazione a bassa potenza 2,4 – 2,448 GHz utilizzando lo spettro di diffusione con un salto di frequenza a 1600 hop/s che permette di avere una misura di sicurezza aggiuntiva. E’ stato sviluppato nel 1994 da Ericsson coop., in seguito formalizzata dalla Bluetooth Special Interest Group (SIG) di cui fanno parte anche Sony, IBM, Intel, Toshiba e Nokia che oltre essere proprietari del marchio gestiscono anche il programma di qualificazione il cosiddetto Bluetooth SIG, un processo di certificazione richiesto per qualsiasi prodotto che utilizza questa tecnologia.
La specifica minima per la portata del Bluetooth è 10m, ma questo limite non vieta i produttori di implementare specifiche diverse nei propri dispositivi, in effetti questa caratteristica di avere una “progettazione libera” come vedremo è la causa principale di molte delle vulnerabilità di BLE.
Vuoi diventare un Ethical Hacker?
Non perdere i nostri corsi e scrivi subito su WhatsApp al numero
375 593 1011
per richiedere informazioni dicendo che hai trovato il numero sulle pagine di Red Hot Cyber
Supporta RHC attraverso:
Ti piacciono gli articoli di Red Hot Cyber? Non aspettare oltre, iscriviti alla newsletter settimanale per non perdere nessun articolo.
Ogni dispositivo compatibile con la tecnologia Bluetooth è dotato di un chip a basso consumo energetico che definisce una Classe di copertura di rete e in base ad uno dei tre livelli della classe ne estende o meno la portata. La connessione tra dispositivi Bluetooth inoltre stabilisce dei ruoli d’azione, creando nello stesso tempo una rete molto piccola che prende anche il nome di Piconet.
La Piconet è composta di un dispositivo principale avente un ruolo Master (maestro) e uno o più dispositivi periferici aventi ruoli Slave (schiavi). Il dispositivo principale (master) è quello al quale dovrà essere collegata la periferica (slave). Una Piconet può contare di un solo dispositivo master e fino a sette slave, un master invece può collegarsi a un dispositivo slave per volta. Le fasi che accompagnano una connessione tra due dispositivi Bluetooth sono principalmente cinque e offrono di base un certo grado di sicurezza.
Nella fase di rilevamento Inquiry, il dispositivo master invia una richiesta di accesso a tutti gli slave presenti nel suo raggio di copertura, gli stessi prendono anche il nome di punti di accesso AP, le periferiche rispondono con il loro indirizzo composto dall’associazione Nome/indirizzo MAC, in questa fase i dispositivi costantemente si scambiano segnali di rilevazione sotto forma di piccoli pacchetti dalle dimensioni ridotte, mostrando agli altri dispositivi le seguenti informazioni tecniche: Nome, Classe, Servizi.
Il Nome identifica ogni dispositivo nella piconet, corrisponde come appena detto ad una relazione tra nome del dispositivo e indirizzo MAC della scheda di rete.
La Classe specifica il raggio di copertura del dispositivo; i Servizi sono delle specifiche che estendono le funzionalità delle versioni Bluetooth in maniera simile ai driver. Sono definiti sotto forma di profili, di seguito alcuni esempi dei principali profili:
La fase di Sincronizzazione Paging avviene attraverso la scelta del master al quale lo slave vuole sincronizzarsi, in questa fase viene sincronizzato il clock e la frequenza con il punto di accesso.
Subito dopo si stabilisce un legame con la periferica scelta dal master e incomincia la fase enumerativa sui servizi offerti, per lo scopo è utilizzato un profilo specifico SDP Service Discovery Protocol.
Terminata anche quest’ultima fase, il master è finalmente in grado di cercare un canale di comunicazione con la periferica utilizzando il protocollo L2CAP. In base all’esigenza del servizio si potrebbe optare su un canale supplementare e funzionante su L2CAP, noto come RFCOMM, utile per fornire una porta seriale virtuale, alcune applicazioni sono state progettate per connettersi a una porta standard indipendentemente dall’hardware usato, è il caso delle applicazioni di navigazione GPS.
A partire dalle nuove versioni è stato implementato un meccanismo di sicurezza aggiuntivo chiamato Pairing (accoppiamento), il quale permette di limitare l’accesso ai soli utilizzatori autenticati, questo per garantire un certo livello superiore di protezione sulla piconet. Il pairing avviene solo una volta tra gli stessi dispositivi e si svolge attraverso l’inserimento di un codice segreto PIN sul display (se presente). La periferica slave invia una richiesta di pairing al dispositivo master il quale richiederà l’intervento manuale dell’utente per inserire il codice sul proprio display, se quest’ultimo viene inserito correttamente avverrà l’associazione che in gergo tecnico vuol dire stabilire una chiave lunga e duratura, utile per le connessioni future con lo stesso dispositivo.
In modalità sicura (secure mode) il codice PIN sarà trasmesso in modalità cifrata con l’aiuto della generazione di una seconda chiave detta anche chiave pubblica (crittografia simmetrica).
Ad avvenuto Pairing tra master e slave, il master sarà libero di utilizzare il canale stabilito, di seguito si mostra un processo di pairing tra due dispositivi master/slave:
Il profilo GATT acronimo di Generic Attribute Profile. Le specifiche del profilo hanno permesso l’inserimento del chip all’interno di dispositivi dalle dimensioni ridotte sfruttando oltretutto una crittografia per le chiavi a 128 bit, permettendo il rilevamento e l’enumerazione sui dispositivi dotati di BLE. In seguito uscirono la versione 4.1, 4.2 e in particolare l’ultima v. 5.0 che continua a specializzarsi nei dispositivi ioT acronimo di Internet of things.
In questo scenario è permesso fare una netta divisione dell’evoluzione tecnologica dello stack Bluetooth, partendo dal Bluetooth Classic BR/EDR fino alla versione 3.0 e Bluetooth LE dalla v. 4.0 fino alle successive e attuali, questa distinzione sarà utile per comprendere le varie vulnerabilità e gli attacchi che ne derivano.
Bluetooth BR si è dedicato a dispositivi quali: smartphone, cuffie, auricolari, elettrodomestici, autovetture, ma il trampolino di lancio è avvenuto sui con l’introduzione di BLE, grazie al Low Energy il Bluetooth è entrato nelle nostre case con prodotti indossabili di dimensioni notevolmente ridotte come: telecomandi, bracciali, occhiali, tazze, dispositivi medici, lampadine e molto altro, si è sviluppato all’interno di tecnologie mediche, industriali e militari come i cardiofrequenzimetri, termometri, apparecchiature per protesi, pacemaker, dispositivi per l’esercito e dispositivi industriali. Alcuni dispositivi ioT sono di scarso interesse in tema di sicurezza e privacy, ma altri mettono seriamente in discussione queste realtà.
Se prendessimo come riferimento alcuni dispositivi Bluetooth come: serrature e lucchetti, allarmi domestici, sensori di sicurezza biometrica per le attività bancarie, token, keypass o altri dispositivi di tracciamento della posizione, ne potremmo dedurre un potenziale rischio reale sulla sicurezza delineato dai principali standard della cyber security. BLE, grazie anche alle modifiche apportate sullo stack e con l’integrazione del profilo GATT, ha riesaminato la struttura dei servizi e i protocolli con i quali i dispositivi si scambiano i dati.
La modalità di esposizione di tali informazioni tecniche da parte della periferica slave può essere intesa in maniera similare a ciò che avviene su un classico server. La specifica è definita dal protocollo ATT acronimo di Attribute Protocol che si trova al livello sottostante del profilo GATT, fondamentalmente sono presenti due ruoli in questo protocollo il server e client. Il server è il dispositivo che espone i dati e accetta i comandi in arrivo da un dispositivo principale, invia risposte, notifiche e indicazioni, il client è il dispositivo che s’interfaccia con il server allo scopo di leggere tali dati esposti, invia comandi e richieste e riceve notifiche e indicazioni. I dati che il server espone sono chiamati Attributi. Un attributo è composto di alcuni elementi essenziali:
Il profilo GATT definisce il formato e le procedure utilizzate per interfacciarsi con gli attributi, inoltre specifica in che modo devono essere classificati i Profili, Servizi e Caratteristiche.
Il Profilo indica la classe globale degli attributi e solitamente un profilo non è esposto dal server. Il Servizio è un raggruppamento di uno o più attributi alcuni dei quali sono caratteristiche, altri invece possono essere semplici attributi non caratteristiche.
L’immagine di seguito illustra come si presentano gli attributi nel profilo GATT, è utile comprendere anche i diversi attributi di cui è composto un servizio:
• Uno o più servizi d’inclusione : Si tratta di servizi primari o secondari richiamati dal server che estendono le funzionalità del dispositivo;
• Una o più caratteristiche : Definite da: proprietà, valori e descrittori.
I codici descrittori sono dettagli sul formato del dato, i principali due descrittori utilizzati nei dispositivi BLE sono:
Le caratteristiche hanno la proprietà di essere lette, scritte, modificate e mostrate nelle notifiche dell’applicazione mobile con la quale il dispositivo comunica. Ogni servizio e caratteristica è identificato da un UUID associato.
Nella fase di Enumerazione il dispositivo BLE principale (master) esegue una scansione sul dispositivo associato (slave), enumerando su tutti i servizi e caratteristiche disponibili che esso espone, mentre le richieste di scrittura, lettura e notifica di valori avvengono esclusivamente se l’azione è autenticata. Questo processo indica che deve essere stata eseguita preventivamente un’associazione tra dispositivi per enumerare sui servizi. Poiché il processo di scansione dei servizi richiede diverse richieste e risposte (request, reply) i firmware dei dispositivi al fine di ottimizzare il processo, memorizzano i valori trasmessi in scrittura e lettura nelle rispettive cache si sistema.
La sicurezza Bluetooth si basa su alcune tecniche, la prima è stata citata quando è stata descritta l’architettura del Bluetooth classico ovvero il salto di frequenza generato da un algoritmo di frequenza conosciuto esclusivamente dal master e dalla periferica slave. In secondo luogo, dalla chiave precondivisa a 128 bit di tipo AES-CCM scambiata al momento del pairing e utilizzata per l’autenticazione e la cifratura dei dati trasmessi. Il processo di pairing varia leggermente tra le versioni 4.2 e successive rispetto alla 4.1- 4.0. Il processo di associazione nelle versioni 4.1 è noto anche come LE Legacy Pairing, esso utilizza un protocollo di scambio personalizzato delle chiavi: In questa configurazione, i dispositivi scambiano una chiave temporanea (TK) Term key e la utilizzano per creare un’ulteriore chiave (STK) Short Term Key, quest’ultima è utilizzata per cifrare la connessione, la sicurezza di questo processo dipende molto dalla modalità di scambio della chiave TK. Il processo di scambio si può distinguere in tre fasi importanti ognuna con delle caratteristiche ben precise da esaminare nel dettaglio:
I dispositivi BLE 4.2 sono totalmente retro-compatibili, ciò comporta che sono in grado di eseguire lo stesso processo di associazione utilizzato dalle versioni precedenti, inoltre sono capaci di aggiungere un ulteriore livello di protezione creando una connessione nota come: LE Secure Connections. Il processo sostituisce le doppie chiavi (TK) e (STK) con una singola (LTK) Long Term Key. La chiave LTK sarà scambiata utilizzando un algoritmo noto come (ECDH) Elliptic Curve Diffie Hellman, che offre una sicurezza maggiore rispetto al LE legacy pairing.
Fin qui sono state descritte le funzionalità di sicurezza definite dal SIG e implementate su tutti i dispositivi dotati di Bluetooth. Il SIG ha disposto che ulteriori implementazioni di sicurezza dovranno essere lasciate nelle mani delle case produttrici di dispositivi che in base alle funzioni che decideranno di implementare possano o meno in autonomia sviluppare misure di sicurezza personalizzate. Principalmente i livelli base di sicurezza Bluetooth sono tre:
La chiave di cifratura AES a 128 bit permette di avere un certo grado di protezione dagli attacchi di tipo brutal force ma non contro gli attacchi Man in the middle e più in generale da attacchi di intercettazione di dati. I metodi utilizzati nello scambio delle chiavi sono inefficaci per la sicurezza dei dispositivi BLE. I metodi sottoelencati riguardano soprattutto i dispositivi che si interfacciano con la rispettiva applicazione mobile:
In questo metodo la chiave TK è impostata su 0, pertanto diventa molto semplice per un’attaccante forzare la chiave STK e intercettare la connessione, non offre una buona protezione dagli attacchi da intercettazione.
In questo metodo la chiave TK è rappresentata da un codice di sei cifre che è richiesto da un dispositivo periferica a quello principale, il codice sarà letto dall’utente sul display e dovrà essere inserito nel dispositivo che lo richiede. Questo metodo offre una discreta protezione dagli attacchi da intercettazione a patto che il processo di pairing non avvenga sotto operazioni di sniffing in questo caso sarà semplice ricavare la chiave TK per derivare successivamente la chiave STK per decifrare la connessione.
In questo metodo la chiave TK è scambiata utilizzando un’altra tecnologia Wi-Fi come per esempio NFC. Questo metodo è maggiormente più sicuro dei precedenti a patto che il canale OOB sia sicuro contro gli attacchi da intercettazione, se così non fosse, la connessione potrebbe essere decifrata.
Il fatto per BLE di essere solo un protocollo, ha indotto il SIG a lasciare liberi i produttori di implementarlo in maniera sicura nei propri dispositivi. I dispositivi BLE sono stati progettati per migliorare l’esperienza utente integrando al loro interno un chip di dimensioni molto ridotte, riservando molta meno importanza alla sicurezza e la privacy.
Tralasciando le innumerevoli vulnerabilità e tipologie di attacco che negli anni a venire hanno portato il Bluetooth classico a collocarsi nel mirino degli hacker attraverso alcuni dei noti attacchi Bluetooth: Bluesmack, Blueborne, Bluejacking, Bluebugging, Bluesnarfing, alcuni prevedono la disconnessione forzata dei dispositivi, altri come il Bluejacking permettevano di accedere alle funzioni dello smartphone come rubrica, calendario o sms. Fortunatamente nel tempo attraverso il rilascio di rolling patches di aggiornamento nei sistemi operativi, si è riusciti ad arginare i relativi exploit, ma queste soluzioni non sono state sufficienti a rimediare alle grosse falle nello stack dei protocolli utilizzati dal Bluetooth.
Ad oggi in ambito violazioni Bluetooth sono utilizzate tecniche orientate molto più verso l’intercettazione attiva di dati come visto per gli attacchi Man in the middle, enti e ricercatori accademici in campo elettronico e informatico hanno classificato alcune gravi vulnerabilità attraverso dimostrazioni pratiche chiamate Poc acronimo di Proof of concept.
Dopo questo lungo epilogo utile per comprendere le tecniche di attacco vediamo di cosa stiamo parlando:
La vulnerabilità BIAS è stata scoperta nel 2019 da un team di ricercatori dell’università di Lausanne tra i quali fa parte anche l’italiano Roberto Antonioli. La tecnica di attacco colpisce il meccanismo di pairing utilizzato per l’associazione dei dispositivi e successiva comunicazione. Il sistema è implementato nell’architettura del Bluetooth classic ed ereditato in parte anche nel BLE, un tipico attacco di questo genere si compone in questo modo:
Si utilizza un sistema operativo Gnu/Linux ottimizzato ad hoc e una scheda a basso costo tipo Arduino o Raspberry, attraverso un’applicazione mobile di diagnostica come può essere NRF Nordic connect, si clona u n dispositivo slave o master.
precedentemente associati tra loro attraverso il meccanismo di pairing. Nello scenario preso in considerazione nella quale è clonato un dispositivo slave, il dispositivo master assumerà il ruolo di vittima. La tecnica BIAS descritta prevede che l’attaccante attraverso un copia esatta del dispositivo impersonato (clone), si sostituisca a esso recuperandone tutte le caratteristiche e specifiche tecniche tra le quali anche l’associazione al master (chiave).
Il master riconoscerà il dispositivo clonato come autentico derivandolo dalla relativa chiave precondivisa anch’essa clonata, questa tecnica permetterebbe di eludere il sistema di pairing in quanto dimostra che non vige nessun controllo o checksum di autenticità sulla chiave clonata.
Analizzando questa tecnica si può affermare che il BIAS assume diverse similitudini con gli attacchi Man in the middle e attualmente rimane una pericolosa minaccia per milioni di dispositivi che da dicembre 2019 a oggi non hanno ancora ricevuto le patch di aggiornamento. La vulnerabilità permetterebbe ad un malintenzionato di collegarsi al dispositivo vittima fingendo di essere il dispositivo autentico con tutti i vantaggi che seguono.
La tecnica BIAS inoltre prevede che l’attaccante conosca preventivamente l’indirizzo Mac del dispositivo impersonato che è stato precedentemente associato al rispettivo master, inoltre per essere portato a termine deve trovarsi nel raggio di copertura della rete Wpan.
La vulnerabilità BLESA è particolarmente nuova e mette a rischio miliardi di dispositivi dotati del modulo BLE, è stata scoperta dai ricercatori di sicurezza dell’università di Purdue e riguarda in particolar modo i dispositivi ioT dotati del Low Energy Bluetooth. La vulnerabilità colpisce il processo di riconnessione tra due dispositivi BLE. La riconnessione avviene quando i due dispositivi dopo aver superato il limite del raggio di copertura, tornano nelle vicinanze. In questa fase si autenticano nuovamente scambiandosi le chiavi crittografiche registrate in fase di pairing in modo da continuare a comunicare tra loro. Il problema evidenziato dai ricercatori sta nel fatto che le specifiche di BLE non contengono un controllo sufficientemente sicuro che descrive il processo di riconnessione, ne consegue due problematiche principali:
Come per il Bias anche l’attacco Blesa prevede che un attaccante si trovi nel raggio di copertura dei dispositivi vittima, lo stesso potrebbe attraverso questa vulnerabilità aggirare le verifiche relative alla riconnessione, intercettare il traffico e trasmettere dati falsificati.
La vulnerabilità Blurtooth è stata scoperta dai ricercatori dell’Ecole Polytechnique Fèdèrale de Lausanne e della Purdue University, il problema risiederebbe nelle versioni 4.2 e 5.0 dello standard Bluetooth in quanto la v. 5.1 già risulterebbe mitigata. La vulnerabilità colpisce il processo di accoppiamento CTKD acronimo di Cross –Transport Key Derivation, utilizzato per la negoziazione e la gestione delle chiavi di autenticazione. Questa componente si occupa di gestire e configurare due diversi insiemi di chiavi di autenticazione, rispettivamente per gli standard (BR/EDR) ovvero Bluetooth classic e (BLE) Bluetooth Low Energy.
Questo sistema è stato progettato per far in modo di avere sempre pronto all’uso le relative chiavi, delegando i dispositivi di decidere durante la fase di pairing quale versione dello standard utilizzare con il rispettivo gruppo di chiavi. Anche questo attacco prevede che un malintenzionato debba trovarsi nel raggio di copertura dei dispositivi vittima, l’abbinamento si dovrà trovare in modalità JustWork (nessuna restrizione di accesso), in modo da non esserci l’interazione dell’utente, si riuscirebbe così a compromettere il processo CTKD in modo da sovrascrivere completamente le chiavi di autenticazione oppure declassandole ad un livello minore per sfruttare un protocollo di crittografia meno robusto del precedente.
Lo Sniffing Passivo di dati scambiati è una tecnica di monitoraggio del traffico dei pacchetti frame Bluetooth che vengono continuamente scambiati tra dispositivi, non comporta manipolazioni o interventi attivi sul dispositivo vittima da parte dell’attaccante a meno che non evolve in intercettazione attiva, prevede esclusivamente l’analisi dei pacchetti frame scambiati tra dispositivi come per esempio un applicazione che gestisce i colori di una lampada BT i valori scambiati in scrittura o lettura sono essenziali per il funzionamento del dispositivo. Fortunatamente questa vulnerabilità non risulta pericolosa come le precedenti poiché è stata messa in protezione dal protocollo GATT che nelle nuove versioni sui dispositivi dotati di Ble è quasi inesistente.
In sede preliminare è doveroso esporre i principali 4 difetti di progettazione del Bluetooth Low Energy:
Il difetto di progettazione nr 3 e nr 4 sotto certi aspetti si presentano interessanti, per comprendere meglio l’attacco, si dovrà partire dall’analisi del difetto di progettazione nr 3:
Si prendano due dispositivi che sono stati già associati tramite il relativo processo di pairing: un dispositivo master (smartphone Android con relativa applicazione) e un dispositivo slave (saturimetro digitale BLE), è stabilita quindi una chiave LTK per entrambi. Ora si immagini che il dispositivo slave rimuova la chiave attraverso un ripristino delle impostazioni di fabbrica.
Il dispositivo Android richiederà una nuova connessione al dispositivo saturimetro il quale risponderà con un codice di errore 0x06 (pin o chiave mancante) in quanto non riconoscerà la chiave LTK rimossa dal reset. Tuttavia il sistema android non notificherà questa situazione all’utente, permettendo la comunicazione di testo in chiaro non cifrato.
In secondo luogo se il dispositivo android tentasse di accedere al dispositivo slave ad un attributo in lettura o in scrittura in modalità crittografata, il dispositivo dovrà verificare se effettivamente la connessione risulta tale, in caso contrario rifiuterà di fornire le informazioni richieste rispondendo con un errore 0x05 (autenticazione fallita).
A questo punto il dispositivo android avvierà il processo di connessione automatica con il dispositivo slave, in questa circostanza l’applicazione android non è in grado di interrompere il processo di associazione perché in realtà non ne sarebbe nemmeno a conoscenza (è il difetto di progettazione nr 3 di android/BLE, non riconosce che la chiave ltk dello slave è stata rimossa dal reset, non notifica all’utente questa rimozione o dell’errore 0x06, si riassocia stabilendo in automatico allo slave comunicando in modalità non cifrata).
Difetto di progettazione nr 4:
Se un’applicazione determina che una connessione è inappropriata per un qualsiasi motivo potrebbe interromperla, tuttavia non riuscirebbe a rimuovere le chiavi generate derivanti dall’associazione, ciò vuol dire che non potrebbe avviare un nuovo processo di associazione sicuro con il dispositivo collegato usando per esempio una nuova chiamata alla funzione createBond().
Si supponga che un attaccante si trovi nel raggio di copertura tra due dispositivi già regolarmente associati tramite il processo di pairing con le relative chiavi LTK, si prenda come esempio pratico gli stessi dispositivi citati in precedenza, ovvero smartphone android con sua applicazione e saturimetro digitale che invia i valori di ossigeno e pressione sanguigna all’applicazione.
L’attaccante innanzitutto si vorrebbe assicurare del fatto che il saturimetro non dovrà rispondere più all’applicazione android dello smartphone vittima, per far ciò utilizzerà uno smartphone hacker nr 1 impostato con un delay minore di scansione, all’incirca ogni 100 msec rispetto al delay dello smartphone vittima di 5 sec.
Questa situazione si tradurrà in questo modo: all’accensione del dispositivo saturimetro lo smartphone hacker nr 1 avrà una probabilità maggiore di rilevare i pacchetti di adversiting inviati dal saturimetro rispetto alla probabilità dello smartphone vittima.
Illustrazione 1: configurazione scansione BLE
Una volta che lo smartphone hacker nr 1 rileverà il saturimetro, si maschererà simultaneamente da fittizi dispositivi master, inviando senza interruzioni nuove richieste di scansione/associazione fino a saturare le limitate risorse del dispositivo slave in modo simile ad un attacco Dos, cercando di bloccare la rilevazione da parte di altri dispositivi regolari e già associati che in questo caso corrisponde a quello del dispositivo vittima che si vorrà connettere per il suo utilizzo.
Illustrazione 2: saturazione risorse slave
A questo punto l’attaccante introdurrà un secondo smartphone hacker nr 2 mascherato da dispositivo saturimetro che si posizionerà nel raggio di copertura dello smartphone vittima e invierà annunci di scansione, per l’appunto l’attaccante avrà preventivamente clonato i parametri MAC/Name reali del saturimetro attraverso per esempio l’applicazione NRF Nordic connect.
Lo smartphone vittima eseguirà la scansione ricevendo la risposta dallo slave mascherato e effettuerà una richiesta di connessione, poiché lo smartphone hacker 2 non ha memorizzato la chiave LTK durante il legittimo processo di pairing causerà l’errore 0x06 (pin o chiave mancante) permettendo una comunicazione non cifrata con il dispositivo vittima.
Illustrazione 3: induzione codice errore 0x06A questo punto smartphone vittima e smartphone hacker nr 2 potranno comunicare in chiaro in modalità non sicura. Il telefono vittima invierà una richiesta di lettura sull’attributo “OXYGEN” per esempio, questo attributo sul telefono hacker 2 sarà già stato preventivamente configurato dall’attaccante per ricevere un semplice permesso di lettura dall’esterno in modo da rispondere alla richiesta di lettura con un valore fittizio.
La parte più insidiosa dell’attacco è che le operazioni fin qui descritte avvengono silenziosamente e la vittima non ha assolutamente un modo di comprendere quello che sta accadendo, in effetti l’attacco non ripristina il valore della chiave LTK memorizzata nel telefono della vittima, che in un momento successivo gli permetterebbe di collegarsi correttamente in modalità sicura al saturimetro reale.
La simulazione termina con la variante Man in the Middle introducendo nuovamente lo smartphone hacker nr 1
Una volta che lo smartphone hacker nr 1 rimarrà attivo per saturare le risorse del dispositivo slave e il dispostivo hacker 2 attraverso la clonazione dei parametri MAC/name del saturimetro reale, sarà collegato abusivamente in chiaro allo smartphone vittima, l’attaccante attraverso i due smartphone avrà la possibilità da una parte di mantenere occupato il dispositivo slave e dall’altra creare valori creati ad hoc sulla funzione fittizia “OXYGEN” esposta alla quale il dispositivo vittima vorrà accedere.
Fernando Curzi
Copyright @ 2003 – 2024 RED HOT CYBER
PIVA 16821691009