If it bleeds, it leads

UPDATED A brace of vulnerabilities in Bluetooth chips, collectively christened BleedingBit, allegedly create a means to hack into access points and other networking kit.

The supposed security shortcoming of Bluetooth Low Energy (BLE) chips from Texas Instruments were publicized by security firm Armis ahead of an upcoming talk.

Texas Instruments, however, dismissed Armis’ warning as “factually unsubstantiated and potentially misleading”. It said the flaws had already been remediated.

The Daily Swig put these criticisms to Armis on Friday, but we’ve yet to receive a substantive response. We’ll update this story as and when more information comes to hand.

The chips in question are used in networking kit from an array of vendors, including enterprise-grade WiFi access points from suppliers including Cisco, Meraki, and Aruba.

Hackers need to be physically close to a targeted network that has BLE enabled in order to mount an attack, but given this precondition the flaws create a mechanism for unauthenticated hackers to push malicious code onto vulnerable devices, according to Armis.

Details of the remote code execution-class vulnerabilities are being withheld pending a presentation due to take place at Black Hat Europe in London next month.

“Once an attacker takes control over an access point, he can move laterally between network segments, and create a bridge between them – effectively breaking network segmentation,” Armis warned through a dedicated micro-site it set up last week to trail its upcoming BleedingBit research.

It warns that the one of the flaws creates a means for hackers to move laterally from an initially compromised device across targeted networks.

Armis notified Texas Instruments (TI) as well a networking kit vendors about the vulnerabilities.

The first BleedingBit remote code execution (RCE) vulnerability (CVE-2018-16986) is a two stage attack, according to Armis.

First, the attacker sends multiple benign BLE broadcast messages, called “advertising packets”, which will be stored on the memory of the vulnerable BLE chip in targeted device. While the packets are not harmful, they contain code that will be invoked by the attacker later on.

This activity will be undetected by traditional security solutions.Next, the attacker sends the overflow packet, which is a standard advertising packet with a subtle alteration – a specific bit in its header turned ON instead of off. This bit causes the chip to allocate the information from the packet a much larger space than it really needs, triggering an overflow of critical memory in the process.

The leaked memory contains function pointers – memory that points to specific code segments, which the attacker can leverage to point to the code s/he sent to the vulnerable chip in the previous stage of the attack. At this point, the attacker can run malicious code on the targeted device, and install a backdoor on the vulnerable chip, which will await further commands transmitted over BLE.

The attacker can also change the behavior of the BLE chip and attack the main processor of the device, gaining full control over it. In the case of an access point, once the attacker gained control he can reach all networks served by it, regardless of any network segmentation. Furthermore, the attacker can use the device in his control to spread laterally to any other device in its vicinity, launching a truly airborne attack.

In an update to customers, TI dismissed the security issue as already resolved. “Potential security vulnerability identified by Armis was addressed with previous software updates,” it said.

TI is aware that Armis has reported potential security vulnerabilities with certain older versions of the BLE-STACK. Armis has also incorrectly indicated a chip-level issue with the over-the-air download (OAD) profile feature.

The second BleedingBit vulnerability (CVE-2018-7080) is limited to the Aruba Access Point Series 300, and its implementation of firmware update technology from Texas Instruments.

TI faulted Armis on this issue for “failing to clarify that the over-the-air firmware download (OAD) profile feature mentioned in Armis’ report is not intended or marketed to be a comprehensive security solution”.

“Prior to being contacted by Armis, TI identified a potential stability issue with certain older versions of the BLE-STACK when used in a scanning mode, and we addressed this issue earlier this year with software updates,” the chipmaker said.

“We’ve informed Armis that the potential security vulnerability that they are exploiting was addressed with previous software updates. If our customers have not already updated their software with the latest versions available, we encourage them to do so.”

In a statement to The Daily Swig on November 5, Armis defended its approach and argued what TI had initially identified as a stability issue turned out to have security ramifications:

Coordinated vulnerability disclosures of this complexity require careful orchestration. Once we identified the issues, we reached out to TI and connected with their appropriate security contacts. We clearly communicated in our public report that TI had already identified the BLE-STACK issue and provided a fix. But as TI itself states, they identified it as a stability issue – not a security issue.

Their original release notes did not include any specific security notice (and still does not). Once TI reviewed our findings, they acknowledged that the issue can lead to an RCE vulnerability. Together we embarked on a coordinated disclosure of the security issue as TI then filed the CVE, and Cisco and Meraki applied the updates.

Armis agrees that the over-the-air download (OAD) feature was not marketed as, and did not include, a comprehensive security solution and never said otherwise. We identified an issue with Aruba’s implementation, and notified TI and Aruba. We agree that manufacturers need to securely implement the feature when used outside a development environment, and raised this issue with TI.

TI agreed to update its warnings on the OAD usage (which took place in mid-October). Together, we embarked on a coordinated disclosure to inform all manufacturers about the proper use of and risks related to OAD, to avoid a potential RCE vulnerability; while giving Aruba time to make the appropriate changes.

This article has been updated to include additional comments from Armis.