IoT Security Part 4 - Bluetooth’s battle with the hackers heats up

Bluetooth is one of the most widespread wireless protocols in use today. Having started as a way of extending the functionality of smartphones, it is now becoming fundamental to the development of the Internet of Things (IoT). The arrival of Bluetooth 5 brings with it new features intended to support use of the wireless protocol in larger networks. One of these changes is an increase in the maximum range to 200m, supporting the use of Bluetooth in building-wide networks. The addition of mesh capability and support for 6LoWPAN connectivity confirms the evolution of Bluetooth from a personal-area network to a short-range, multipurpose network that, in principle, challenges other options for IoT connectivity such as Thread and Zigbee.

Bluetooth connects devices as disparate as audio headsets, thermostats, security sensors and heart-rate monitors. But with the rise in use of Bluetooth devices that track health and other sensitive aspects of our personal lives, the security of the connection itself is now a critical issue.

Bluetooth attacks

Unfortunately, through a combination of factors, Bluetooth has proven to be vulnerable to a variety of attacks. The BlueBorne attack vector that Armis Labs identified in September 2017 is just one example that demonstrated how the nature of attacks is changing and making it harder to protect against them. From the beginning, the Bluetooth protocol itself suffered from weaknesses that made it possible for an attacker to take control of a device remotely or force it to execute malicious code. The most serious security shortcomings of the protocol were addressed with the release of version 2.1 in 2007. Since then, issues in the core protocol have been relatively minor and it has not been possible to have a device under attack run malicious code.

Although the protocol is now more secure than it was at the beginning, implementations of Bluetooth and common usage mechanisms have exposed multiple vulnerabilities. Some security researchers argue that a number of the problems in Bluetooth implementations stem from its high complexity and accommodation of different application profiles. Today, the specification for Bluetooth extends to more than 2800 pages.

Such complexity can easily play host to a large number of potential vulnerabilities. For example, there are multiple fragmentation layers within the full Bluetooth stack that are used to split long messages into small physical-layer frames. Each fragmentation layer provides an opportunity to find weaknesses that can be exploited by commonly used techniques such as buffer overflow. Typically, such an attack sends a deliberately oversized protocol frame that causes data to spill out from the end of the fixed-sized buffer that a task will have allocated to hold the data. Careful manipulation of this data makes it possible for the hacker to start to take control of the stack and, from there, the device itself.

A further factor in the security challenges facing Bluetooth stems from features that were implemented largely to improve ease of use and speed commissioning. Using typical default settings, Bluetooth devices will broadcast information about themselves that provides information that attackers employ to take control of them. Devices that employ connection protocols from earlier versions of the standard perform very little authentication. Many Bluetooth devices with limited user interfaces employ “Just Works” pairing. Many IoT devices fall into this category as they are just sensor nodes with no recognisable user interface. Just Works pairing involves the use of short passkeys – often just four digits long – or no passkey at all. This makes it practically impossible to authenticate the endpoint properly.

One attack that poor authentication enables is “bluebugging”. This involves spoofing a device to which a user wants to connect their device. Once connected, the hacker’s device can be used to access data on the target or attempt to upload a worm or virus. The disadvantage to the hacker is that such an attack relies on the ability to fool a user into connecting, which reduces the probability of success. With an attack based on BlueBorne or as yet undiscovered vulnerabilities, the hacker does not require the active participation of the user.

The man-in-the-middle (MITM) attack itself is one method that attackers have used to avoid detection of their intrusion and is one that is highly applicable to IoT applications. Under MITM, the attacker uses their device as an intermediary between two authorised endpoints, such as an IoT sensor node and a gateway, which may be a smartphone or a home router. The attacker typically will have their device act as the gateway and pass on messages to the intended destination. Once in the middle, new messages can be injected or messages passing though corrupted. Both endpoints will be fooled into believing that they are participating with each other directly.

Figure 1: Man-in-the-middle attack - Copyright Premier Farnell Ltd

The attacker can even eavesdrop on communications that the authorised parties believe to be encrypted successfully if the attack occurs early enough. The shared public key provided by one of the endpoints can be intercepted and replaced by one used by the attacker during the pairing process. In many cases today, only limited encryption is used. Before Bluetooth 2.1, transmissions between paired devices need not be encrypted at the link layer. This has now changed, which adds a degree of data protection.

However, even as the protocol specification is progressively tightened to deal with mistakes and to improve overall security, Bluetooth implementations provide trapdoors that can be readily exploited by hackers. BlueBorne provides an example that is very difficult to protect against.

BlueBorne: a major Bluetooth attack vector

BlueBorne is the collective term coined by Armis for eight different vulnerabilities in the Bluetooth stacks that lie inside many mobile devices. By exploiting a BlueBorne vulnerability, not only is an attacker able to penetrate and control a single device by infecting it with malicious code, the code can spread from device to device using Bluetooth alone. This makes it possible to attack networks that are otherwise “air gapped” – those that have no connection to each other or the wider internet – if they have devices with active Bluetooth interfaces.

