Bluetooth and BLE

Bluetooth Low Energy (BLE) is everywhere: wearables, smart locks, medical devices, car keys, toys, IoT sensors. Many were designed prioritizing ease and low power over security, so it’s common to find unencrypted communication, weak or absent authentication, and exposed sensitive data. Auditing BLE means discovering devices, mapping their services and characteristics, and reading/writing/intercepting what shouldn’t be accessible.

BLE concepts

GATT        data structure: Services -> Characteristics -> Values
Characteristic  a readable/writable/notifiable datum (e.g. "lock state")
MAC          device address (sometimes randomized)
Advertising  frames the device broadcasts to announce itself
Pairing/Bonding   pairing (with or without encryption/authentication)
# security modes: Just Works (no auth, common and weak), Passkey, OOB, LE Secure Connections

Hardware

# BLE adapter (the laptop's built-in one usually works to start)
# for more range/capability: CSR/Nordic dongles, Ubertooth One (advanced sniffing)
# a phone with apps (nRF Connect) for quick exploration

Discover and explore (recon)

# scan nearby devices
hcitool lescan ; bluetoothctl -> scan on
# explore services and characteristics (GATT)
gatttool -I -b <MAC>                    # interactive mode
# or modern tools
bettercap -> ble.recon on ; ble.enum <MAC>
# apps: nRF Connect (Android/iOS) -> view and write characteristics conveniently

Map which services/characteristics the device exposes and which allow read/write/notify.

Attack vectors

# read/write characteristics without authentication
gatttool -b <MAC> --char-write-req -a <handle> -n <value>
# -> open a lock, change a setting, send an unauthorized command
# replay: capture a legitimate command (sniffing) and resend it
# lack of encryption -> BLE traffic sniffing reveals commands/data
# Just Works pairing -> MITM the pairing
# characteristic fuzzing -> trigger crashes/unexpected behavior
# devices exposing everything with no authentication (very common in cheap IoT)

The recurring pattern: a characteristic that performs a sensitive action (open, turn on, change config) without checking authentication → anyone in range invokes it.

Sniffing and interception

# capture BLE traffic (requires hardware that supports sniffing)
Ubertooth One + ubertooth-btle ; nRF Sniffer (Wireshark)
# analyze the pairing and cleartext commands
# BLE MITM: GATTacker, BtleJuice (proxy between app and device)

For the defense

LE Secure Connections with authenticated pairing (Passkey/OOB), not “Just Works” for sensitive actions.
Encrypt the communication and authenticate commands at the application level (don’t rely on pairing alone).
Don’t expose sensitive characteristics without authentication; validate who writes.
Anti-replay protection (nonces, counters); key rotation.
MAC randomization for privacy; minimal advertising surface.

Testing checklist

BLE hardware and tools (bluetoothctl/gatttool/nRF Connect)
Discover devices and map GATT (services/characteristics)
Read characteristics without authentication
Write sensitive characteristics (open/command) without auth
Traffic sniffing (unencrypted?) and command replay
Pairing mode (Just Works vs authenticated)
MITM the pairing (GATTacker/BtleJuice)
Blue: LE Secure Connections, app-level auth, anti-replay?