Snippet 22: Bleeding Bit Attack

Bleeding Bit exploited the Texas Instruments Bluetooth Low Energy system-on-chip used inside Cisco Meraki and Aruba access points, turning a Bluetooth bug into remote code execution on enterprise network infrastructure.

Key Takeaways

• Two vulnerabilities in the TI BLE system-on-chip exposed Cisco Meraki and Aruba access points to remote takeover
• A spec change between Bluetooth 4.2 and 5 in advertising packet length handling created the buffer-overflow path to remote code execution
• Aruba devices shipped with remote BLE firmware updates enabled, and the signing key was recoverable from the companion app
• Patching the chip does not automatically patch the shipped products built on it

Video Transcript

Bleeding Bit. Same group of researchers. And this is a Bluetooth Low Energy vulnerability. Two different vulnerabilities that are actually pretty distinct, but they get grouped under the same heading here. And they both exploit the Texas Instruments Bluetooth Low Energy system on a chip. So they found a vulnerability in the TI SoC. And then they noted that SoC is in Cisco Meraki and Aruba access points. And they showed how they could get remote code execution and take over those specific access points.

So they note in their paper that they think part of the problem is that from 4.2 to 5, Bluetooth changed the advertising channel PDU header. So this is a packet that's used a lot. And notably they changed how the length field works and how these optional RFU fields are populated and where they're positioned. So they think that there is basically a disconnect and the new length wasn't handled properly, which lets them misspecify the length and then get the buffer overflow remote code execution.

So once they proved it out in the Ti SoC, they were able to dump the ROM on a Cisco access point or series of Cisco access points and further work through the kill chain in order to get remote code execution on Cisco. Aruba, they did a different style of attack. They noted that the same SoC was there and that Aruba had accidentally left on remote Bluetooth Low Energy firmware updates. And they were able to decompile the Aruba app that did those updates and dump the ROM on the device.

And through that, they found the key that allowed them to just send packets to put their own firmware on the device. And once they can do that, then they own the device. So they noted these SoCs from TI were vulnerable and these Cisco Meraki and Aruba access points were vulnerable.