New BLEEDINGBIT Vulnerabilities Affect Widely-Used Bluetooth Chips

Two vulnerabilities in the Bluetooth chips typically found in access points that provide WiFi service in enterprises allow attackers to take control of the devices without authentication or to breach the network.

The vulnerable chips are also present in medical devices (insulin pumps, pacemakers), smart locks and a variety of other types of products that rely on Bluetooth Low Energy (BLE) technology for communication. A tally of affected gadgets is currently unavailable.

Researchers at Armis security company for IoT devices discovered the flaws in the BLE chips from Texas Instruments (TI) and gave them the collective name BLEEDINGBIT.

Specific products known to embed the faulty TI BLE chips are WiFi network equipment from Cisco, Meraki (acquired by Cisco Systems in December 2012), and Aruba Networks (subsidiary of Hewlett-Packard). Together, the three brands sell at least 70% of the access points that end up in enterprises every year.

BLEEDINGBIT remote code execution CVE-2018-16986

Tracked as CVE-2018-16986, one of the issues can be leveraged to trigger a memory corruption in the BLE stack, offering an unauthenticated attacker the opportunity to take full control of the system.

"The vulnerability can be exploited by an attacker in the vicinity of the affected device, provided its BLE is turned on, without any other prerequisites or knowledge about the device," Armis says in a report shared with BleepingComputer.

The attacker can exploit the bug by sending the access point (AP) specially crafted advertising packets containing code that would be triggered in a future step.

In a second stage, the AP receives an overflow packet in the form of an altered advertising packet that has a specific bit turned on. The memory leak triggered this way reveals function pointers the attacker can use to execute the code delivered in the first 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," Armis warns.

CVE-2018-16986 is present in the following Texas Instruments chips:

CC2640 (non-R2) with BLE-STACK version 2.2.1 or earlier

CC2650 with BLE-STACK version 2.2.1 or earlier

CC2640R2 with BLE-STACK version 1.0 or earlier

According to Armis, the bug can be exploited in the following Cisco and Meraki access points: 1542 AP, 1815 AP, 4800 AP, MR33, MR30H, MR74, and MR53E.

BLEEDINGBIT remote code execution CVE-2018-7080

The second BLEEDINGBIT bug is a backdoor that helps during the development stage to push over-the-air downloads (OAD) of the firmware. The function is intended for updating the devices remotely by connecting to them with a preset password.

Texas Instruments says that vendors should not use the OAD feature in the production of devices. In the case of Aruba 300 Series WiFi devices, Armis found that they had the same password.

An attacker can learn the password by sniffing the network when a legitimate update comes or by reverse engineering the product. With the OAD access code, the threat actor can create a fraudulent firmware update and serve it to nearby devices.

Texas Instruments prepared a fix

On June 20, Armis contacted Texas Instruments about CVE-2018-16986. The chip maker knew about the vulnerability, but viewed it as a stability issue, failing to see the security implications.

Once the security consequences became evident, Texas Instruments worked with Armis to release a patch, which is available in version 2.2.2. of BLE-STACK.

As for CVE-2018-7080, the maker recommends disabling the OAD feature in production environments, as it is intended for development and testing purposes only.

UPDATE [Nov 1]: Following the publication of this article, Cisco reached out to BleepingComputer to highlight that BLEEDINGBIT is exploitable on a limited number of its Aironet and Meraki products (listed in the table below) under conditions that are not present by default.

Successful exploitation requires both the BLE feature and scanning mode to be enabled. Aironet products do not have BLE turned on by default and scanning mode is disabled on all potentially affected devices from Cisco, a company spokesperson told BleepingComputer via email. Furthermore, the attacker needs to be nearby the target.

The company today released an advisory to clarify that the troublesome BLE feature allowing exploitation was introduced in firmware version 8.7 of the affected Aironet access points. The fix is available in version 8.8.100; for Meraki devices, the issue is fixed in version MR 25.13 and later.

Administrators can determine if BLE is enabled by running the command show controllers bleRadio 0 interface; the command is recognized only by vulnerable devices, otherwise, the error message BLE not supported on this platform is shown.

Guidance on how to disable the BLE feature on Meraki devices is available here.

Ionut Ilascu is freelancing as a technology writer with a focus on all things cybersecurity. The topics he writes about include malware, vulnerabilities, exploits and security defenses, as well as research and innovation in information security. His work has been published by Bitdefender, Netgear, The Security Ledger and Softpedia.