One of the reasons why Armis researchers consider BlueBorne dangerous is the combination of vulnerabilities in the Bluetooth stacks of many devices, the nature of the Bluetooth stack and design decisions made in many of embedded and IoT devices. In the latter case, a key problem is that the Bluetooth stack has high privilege in many platforms. This means an attack that takes control of the Bluetooth firmware and processes in a device is more easily able to take control of the device’s core functions.

The BlueBorne attack involves a number of steps. The first is to identify active Bluetooth devices in the vicinity. These can be found even if the Bluetooth endpoint is set to be non-discoverable. This is possible because active Bluetooth devices will listen for packets sent to it. To send a packet to an endpoint requires knowledge of its unique Bluetooth device address (BDADDR). Although a non-discoverable device does not advertise its BDADDR, it is possible in many cases to determine the BDADDR of a target simply by monitoring communications between connected devices.

A convention adopted by many manufacturers if Bluetooth is active but dormant makes it possible to determine the BDADDR from WiFi traffic. Wifi media-access control (MAC) address are not encrypted and, on a given device, the BDADDR will be set to be the same or offset by a value of one.

Subtle differences in implementation make it possible, on further probing, to determine the underlying operating system. The device might not reveal the operating system and platform explicitly but the attacker can work them out by comparing known responses to probes. Using this information, the attacker can use knowledge of vulnerabilities in specific parts of the stack to attempt to penetrate the system.

Addressing Bluetooth security

The best protection against attack is simply to deactivate Bluetooth entirely. However, given the nature of the IoT, this is impractical if Bluetooth is used as the main wireless connection to sensor nodes and other devices. In principle, setting the device to be non-discoverable by others that do not have a formal connection makes it harder to find and attack it. However, the BlueBorne attack vector demonstrates that this level of protection will not defend against a more determined assailant.

A layered approach provides a degree of protection against most attacks although a sophisticated targeted hack will prove troublesome for practically all devices with active Bluetooth interfaces. In building defences, it is important to distinguish between problems that stem from choices made by the protocol designers and those that result from programming mistakes or poor assumptions. For example, attacks such as BlueBorne focus on the failure of specific software functions to cope with deliberately malformed packets and the data structures they are assumed to contain.

Over time, the industry can expect programming practices to improve now that the prevalence of buffer-overflow and data-injection attacks has been demonstrated on many communications protocols employed by embedded and IoT devices. Even so, such problems will continue to be discovered as the IoT and its use of Bluetooth expands. Manufacturers and integrators of IoT devices need to plan not only for the consequences of vulnerabilities but for their products to be patched once fixes have been published. That means providing mechanisms that allow software updates to be transferred to the device and installed correctly. If Bluetooth is the only communications protocol in use, manufacturers have to plan for the eventuality that a compromised device will reject update attempts. As a result, the internal firmware needs to be designed in such a way that it can boot securely into a factory-installation mode or other known safe mode and update from that.

There are recent additions to the Bluetooth protocol that manufacturers and integrators can use to improve overall levels of security. Version 4.2, for example, introduced a pairing process based on numeric comparisons. However, this is a mechanism that relies on some form of display being available on the IoT device. Under numeric comparison, a six-digit key generated by the device attempting to connect to another appears on both devices. The user must verify that they are the same number for the connection to be set up correctly. A problem with using this approach is that it does not protect against attacks using counterfeiting techniques that can fool a user into believing they have connected with an authentic device.

An approach to pairing that can offer much higher levels of security is to use a separate communications channel. Although the channel is used in a one-off commissioning process simply for pairing and not for normal data transfers, the addition of an extra RF transceiver need not significantly increase the cost and complexity. The Near-Field Communication (NFC) protocol provides a cost-effective channel and has the advantage that the attacker needs to be close to the target device in order to intercept its communications. To link two devices, the user simply taps the NFC-enable IoT device onto the other unit and the protocol takes care of the handshake.

A major advantage of NFC is that it can not only provide a way to use the more secure pairing mechanisms of later version of Bluetooth but also perform security checks. The NFC-enabled commissioning device can check factory-installed security certificates for authenticity and when satisfied deliver public keys that can used to support end-to-end encryption during commissioning and use. This makes eavesdropping attacks on the Bluetooth channel much harder to use just as long as there are no usable vulnerabilities in the software running on the IoT device that processes the encrypted stream or in the underlying Bluetooth stack.

An even cheaper, though less convenient and effective, approach compared to a side channel such as NFC is the use of a simple peel-off label attached to the IoT device. As long as the code is unique and not replicated across other devices of the same type, this provides a way to use a legacy pairing technique in a reasonably secure manner. Similar approaches can be used to aid the commissioning not just of Bluetooth-connected but those using IoT-focused alternatives such as Zigbee and Z-Wave.

Conclusion

Since its introduction two decades ago, Bluetooth has made strides as a short-range, low-power wireless protocol. It now underpins a growing base of IoT devices. Any widely used protocol will represent a valuable target for hackers. The problem for manufacturers and integrators is that the complexity and implementation challenges of Bluetooth make it vulnerable. Although it is possible to take steps to reduce risk, such as using secondary channels to commission devices, Bluetooth can not yet be considered secure. In applications where high levels of data security are required, engineering teams should look at other options.

IoT Security Part 4 - Bluetooth’s battle with the hackers heats up. Date published: 15th December 2017 by Farnell element14