{"id":37142,"date":"2020-09-15T21:27:43","date_gmt":"2020-09-15T21:27:43","guid":{"rendered":"http:\/\/4b9c9c8a-a096-458f-8a16-415d51f5102e"},"modified":"2020-09-15T21:27:43","modified_gmt":"2020-09-15T21:27:43","slug":"billions-of-devices-vulnerable-to-new-blesa-bluetooth-security-flaw","status":"publish","type":"post","link":"https:\/\/www.threatshub.org\/blog\/billions-of-devices-vulnerable-to-new-blesa-bluetooth-security-flaw\/","title":{"rendered":"Billions of devices vulnerable to new ‘BLESA’ Bluetooth security flaw"},"content":{"rendered":"
\"bluetooth\"<\/span>
<\/span> Image: ZDNet <\/span><\/figcaption><\/figure>\n

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.<\/p>\n

Named BLESA <\/strong>(B<\/strong>luetooth L<\/strong>ow E<\/strong>nergy S<\/strong>poofing A<\/strong>ttack), the vulnerability impacts devices running the Bluetooth Low Energy (BLE) protocol.<\/p>\n

BLE<\/a> 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.<\/p>\n

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.<\/p>\n

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<\/a>.<\/p>\n

Academics studied the Bluetooth “reconnection” process<\/h3>\n

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.<\/p>\n

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.<\/p>\n

<\/section>\n

Their work focused on the “reconnection<\/strong>” process. This operation takes place after two BLE devices (the client and server) have authenticated each other during the pairing operation.<\/p>\n

Reconnections<\/em> 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.<\/p>\n

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:<\/p>\n

    \n
  • The authentication<\/strong> during the device reconnection is optional instead of mandatory<\/strong>.<\/li>\n
  • The authentication can potentially be circumvented<\/strong> if the user’s device fails to enforce the IoT device to authenticate the communicated data.<\/li>\n<\/ul>\n

    These two issues leave the door open for a BLESA attack \u2014 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.<\/p>\n

    \n