Millions of devices, primarily network access points, could very well be vulnerable to two new types of proximity-based attacks discovered by Armis and dubbed Bleedingbit.
The vulnerabilities lie within Bluetooth Low Energy chips manufactured by Texas Instruments (TI) that are embedded in popular network access points used by Meraki, Cisco, and Aruba—the three largest network providers in the world, who together make up nearly 70 percent of the market.
While the network providers and TI have been aware of the vulnerability since June of this year—and many have provided patches to their devices (or SDK in TI’s case)—researchers are still worried that millions of other devices which leverage BLE chips could still be vulnerable.
Here’s everything you need to know about the Bleedingbit vulnerabilities, and how sentry processors provide the best means of closing down this attack vector.
What Are the Bleedingbit Vulnerabilities?
Bleedingbit is not one, but two different vulnerabilities that exploit attack vectors in embedded BLE chips. While the Armis blog focuses on the impact of the vulnerabilities on network access points, the TI chips in question, as well as the BLE protocol, are used in a wide variety of other applications, such as IoT devices, and therefore could affect millions of devices.
The two vulnerabilities are classified as such:
- CVE-2018-16986: A vulnerability that allows a buffer overflow attack, resulting in Remote Code Execution (RCE). According to Armis, an attacker just needs to be in the vicinity of an access point, and begin sending it “benign BLE broadcast messages, called ‘advertising packets,’ which will be stored on the memory of the vulnerable BLE Chip in a targeted device.” The attacker can then use a buffer overflow to overwrite bits of memory that eventually cause control to transfer to memory whose content is controlled by the attacker (thanks to those previously mentioned advertising packets). From here, the attacker can begin running malicious code that allows them to take control of the device, and, among other things, propagate the attack to other devices on the network.
- CVE-2018-7080: This vulnerability is unique to the Aruba 300 Series of access points and is due to the way the device is updated. The CVE-2018-7080 vulnerability exploits the Over-the-Air firmware Download (OAD) feature of TI’s BLE chip—which is essentially a backdoor into the system. While a hardcoded password exists on these access points to prevent attacks, the password is identical on all devices and can be easily sniffed or found in a reverse-engineering effort. In either case, once that password is obtained, the attacker can flash an entirely new firmware onto the access point and gain total control. Aruba issued an advisory to their users in October about this OAD vulnerability and noted that options for securing the devices are limited to software patches or through disabling the bluetooth on affected devices, according to TechCrunch.
Since these vulnerabilities leverage exploits in BLE chips, they’re “airborne,” or, said differently, they’re not coming over the network. Because of this, they can’t be detected through traditional means, and can be considered contagious in the same way that other similar attacks such as BlueBorne and the KRACK Attack.
What is Bluetooth Low Energy and How Is It Used In Embedded Systems Today
BLE is a communication protocol that is highly leveraged in embedded systems today. While it was established on the traditional Bluetooth protocol, it goes beyond traditional Bluetooth in allowing users to create networks. We can think of these as mesh networks used within enterprises to spread Wifi across large buildings or office spaces. But BLE is used in a wide variety of applications outside of this.
For example, BLE is used at the point of sale in businesses to help collect information on customers, it’s used in hospitals to keep track of resources, and it’s used in medical devices like insulin pumps and pacemakers to help doctors adjust devices without conducting invasive procedures like surgery. You’ve probably encountered BLE capabilities at local shopping malls, as well, when your phone automatically pulls up a directory after you’ve entered the building.
BLE is a rapidly growing technology and new use cases are being discovered for it every day, thanks to the rise of the Internet of Things. This means that BLE chips are becoming more popular, therefore providing ample opportunities for attackers who wish to subvert them.
What is the major implication of Bleedingbit?
The popularity of BLE and its use in mesh networks such as those leveraged by enterprises, creates a major problem for fans of network segmentation.
As you may know, network segmentation is a primary means of securing a network in an enterprise (or home), today. Even if you’re not familiar with the jargon, you’ve definitely encountered network segmentation in your day-to-day life. Network segmentation is the reason your router at work provides two networks to join: a private network and a guest network.
Network segmentation allows us to split our internet connection in two and put secure devices on one and unsecured devices on the other (such as the guest network).
According to Armis, however, Bleedingbit erases the security provided by network segmentation. Their research indicates that an attacker who gains control of the access point would also gain control over all segments of the network, simultaneously—or even have the ability to delete entire segments all together.
Two Ways Sentry Processors Can Truly Stop Bleedingbit CVE-2018-16986 Before Attackers Compromise a Single Access Point
Before we discuss sentry processors, it’s important to note that cybersecurity must be considered at the design level. It’s up to manufacturers to provide the most basic levels of security for their devices—such as hashing passwords and digitally signing firmware—if they want to prevent attacks that exploit vulnerabilities like CVE-2018-7080. Unfortunately, this clearly isn’t the case here with Bleedingbit-vulnerable systems and is a problem throughout the networking space.
As we’ve discussed in the past, cybersecurity requires a multi-layered approach. The basic security features that manufacturers provide do not constitute a “secure device,” but provide a foundation to build upon. Without the basics, any security stack that you try to build on top of your product will be ineffective and collapse.
However, if you are already providing basic security capabilities for your device, then a sentry processor like CoreGuard® can help you truly protect the device against Bleedingbit in a way traditional fixes like patching cannot.
Why Software Patches Are Not a True Security Solution
First and foremost, software updates aimed at shutting down attack vectors (patches) are a poor solution because all they do is layer new software on top of an older layer of flawed software. Since all software is written in code, and no code is perfect, all software contains vulnerabilities. By patching exploitable software, all we’re doing is replacing one vulnerability with (a) potentially new one(s).
Secondly, patching devices like access points (or other, disparate, unmanaged devices) is extremely difficult. As Shay Nahari, head of Red Team services at CyberArk, based in Newton, MA, told TechTarget, "Mitigating the risk by patching is extremely difficult, since, in many cases, there are no agents installed on these devices and the routers often sit at demilitarized zone or in segmented networks, making it a burden to patch."
CoreGuard, on the other hand, is silicon IP that lives on the SoC and acts like a bodyguard for the host processor by monitoring every single instruction executed by the host processor. Through the use of proprietary technology, CoreGuard is able to leverage the metadata a compiler typically throws away, and compare that data to a pre-established set of security, safety, and privacy rules, known as micropolicies. If the metadata violates one of the micropolicies CoreGuard has on file, then CoreGuard interrupts the processor, stopping it from executing the malicious code before any damage can be done.
This makes CoreGuard the perfect solution for shutting down the CVE-2018-7080 attack vector in vulnerable BLE chips.
Stopping the Exploitation of CVE-2018-16986
As mentioned above, this is a Remote Code Execution vulnerability. CoreGuard can stop RCE attacks through its Heap or Read/Write/Execute (RWX) Micropolicies, in the context of this Bleedingbit vulnerability.
To start, the Heap Micropolicy would shut down this attack vector by preventing the buffer overflow that launches the attack in the first place. This is accomplished by assigning a color to the buffer in which data resides, as well as to the pointer for that buffer. For example, blue for a username buffer and its pointer, and yellow for a password buffer and its pointer. CoreGuard’s Heap Micropolicy dictates that an instruction cannot write data to a buffer with a color that doesn’t match the color of the pointer to the buffer, thus stopping this attack.
Secondly, CoreGuard can prevent the host processor from executing code that is arbitrarily injected into memory through its RWX Micropolicy. The RWX Micropolicy can label each word in memory with metadata that indicates whether it is readable, writable, and/or executable. This policy, therefore, is designed to block attacks that try to manipulate data in a way they shouldn’t. For example, a code injection attack can exploit a software vulnerability (such as a buffer overflow) to introduce arbitrary code that will change the system’s course of execution, as is the case here. CoreGuard’s basic RWX Micropolicy can easily prevent the successful execution of injected code, as the injected code will be in a region of memory labeled non-executable.
How To Secure The Next Generation of BLE Chips
While TI has confirmed the bugs that Armis discovered, and has since issued patches, they’ve also attacked the security researcher for their work, “calling its report ‘factually unsubstantiated and potentially misleading,’” according to TechCrunch’s reporting. The other three network providers in question—Cisco, Aruba, and Meraki—have also released patches.
However patches, and all software-based security, are non-sustainable answers. The only way to truly secure an embedded system is by implementing security at the lowest possible level—in the hardware—with silicon IP like CoreGuard.
To learn more about how CoreGuard can be your processor’s bodyguard and help secure your embedded system, request a demo today.