Millions of access points and other networking devices used by enterprises around the world may be exposed to remote attacks due to a couple of vulnerabilities discovered by researchers in Bluetooth Low Energy (BLE) chips made by Texas Instruments.
Bluetooth Low Energy, or Bluetooth 4.0, is designed for applications that do not require exchanging large amounts of data, such as smart home, health and sports devices. BLE stays in sleep mode and is only activated when a connection is initiated, which results in low power consumption. Similar to the classic Bluetooth, BLE works over distances of up to 100 meters (330 feet), but its data transfer rate is typically 1 Mbit/s, compared to 1-3 Mbit/sec in the case of classic Bluetooth.
Researchers at IoT security company Armis, who in the past discovered the Bluetooth vulnerabilities known as BlueBorne, now claim to have found two serious vulnerabilities in BLE chips made by Texas Instruments. These chips are used in access points and other enterprise networking devices made by Cisco, including Meraki products, and HP-owned Aruba Networks.
According to Armis, these vendors provide 70% of the wireless access points sold to enterprises every year, but it’s unclear exactly how many devices are vulnerable.
The flaws, dubbed BLEEDINGBIT by Armis, can allow a remote and unauthenticated attacker to take complete control of impacted devices and gain access to the enterprise networks housing them.
Devices used in the healthcare sector, such as insulin pumps and pacemakers, also use the affected BLE chips so they could be vulnerable to BLEEDINGBIT attacks as well.
The IoT security firm is in the processes of assessing the full impact of the BLEEDINGBIT vulnerabilities, but so far it determined that they affect several Texas Instruments chips. One of the flaws, tracked as CVE-2018-16986, has been found in CC2640 and CC2650 chips running BLE-STACK 2.2.1 and earlier, and CC2640R2 running version 1.0 or earlier.
The bug is present in several Cisco Aironet and Meraki MR access points. However, exploitation is only possible if the device is actively scanning.
The second flaw, CVE-2018-7080, is present in CC2642R2, CC2640R2, CC2640, CC2650, CC2540 and CC2541 chips. However, the security hole can only be exploited if the device using the chip has the over-the-air firmware download (OAD) feature enabled. So far, only some APs from Aruba have been found to use this feature.
The first vulnerability can be exploited for remote code execution by an attacker who is in range of the targeted device. If BLE is turned on and the device is actively scanning, a malicious actor can send specially crafted packets in order to trigger a memory overflow and execute arbitrary code.
The attacker can install a backdoor on the chip and then gain complete control of the system. In the case of access points, the attacker can use the compromised AP to spread to other devices on the network, even if segmentation is in place.
The second bug, which to date has only been found to affect Aruba devices, allows an attacker to deliver a malicious update to the targeted AP and rewrite its operating system. The attacker can then gain complete control of the device.
This attack is made easier by the fact that all Aruba access points share the same OAD password, which can be obtained by intercepting a legitimate update or reverse engineering the device. However, Aruba pointed out that the exploit only works if BLE radio has been enabled – the feature is disabled by default.
Attacks can be conducted from up to 100 meters, but Armis told SecurityWeek that the distance can be doubled or even tripled if the attacker uses a directional antenna. Once the AP has been compromised, the attacker can create an outbound connection over the Internet and they no longer need to stay in range. Armis says the attacks can be carried out in 1-2 minutes.
Armis notified all affected vendors about the vulnerabilities this summer. Texas Instruments addressed CVE-2018-16986 with the release of BLE-STACK version 2.2.2. However, in the case of the OAD-related flaw, the chipmaker pointed out that the feature should not be used in production environments. Cisco and Aruba have also released patches for affected products.