Slashdot Mirror
Bleedingbit Zero-Day Chip Flaws May Expose Majority of Enterprises To Remote Code Execution Attacks (zdnet.com)
Two new zero-day vulnerabilities called "Bleeding Bit" have been revealed by security firm Armis, impacting Bluetooth Low-Energy (BLE) chips used in millions of Cisco, Meraki, and Aruba wireless access points (APs). "Developed by Texas Instruments (TI), the vulnerable BLE chips are used by roughly 70 to 80 percent of business wireless access points today by way of Cisco, Meraki and Aruba products," reports ZDNet. From the report: The first vulnerability, CVE-2018-16986, impacts Cisco and Meraki APs using TI BLE chips. Attacks can remotely send multiple benign BLE broadcast messages, called "advertising packets," which are stored on the memory of the vulnerable chip. As long as a target device's BLE is turned on, these packets -- which contain hidden malicious code to be invoked later on -- can be used together with an overflow packet to trigger an overflow of critical memory. If exploited, attackers are able to trigger memory corruption in the chip's BLE stack, creating a scenario in which the threat actor is able to access an operating system and hijack devices, create a backdoor, and remotely execute malicious code.
The second vulnerability, CVE-2018-7080, is present in the over-the-air firmware download (OAD) feature of TI chips used in Aruba Wi-Fi access point Series 300 systems. The vulnerability is technically a leftover development backdoor tool. This oversight, the failure to remove such a powerful development tool, could permit attackers to compromise the system by gaining a foothold into a vulnerable access point. "It allows an attacker to access and install a completely new and different version of the firmware -- effectively rewriting the operating system of the device," the company says. "The OAD feature doesn't offer a security mechanism that differentiates a "good" or trusted firmware update from a potentially malicious update."
The second vulnerability, CVE-2018-7080, is present in the over-the-air firmware download (OAD) feature of TI chips used in Aruba Wi-Fi access point Series 300 systems. The vulnerability is technically a leftover development backdoor tool. This oversight, the failure to remove such a powerful development tool, could permit attackers to compromise the system by gaining a foothold into a vulnerable access point. "It allows an attacker to access and install a completely new and different version of the firmware -- effectively rewriting the operating system of the device," the company says. "The OAD feature doesn't offer a security mechanism that differentiates a "good" or trusted firmware update from a potentially malicious update."
Obviously it's there to increase the attack area. Duh.
Sigh... I was rather foolishly attempting to communicate an interesting parable to the feeble... epic fail.
Happiness in intelligent people is the rarest thing I know.
Ernest Hemingway
It's a checkbox in the bullshit-feature game.
You know those checkboxes. From your local electronics big box mart. With every appliance, there's this sticker that has a lot of checkboxes next to the name of features. And some are checked and some are not, depending on whether the appliance has the feature or not. Which ones sell? The ones with features of course. If appliance A costs about as much as appliance B, how will the average person tell the difference? By counting ticked checkboxes, of course. Do they need those features? Hell no. In 9 out of 10 cases they don't even know what those features mean. But A has it and B doesn't, so A is better!
Why do you think the average procurement manager works differently?
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Not allowing the owners of the chips to load custom firmware onto the chips is an atrocious practice. That would be the equivalent of maintaining hidden root access on a system that doesn't belong to you and relegating the legitimate owner to a shadow fake root. If you're going to require signed firmware images on a piece of kit then you need to include the private key to sign new firmware to anyone with with your chip in their equipment.
How many big box mart stores sell these enterprise Cisco, Aruba and Meraki access points?
microcode is the code a cpu runs internally to implement its own instruction set.
I highly doubt the cpu in these ble chips use microcode at all.
Except one of these vulnerabilities is exactly what you're complaining about.
The ability to allow any code to be uploaded was accidentally left enabled, allowing anyone within radio range to load any code they wish.
Reflashing should require setting a physical jumper.
I don't think that word means what you think it means.
In fact, the TI chips, like many other BLE chips is an ARM cortex SOC (cannot run Linux) running a light weight RTOS with a Bluetooth protocol stack and a suitable radio.
In other words, they run ARM machine language.
Enterprise vendors and the pointy hairs that sign the POs follow exactly the same pattern.
In other words, you mean none of the products identified as having this issue.
These aren't consumer marketed products. Just because Cisco has a consumer brand with a different set of products, doesn't mean their enterprise offerings are identical.
The difference between physical access and nearby is huge. The former offers a much greater risk of being caught red-handed. The latter is nearly impossible to prove.
Meanwhile, a good antenna can increase the range a fair amount.
So to upgrade the firmware in these enterprise outdoor access points, they should send a guy on site up a pole, take the thing down, open it up, insert the jumper, upgrade the firmware, reassemble it and then reinstall it outside? For each of the hundred devices they have?
Even the indoor AP's in my building would be a costly nightmare. There's 10 floors with at least 6 AP's on the roof of each floor.
It's up to you, you can balance the risk/reward as you see fit.
For example, you might prefer to change the bootloader so it will flash an image you signed without the jumper, but require the jumper to change the signing key.
Or, since the firmware I'm referring to is for the BLE module, (not the entire AP), you could just leave it as is with the jumper off..
Again, this is the procurement version of it. You have a procurement manager who knows jack shit about routers. But you, in IT, can't simply go and purchase a sensible access point when you need one. You have to go through procurement. And procurement will buy the "most economic" solution. Which usually means the cheapest shit that fits the bill. And if you find different cheap shit, the one with the most filled tick boxes get bought.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
It's for new wayfinding and location-based features. And they leveraged it for console use, though you rarely ever need console on these things.
Note the second CVE is not a "0-day". Aruba notified customers quite some time ago with workarounds (and a patch relaease, though only for their most-deployed chain.)
And they knew before then (they said they had to notify earlier than they wanted due to someone leaking.)
Someone had to do it.
I'd love to get that horse back in the barn, but considering the tech docs for these chipsets are not released to customers, we'd have to round up the pony as well. You can hope the chips behave like some similar design but you never know if there's one register in there wired up differently on a device made custom fr a manufacturer.
Also in this specific case they can hide behind the fact that the chipsets participate in RF and thus amateur firmware could cause illegal interference, so there's a mule out in the field as well (same problem with phone chipsets.)
(Proper way to go about this is have the TPM allow a customer key, not publish your corporate private key. Preferably you can have more than one key, and disable the vendor key if needed. Main problem is making it easy for low-level IT guys to check what the status of the keys are... very low-level IT guys. So preventing the TPM from using keys it was not booted with and providing a service/mechanism that validates the running key.)
Someone had to do it.
linksys is not owned by cisco. belkin bought it from cisco way back in march of 2013. but get with the program. it's not over yet, either, try to keep up... because now, foxconn is in process of buying belkin.
but either way, belkin or foxconn, don't expect anything to improve on the security and update front. they're both worse than cisco was for security support of that product line, and far worse than linksys was on its own before that.
Someone in marketing said that they need to put Bluetooth on the devices before the competition does. Now they have the most wireless in their wireless access points and have closed the Bluetooth "gap" with the competition.
Doesn't seem to make sense to me.
On a laptop, phone or tablet, you probably want bluetooth and wifi.
But "enterprise" wifi access points are normally wired in with a controller, and I don't see what the bluetooth would be used for.
What am I missing?
IOT devices with low power BT are used for tracking. Some McDonalds in the Netherlands uses these to serve your order.
The best weapon of a dictatorship is secrecy, but the best weapon of a democracy should be the weapon of openness.
Would it not be preferable to just have the motherboard require a switch accessible by users when the case is fully assembled set to allow firmware updates?
I had to look at TFA to find out that:
1) It has an auto-play video. Another to add to your blocker's blacklist
2) BLE chips are used for IoT connectivity. I assume the Access Points run wifi for your phones and laptops and Bluetooth (LE) for your IoT devices. If you don't have any IoT, you don't need the BLE functionality (there may be a way to turn it off in these products, but knowing Cisco, you can turn the functionality off but it won't protect you from the vulnerability).
In other words... IoT is a sack of insecure shite. If the device itself doesn't have vulnerabilities, the AP will. Great.
Enterprise procurement works the same, is the point. The decision makers for very large purchases don't understand the technology, but they do understand feature checklists.
Socialism: a lie told by totalitarians and believed by fools.
A lot of these devices don't even store the firmware themselves any more. They just have a bootloader and the firmware is loaded every time they are powered up.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
True, some don't, but the TI devices do have their own flash for firmware.
Some devices have their own onboard flash and bootloader. Others have no internal flash and they are initialized by the main CPU and run out of the main device flash.
Cortex A runs linux, but cortex M used in bluetooth devices cannot.
I said SHOULD, not DOES.
That would be up to the manufacturer that incorporates the BLE module into the product.
Tracking and advertising. These things emit BLE beacons that apps on your smartphone pick up. This allows for analytics in malls, geofencing ads, ... (Look up Eddystone and iBeacon.) That coupon app for your supermarket chain? Allows them to track your every move through their store, from the moment you enter to when you check out.
Other uses include "indoor GPS" (having the app show your location in the building on a map, ...).
https://documentation.meraki.c...
https://www.arubanetworks.com/...
https://www.cisco.com/c/en/us/...