Finding New Bluetooth Low Energy Exploits via Reverse Engineering Multiple Vendors' Firmwares

The presentation discusses a vulnerability in Bluetooth devices that can lead to remote code execution and the challenges in identifying and mitigating such vulnerabilities.

• Bluetooth devices lack common exploit mitigations, making them easier to exploit
• Cheap vendors often do not support secure reset, allowing attackers to persist on the device
• Identifying and assessing the impact of security findings is difficult due to the complex supply chain and lack of transparency
• The presentation provides an anecdote of identifying and exploiting a stack overflow vulnerability in Bluetooth devices
• The vulnerability can be exploited through a malicious advertisement packet without authentication or pairing
• The presentation also discusses the challenges in identifying and mitigating vulnerabilities, including the lack of common exploit mitigations and the difficulty in identifying end products and classes of devices

The speaker identified a stack overflow vulnerability in Bluetooth devices that can be exploited through a malicious advertisement packet without authentication or pairing. The vulnerability was caused by a programmer's mistake in maintaining a chain buffer, which could lead to overriding memory chunks and metadata pointers, ultimately allowing for remote code execution. The speaker patched the binary to identify the source address and length value for the mem copy and set a flag to see more information at the time of the crash. The vulnerability was similar to Bleeding Bit but in a different code path, and the speaker highlights the challenges in identifying and mitigating such vulnerabilities due to the complex supply chain and lack of transparency.

Bluetooth Low Energy (BLE) has seen widespread product adoption and a renewed interest from a security community whose interest in Classic Bluetooth (BT) had waned. Protocols that run "above" the Host Controller Interface (HCI) on the BLE stack are typically handled in full OSes or applications. Vulnerabilities at these layers are plentiful (~70 in Android in 2019) and comparatively well-understood. But for performance and abstraction reasons, protocols below the HCI layer are always handled in firmware running on microprocessors designed for BLE support. Until now, there had been only a single publicly disclosed remote code execution vulnerability in BLE below the HCI layer: CVE-2018-16986, Armis' BleedingBit. This talk describes my process of going from knowing nothing about Bluetooth, to reverse engineering multiple vendors' firmwares, and finding remote code execution exploits for multiple new vulnerabilities at the lowest levels of the BLE protocol stack which I will demonstrate. Exploits at this layer are of particular interest because they require neither pairing nor authentication, merely proximity, to exploit.