Image: ZDNet
Billions of smartphones, tablets, laptops, and IoT devices are using Bluetooth software stacks that are vulnerable to a new security flaw disclosed over the summer.
Named BLESA (Bluetooth Low Energy Spoofing Attack), the vulnerability impacts devices running the Bluetooth Low Energy (BLE) protocol.
BLE is a slimmer version of the original Bluetooth (Classic) standard but designed to conserve battery power while keeping Bluetooth connections alive as long as possible.
Due to its battery-saving features, BLE has been massively adopted over the past decade, becoming a near-ubiquitous technology across almost all battery-powered devices.
As a result of this broad adoption, security researchers and academics have also repeatedly probed BLE for security flaws across the years, often finding major issues.
Academics studied the Bluetooth “reconnection” process
However, the vast majority of all previous research on BLE security issues has almost exclusively focused on the pairing process and ignored large chunks of the BLE protocol.
In a research project at Purdue University, a team of seven academics set out to investigate a section of the BLE protocol that plays a crucial role in day-to-day BLE operations but has rarely been analyzed for security issues.
Their work focused on the “reconnection” process. This operation takes place after two BLE devices (the client and server) have authenticated each other during the pairing operation.
Reconnections take place when Bluetooth devices move out of range and then move back into range again later. Normally, when reconnecting, the two BLE devices should check each other’s cryptographic keys negotiated during the pairing process, and reconnect and continue exchanging data via BLE.
But the Purdue research team said it found that the official BLE specification didn’t contain strong-enough language to describe the reconnection process. As a result, two systemic issues have made their way into BLE software implementations, down the software supply-chain:
- The authentication during the device reconnection is optional instead of mandatory.
- The authentication can potentially be circumvented if the user’s device fails to enforce the IoT device to authenticate the communicated data.
These two issues leave the door open for a BLESA attack — during which a nearby attacker bypasses reconnection verifications and sends spoofed data to a BLE device with incorrect information, and induce human operators and automated processes into making erroneous decisions. See a trivial demo of a BLESA attack below.
Several BLE software stacks impacted
However, despite the vague language, the issue has not made it into all BLE real-world implementations.
Purdue researchers said they analyzed multiple software stacks that have been used to support BLE communications on various operating systems.
Researchers found that BlueZ (Linux-based IoT devices), Fluoride (Android), and the iOS BLE stack were all vulnerable to BLESA attacks, while the BLE stack in Windows devices was immune.
“As of June 2020, while Apple has assigned the CVE-2020-9770 to the vulnerability and fixed it, the Android BLE implementation in our tested device (i.e., Google Pixel XL running Android 10) is still vulnerable,” researchers said in a paper published last month.
As for Linux-based IoT devices, the BlueZ development team said it would deprecate the part of its code that opens devices to BLESA attacks, and, instead, use code that implements proper BLE reconnection procedures, immune to BLESA.
Another patching hell
Sadly, just like with all the previous Bluetooth bugs, patching all vulnerable devices will be a nightmare for system admins, and patching some devices might not be an option.
Some resource-constrained IoT equipment that has been sold over the past decade and already deployed in the field today doesn’t come with a built-in update mechanism, meaning these devices will remain permanently unpatched.
Defending against most Bluetooth attacks usually means pairing devices in controlled environments, but defending against BLESA is a much harder task, since the attack targets the more often-occurring reconnect operation.
Attackers can use denial-of-service bugs to make Bluetooth connections go offline and trigger a reconnection operation on demand, and then execute a BLESA attack. Safeguarding BLE devices against disconnects and signal drops is impossible.
Making matters worse, based on previous BLE usage statistics, the research team believes that the number of devices using the vulnerable BLE software stacks is in the billions.
All of these devices are now at the mercy of their software suppliers, currently awaiting for a patch.
Additional details about the BLESA attack are available in a paper titled “BLESA: Spoofing Attacks against Reconnections in Bluetooth Low Energy” [PDF, PDF]. The paper was presented at the USENIX WOOT 2020 conference in August. A recording of the Purdue team’s presentation is embedded below.
