Bluetooth and BLE Attacks

Bluetooth is everywhere: headsets, locks, medical devices, fitness trackers, car infotainment, and industrial sensors. Two distinct technologies share the brand:

• Bluetooth Classic (BR/EDR) — higher throughput, used for audio and file transfer.
• Bluetooth Low Energy (BLE) — low power, used by IoT, wearables, and smart locks.

They differ in radio behavior, pairing, and protocol stacks, so attacks against one rarely apply to the other. BLE dominates IoT and is the focus of most modern assessments because of how often it is deployed insecurely.

BLE operates in the 2.4 GHz band across 40 channels. Three of them (37, 38, 39) are advertising channels used for discovery; the other 37 carry connected data.

The core data model is GATT (Generic Attribute Profile):

• Services group related functionality.
• Characteristics are individual data points you can read, write, or subscribe to.
• Each has a UUID and a handle.

Enumerating the GATT table reveals exactly what a device exposes, which is the heart of BLE assessment.

Reconnaissance starts with scanning advertising packets to learn what is in range, then connecting to enumerate the GATT database.

On Linux, the BlueZ stack and tools like bluetoothctl, hcitool, and gatttool let you scan and interrogate devices. nRF Connect on a phone is an excellent graphical alternative.

To observe communication between a device and its app, you sniff the air. Because BLE hops across channels, a sniffer must follow the connection.

• nRF52840 dongle with the nRF Sniffer plugin for Wireshark is the standard low-cost capture tool.
• Ubertooth One can capture both BLE and some Classic traffic.
• Capture during the connection event to catch the initial handshake.

Wireshark dissects captured packets into advertising data, connection requests, and GATT operations, letting you map exactly what the app reads and writes.

BLE security depends on the pairing method chosen during bonding:

• Just Works — no user verification; vulnerable to man-in-the-middle by design. Extremely common in cheap IoT.
• Passkey Entry — a 6-digit code, stronger but brute-forceable if poorly implemented.
• Numeric Comparison — both devices show a number to confirm (LE Secure Connections).

Legacy pairing (pre-4.2) is cryptographically weak and its keys can be recovered from a captured handshake. LE Secure Connections uses ECDH and is the only method considered robust.

When a device uses BLE legacy pairing, a captured pairing exchange can be brute-forced to recover the Temporary Key and ultimately the Long Term Key.

The tool crackle automates this against a pcap of the pairing event. Once the keys are recovered, previously encrypted traffic in the capture can be decrypted.

Many BLE devices trust whoever can connect. Once you enumerate writable characteristics, you can often issue commands directly without authentication.

• Unauthenticated writes — sending crafted values to a control characteristic can unlock smart locks or toggle relays.
• Device spoofing — cloning a peripheral MAC and advertisement to impersonate it to a victim app.
• GATTacker / Mirage — frameworks that man-in-the-middle a peripheral by proxying GATT traffic.

The classic finding is a smart lock whose unlock command is a static plaintext write that anyone can replay.

A BLE MITM proxy clones the target peripheral, lets the victim app connect to the clone, and relays traffic to the real device. This exposes the full conversation and allows live modification.

Frameworks like Mirage and GATTacker automate cloning advertisements and bridging two radios. You capture, modify, or replay any GATT operation in transit.

Bluetooth Classic has its own history of issues. Notable examples include BlueBorne (a set of stack-level remote code execution flaws) and KNOB (Key Negotiation of Bluetooth), which forces the encryption key down to a brute-forceable length.

• Many headsets and car kits still accept weak or default PINs.
• Service discovery via SDP can leak device capabilities and firmware hints.
• Old stacks may be unpatched against known CVEs.

For Classic, your assessment focuses on stack version, pairing strength, and known vulnerable firmware.

BLE devices that advertise constantly create privacy and tracking risks. A static MAC address lets an observer follow a person across locations.

• MAC randomization rotates the address periodically to defeat tracking, but many devices implement it poorly or not at all.
• Identifiable advertisement payloads (fixed names, manufacturer data) can re-identify a device even with a randomized MAC.
• Long-range directional antennas extend the practical sniffing distance far beyond the nominal 10 meters.

Assessing tracking exposure is a legitimate and important part of BLE privacy review.

Defensive recommendations from a BLE assessment typically include:

• Use LE Secure Connections with numeric comparison; never ship Just Works for sensitive functions.
• Apply application-layer encryption and authentication on top of the link, so a MITM cannot replay or forge commands.
• Implement per-session nonces or rolling codes for control commands like unlock.
• Enable proper MAC randomization and strip identifying advertisement data.
• Keep the Bluetooth stack patched against BlueBorne, KNOB, and similar issues.

The recurring lesson: link-layer security is not enough when the application trusts any connected client.

Test your understanding of BLE pairing security.

You can now assess Bluetooth and BLE devices end to end:

• BLE uses 40 channels and exposes data through the GATT model of services and characteristics.
• Recon means scanning advertisements and enumerating the GATT database with BlueZ tools or nRF Connect.
• Sniffing with nRF52840 or Ubertooth feeds Wireshark for protocol analysis.
• Just Works and legacy pairing are weak; crackle recovers keys from captured legacy handshakes.
• Active attacks exploit unauthenticated writes and MITM proxies like Mirage and GATTacker.
• Defense requires LE Secure Connections plus application-layer authentication and rolling commands.

Next you will move from connected protocols to contactless tags with RFID and NFC.