Bluetooth bugs bite millions of Wi-Fi APs from Cisco, Meraki, and Aruba
Millions of Wi-Fi access points sold by Cisco, Meraki, and Aruba have two critical vulnerabilities being patched that could allow hackers to run malware inside the sensitive networks that use the gear. While the flaws open corporate networks to some scary attacks, the real-word likelihood of them being exploited is debatable.
In a report published Thursday, security firm Armis said two flaws it found in Bluetooth Low Energy chips manufactured by Texas Instruments can be used to hack the APs that embed them. The BLE chips offer a variety of enhancements to traditional Wi-Fi APs. Retailers, for instance, can use them to monitor customer movements inside stores by monitoring the Bluetooth beacons sent by the customers’ phones. Hospitals can use BLE to keep track of Bluetooth-enabled medical equipment. Cisco (which also makes Meraki gear) and Aruba have both issued patches that users of affected gear should install as soon as possible.
Unfortunately, hackers can also make use of the vulnerable BLE chips to take control of the APs. Attackers armed with small Bluetooth-enabled devices need only two minutes to transmit exploits that install malicious firmware on the vulnerable chips. From there, the malware could install AP firmware that monitors communications, infects end users, or spreads to other parts of a corporate network.
Complete access, no authentication required
“Both of the vulnerabilities allow an attacker completely unauthenticated to be able to take over first the BLE chip,” Armis CTO and cofounder Nadir Izrael told Ars, “but secondly, because of the BLE chip’s position within the software stack and firmware, it allows privileged access to the access point itself.” With the ability to control the AP, attackers can gain access to some of the most privileged parts of a company’s network.
The vulnerability affecting Cisco and Meraki gear is a combination heap overflow and an overflow over static variables, either of which can be used to corrupt chip memory and execute malicious code. The attacks require that BLE be turned on and device scanning changed to be enabled. (By default, scanning is turned off on all vulnerable devices, while BLE is turned off on some but not all of them.) With BLE on and scanning enabled, attacks transmitted by BLE devices within radio range are reliable because the embedded chips provide no exploit mitigations.
Armis Head of Research Ben Seri said a slightly customized attack code is needed for APs running different TI firmware versions. But he also said that it wouldn’t be hard to create a weaponized exploit that combined all the vulnerabilities and automatically used whichever one was needed to exploit a particular vulnerable device. The exploit works by sending benign BLE messages (called advertising packets) that get stored in the memory of the vulnerable chip. Embedded inside the packets is code that’s not detected by traditional security scanning products and gets invoked by the attacker later.
The attacker then triggers the overflow by sending a standard advertising packet with one subtle change—a specific bit in the header is turned on instead of off. The on bit causes the chip to allot data in a larger chunk of memory than is needed. The mismatch causes the chip to leak parts of memory that the attacker can use to execute code sent in the advertising packets in the earlier stage. The attacker now has the ability to backdoor the chip and, from there, attack the main processor of the AP.
“Part of the power of this vulnerability is that it occurs when a BLE chip (as the one embedded in access points) is listening for advertising packets,” Seri wrote in an email. “So any AP that is in that state will be vulnerable to this attack. The attacker doesn’t need to target a specific AP. He can simply send out these malicious broadcast packets, and any vulnerable AP within range would be compromised (simultaneously).” The vulnerability is indexed as CVE-2018-16986.
The second vulnerability is known so far only to affect APs from Aruba. CVE-2018-7080 is the result of an over-the-air firmware download feature that TI built into its chips so device makers can more easily update firmware while developing their products. While the chipmaker never intended the feature to be included in production devices used by end users, Armis said, Aruba makes a password-protected version of the update feature available in the Aruba series 300 APs. The password used across all the devices is identical.
“Any attacker who acquired the password by sniffing a legitimate update or by reverse-engineering the device can force any vulnerable access point in the vicinity to download a fraudulent update containing the attacker’s own code, effectively allowing a complete rewrite [of] its operating system, thereby gaining full control over it,” Thursday’s report said.
What’s vulnerable (and when)?
According to Armis, CVE-2018-16986 is present when scanning is used in the following chip/firmware combinations:
- CC2640 (non-R2) with BLE-STACK version 2.2.1 or an earlier version; or
- CC2650 with BLE-STACK version 2.2.1 or an earlier version; or
- CC2640R2F with SimpleLink CC2640R2 SDK version 1.00.00.22 (BLE-STACK 3.0.0); or
- CC1350 with SimpleLink CC13x0 SDK version 2.20.00.38 (BLE-STACK 2.3.3) or an earlier version.
The affected APs include:
- Cisco 1800i Aironet Access Points
- Cisco 1810 Aironet Access Points
- Cisco 1815i Aironet Access Points
- Cisco 1815m Aironet Access Points
- Cisco 1815w Aironet Access Points
- Cisco 4800 Aironet Access Points
- Cisco 1540 Aironet Series Outdoor Access Point
- Meraki MR30H AP
- Meraki MR33 AP
- Meraki MR42E AP
- Meraki MR53E AP
- Meraki MR74
CVE-2018-7080, Armis said, affects Aruba series 300 APs, although an Aruba advisory listed additional devices.
In an email, Cisco confirmed the vulnerabilities when affected devices have BLE turned on and scanning is enabled. Scanning is disabled by default for all affected products, and the BLE feature is disabled by default on the affected Aironet devices. Cisco has documentation about the vulnerabilities here, here, and here.
An Aruba representative said the company issued a patch for the vulnerability on October 18. The advisory says the following APs are affected:
- AP-3xx and IAP-3xx series access points
- AP-203R
- AP-203RP
- ArubaOS 6.4.4.x prior to 6.4.4.20
- ArubaOS 6.5.3.x prior to 6.5.3.9
- ArubaOS 6.5.4.x prior to 6.5.4.9
- ArubaOS 8.x prior to 8.2.2.2
- ArubaOS 8.3.x prior to 8.3.0.4
By default, the Aruba representative said, BLE in the AP-3xx, AP-207, and AP-203R(P) devices is turned off, and the company isn’t aware of any customers being exploited.
Texas Instruments issued a statement that challenged some of the statements in Thursday’s report. Among other things, TI said that it released a software update earlier this year that patched the CVE-2018-16986. (Armis, meanwhile, said TI only recognized the flaw as a stability issue at the time.) TI has fixes and documentation available here.
Bad yes, practical no (but patch anyway)
On one level, the vulnerabilities are shockingly bad. Given the control the bugs give to attackers and the ability for hackers to detect them using relatively standard techniques, it’s hard to understand why TI and Cisco didn’t identify the glaring insecurity caused by the overflow and why Aruba put a modified over-the-air download feature in APs it shipped to customers.
On another level, however, a tremendous amount of work is required to exploit these vulnerabilities in a way that gives attackers the control they ultimately want. Attackers first must invest time in finding the vulnerabilities and developing highly complex code that exploits them. They then must develop even more complex firmware that backdoors the chip without interfering with its normal functions. The amount of reverse engineering and code development involved is significant.
While the ultimate control over a corporate access point is an attractive reward, it’s not as high a return on investment as, say, getting control over a server that stores all of a company’s employee password data or customer databases. Dan Guido, a mobile security expert and the CEO of security firm Trail of Bits, summed up the situation this way:
The chance of code discovery here is pretty low. The resources to recreate this attack are really high. The window of opportunity to exploit it is really low, and the access that it gains you is not that useful, because instead of being root on some Windows box, you’re just going to get code execution on some weird chip where now you’ve got to write custom payloads and reverse engineer all kinds of custom protocols and find a way to manipulate this thing in a device-specific way. It’s just not practical for most attacks.
Then there’s the requirement that the attacker be within radio range of the target. There aren’t many well-known incidences of sophisticated in-the-wild exploits that require relatively close physical proximity to the target. One that comes to mind is the TJ Maxx security breach from the mid-2000s that compromised more than 100 million customer records. According to The Wall Street Journal, it was carried out, at least in part, by hackers who used a simple telescope-shaped antenna and a laptop to intercept data flowing through a Wi-Fi network used at a Marshalls discount clothing store near St. Paul, Minnesota. While the data was encrypted using the WEP protocol, the remote hackers needed only an hour or so to crack the key.
But a hack on a retailer’s poorly secured Wi-Fi network is significantly easier to carry out than the type of highly specialized attack described in Thursday’s report. (In fairness to Armis, though, once attackers made the initial, steep investment in reverse engineering and exploit development, they could send mules armed with BLE-enabled devices to targeted premises to seed the attack. Once the AP inside the network is infected, physical proximity would no longer be required.)
Asked for examples of proximity-based attacks used in the real world, Armis’ Seri pointed to the NSA toolkit catalog leaked by former contractor Edward Snowden. A tool called Nightstand allowed agency hackers to use Wi-Fi signals to compromise Windows computers.
Seri’s citing of a NSA tool as an example of the type of real-word threat posed by proximity-based attacks only seems to further the case that the BLE attacks described Thursday (Armis is calling them Bleedingbit) aren’t the kinds of attacks most enterprises would ever see. Seri, who has experience writing weaponized exploits, continues to disagree.
“This kind of attack, if you compare it to most other attacks, is relatively simple,” he told Ars. “You might think there are a lot of bits in here. This is complicated. An attacker knows that every attack is complicated in some way. But once you’re past the research phase [and] you have your exploit code, you just send it away, and you’re in.”
