Bluetooth is an established yet growing technology that allows the exchange of data between devices in a wireless personal area network (WPAN). It started in 1996, when Intel, Ericsson, and Nokia met to standardize a short-range radio technology to support connectivity between their products. The first specification was released in 1999, and from then, Bluetooth devices have experienced a very strong growth, as shown in the following figure:
The main two Bluetooth radio versions are:
Bluetooth Classic and BLE use different stacks that have no compatibility. However, they can coexist in one device sharing the same antenna, because both use the same radio frequencies of the 2.4 GHz ISM band and apply frequency-hopping spread spectrum (FHSS) mechanisms to avoid interferences. In fact, in many cases, they complement each other; that’s the reason why nowadays most devices are dual mode. As shown below, Bluetooth Classic single-mode devices are projected to disappear in the future, while BLE single-mode devices grow due to the expanding IoT industry.
It is important to note that Bluetooth Classic is not an obsolete version of BLE; they are different technologies used for different applications. Bluetooth Classic is mainly used when point-to-point continuous streaming is required, e.g., wireless audio streaming (wireless speakers, headphones, in-car entertainment systems) or file transfers. On the other hand, BLE is designed for very low-power operations and supports multiple communication topologies, expanding from point-to-point to broadcast and mesh. Examples of BLE applications are monitoring sensors, beacons, and high-accuracy, indoor location services.
This post is focused on BLE, specifically version 4.2, which will be active until February 2025. It’s important to note that there is a version 5 of the Bluetooth specification that introduces some new features not outlined in this post (for example, extended advertising, mesh networking, or direction finding). However, version 5 devices are not so common in the market yet.
What makes it “low energy”?
The main point is that BLE keeps the radio off for as much as possible. This is achieved by the following:
BLE Stack:
App Layer |
Applications |
|
Host |
Generic Access Profile (GAP) |
|
Generic Attribute Profile (GATT) |
||
Attribute Protocol (ATT) |
Security Manager |
|
Logical Link Control & Adaptation Protocol (L2CAP) |
||
Controller |
Link Layer |
Direct Test Mode |
Physical Layer |
Let’s define briefly how each layer works:
The application layer is typically where the most important data resides. Below this layer, the others are responsible of transporting or converting the data.
GAP defines two main aspects in BLE connections:
There are two main connection modes in BLE: Advertising (sending data in one direction, without establishing a connection) and Connected (sending data in both directions).
Only after the visibility and the interaction aspects have been completely set by GAP, GATT then defines how the devices exchange information with each other. For this, GATT uses ATT as an underlying protocol to define how a server exposes its data to a client and how the data is structured. The data is structured as attributes, which can be one of several types (commands, requests, responses, notifications, indications, or confirmations), and are stored in a table using 16-bit unique IDs (also named ‘handles’) for each entry. So, the handle of an attribute can go from 0x0001 to 0xFFFF. According to the Bluetooth Specification, an attribute handle of value 0x0000 is reserved and shall not be used.
As said before, GATT defines how to interface with the attributes (data that must be sent), and for this, it uses the following concepts:
gatttool is a useful tool that can be used to play with these attributes.
The Security Manager in BLE is responsible for security procedures such as pairing, encryption, and signing. All connections start from a “no security” mode (no pairing), and when they want to exchange data in a secure way, they need to pair. The pairing procedure involves the exchange of a Temporary Key (TK) to generate a Short-Term Key (STK), which is used to encrypt the connection link. The security of the whole communication highly depends on how this TK is exchanged. There are four association models (for BLE 4.2) and choosing one or another depends on the input/output capabilities of the devices (information that is exchanged in clear text). We’ve sorted them from most insecure to most secure:
Association models (1-3) are known as LE Legacy Pairing and should be avoided due to their lack of security.
Association model (4) is the most secure and known as LE Secure Connections (introduced in BLE 4.2). The main difference in this model is that, instead of using TK and STK, these association models use a Long-Term Key (LTK) to encrypt the connection link and public key cryptography (specifically the Elliptic Curve Diffie Hellman algorithm) is used to exchange the LTK. This improvement protects against eavesdropping attacks, but not against MitM attacks.
In conclusion, the main and difficult goal of all association models listed above is to securely exchange a key between two devices which don’t have an established connection. The big advantage is that usually both devices have a human between them.
Next is the Logical Link Control & Adaptation Protocol (L2CAP) layer, which is responsible for multiplexing, segmentation and reassembly, logical connection establishment, and flow control. It is equivalent to IP in the TCP/IP stack.
Finally, we have the link layer, which is responsible for scanning, advertising, and creating connections, and interacts directly with the physical layer that converts the bits to RF. These two layers are implemented by hardware in the Bluetooth chip. All the others are implemented by software in the device.
Pen Testing BLE Connections
What about its security? BLE is just a technology; so, the responsibility of BLE security between two devices relies on the implementation applied by the manufacturer.
When you have full control of at least one device:
The easiest way to pen test BLE devices is using the Host-Controller Interface (HCI). As said before, the Host layers are implemented by software, and the Controller layers are implemented by hardware. The Bluetooth HCI specifies all interactions between them, and these interactions can be logged. No additional hardware is needed.
Logging HCI events and commands is very easy, especially on Android, Linux, and OS X systems:
The logging applications generate BTsnoop-formatted files, which are not plain text. However, they can easily be loaded into Wireshark. The following Wireshark filters are useful for analyzing BLE traffic:
For Bluetooth Classic:
Logging is always easier than sniffing and should be used whenever possible.
When you do not have full control of any device:
For example, when you want to analyze BLE traffic between a wireless game controller and its game console. Typically, we have three options in this scenario:
The last option usually requires additional hardware, such as the BBC MicroBit, the BlueFruit, or the Ubertooth. However, these devices are not reliable, and they lose packets, even when a connection was already caught.
Additionally, each of these devices can listen only on one BLE channel. Because the BLE spectrum has three advertisement channels, the probability of catching a connection by using one device would be 33.33%. Using two devices, the would be 66.66%. And using three devices (one per advertisement channel), the probability would be 100%.
The software usually used for sniffing is BTLE Jack, which automatically all the difficulties caused by the frequency hopping mechanism applied in BLE.
For more professional tasks, the company Ellisys sells very good and reliable devices used for Bluetooth sniffing, such as the Bluetooth Explorer or the Bluetooth Vanguard. However, prices are much higher than the MicroBit or the BlueFruit.
In conclusion, for most pen testing projects, it is enough to log the traffic using the Host-Controller Interface. In case the consultant does not have full control over any device, one BBC MicroBit (or similar sniffing tool) should be enough. However, they will need to repeat the process if the device loses packets.
MitM
When logging or sniffing is not enough and modifying the traffic is required, we typically use two attack vectors:
Nowadays, some vendors apply heavy obfuscation to their application’s code, making it very difficult for a reverse-engineer to understand. Additionally, pen tests are almost always time-boxed, so the first option usually becomes infeasible when the code is obfuscated.
However, using just a laptop and two BLE dongles, MitM attacks can be performed without needing any kind of analysis of the firmware or the mobile application. So, code obfuscation does not protect against the second attack vector.
Tools like gattacker and BTLE Juice already take care of all the BLE protocol phases and features to allow MitM and relay attacks. These tools are very flexible and are great for discovering new flaws in applications or in the BLE protocol itself.
For example, an attacker could use the tool gattacker to MitM a connection between two devices during the pairing phase and modify the traffic to trick the devices into a more insecure association model.
Conclusion
I highly encourage you to start looking into BLE and IoT devices. A lot of IoT vendors are still applying very weak security (if any) to their devices, which is equivalent to the same security as computers in the 90’s. And as shown above, you may already have the hardware (if not, you just need less than $100).
Subscribe to Bishop Fox's Security Blog
Be first to learn about latest tools, advisories, and findings.