Detecting and mitigating Bluetooth vulnerabilities in smart locks is critical to securing these IoT devices

A smart lock is an IoT device that facilitates access by opening a door without the need for a physical key. In this second part of the analysis of a smart lock, we will focus on evaluating Bluetooth communications.

We analyze the security of Bluetooth and the communications of a Yale Linus smart lock and tell you about the identified security problems.

The importance of evaluating this mechanism lies in the fact that the smart lock we are analyzing is controlled from a mobile phone via Bluetooth.

There are several vulnerabilities in Bluetooth technology. While BIAS and KNOB are the ones that have received the most attention, there are vulnerabilities such as BRAKTOOTH that have been exploited for a long time and there are other deficiencies that have taken years to be fixed. During the analysis of Bluetooth communications, the lock’s configurations will be checked to see if it is vulnerable to these attacks.

For a comprehensive security assessment of Bluetooth Low Energy Core 4.2, which is the version used by this smart lock, it is crucial to understand some key aspects of the Bluetooth architecture at a technical level. This will allow identifying potential risks and applying the appropriate measures to ensure secure communication through Bluetooth technology.

Introduction to Bluetooth

Bluetooth is implemented over 4 layers: L2CAP (logical link control and connection), Link Manager (link manager), Baseband (baseband) and Radio PHY (radio physical layer).
Since developing in Bluetooth without using abstraction layers is complex, the Bluetooth SIG (Special Interest Group) has provided developers with a tool called profiles.

Bluetooth profiles are specifications that define the functions and behaviors that devices must support to perform specific tasks. Among many others, the hands-free profile (HFP), the serial port profile (SPP) or the general access profile (GAP) can be mentioned.

The latter, GAP, is one of the fundamental profiles in the Bluetooth protocol stack and is therefore mandatory. In broad terms, GAP is an orchestrator and uses Bluetooth components such as SDP (service discovery protocol), SM (security manager) or GATT (generic attribute profile).

One of the most important resources that GAP has is GATT. The Generic Attribute Profile (GATT) provides the structure and set of rules for the transfer of data between Bluetooth devices, such as those that operate with the Bluetooth Low Energy (BLE) technology.

GATT is supported by the ATT (attribute protocol) protocol. The ATT protocol is fundamental in Bluetooth and allows the reading and writing of attributes, which are the units of information in which data is exchanged.

GATT uses ATT attributes and hierarchicalizes them to define the following concepts:

• Service: A collection of data and associated behaviors that implements a device functionality. It is identified by a UUID, which can be a 16-bit or 128-bit Bluetooth UUID.
• Characteristic: A data unit of a service that uses ATT attributes to define its properties and values. It can also contain additional data in the form of descriptors (also ATT attributes). It is identified by a UUID.
• Descriptors: The minimum data unit that allows defining a Characteristic. It is an ATT attribute.
• Profile: A standardized set of GATT services that a device must implement to fulfill a functionality. It is not the same as a Bluetooth profile such as GAP.

GATT uses a client-server architecture to exchange data. The client makes requests and the server sends responses. Servers can also send notifications to clients spontaneously.

Security in our Bluetooth device

Interoperability is essential for Bluetooth devices to work. Therefore, when security flaws are found in the protocol, the Bluetooth SIG must provide a solution. This can be difficult, as the solution must be backward compatible with existing devices.

To address these challenges, Bluetooth implements security mechanisms at several points in the protocol , such as in profiles, operating modes, and link/pairing.

Agencies such as NIST and associations such as OWASP provide guidance and methodologies to help developers improve the security of their devices. These resources can help developers configure the security mechanisms provided by the Bluetooth standard correctly.

Security defects can lead to a variety of problems, including:

• Man-in-the-middle (MiTM) attacks: These attacks allow an attacker to intercept and modify data transmitted between two devices.
• Denial-of-service (DoS) attacks: These attacks can prevent devices from communicating with each other.
• Remote code execution (RCE) attacks: These attacks allow an attacker to take control of a device.

Based on the previous explanation, one of the steps taken during the Bluetooth audit of the smart lock is to discover the exposed profiles and enumerate the attributes grouped into their services, characteristics, and descriptors.

The only thing that needs to be known about the device to perform this inspection is the MAC-ID of the device. We have developed a tool that will generate a list of parameters and check the read/write permission settings.

Device present (%s) 87:C9:85:0F:64:F5
Connecting to device…
INFO: connected
[Service] (%s) 00001800-0000-1000-8000-00805f9b34fb (Handle: 1): Generic Access Profile
INFO: Getting new uuid … [00002a00-0000-1000-8000-00805f9b34fb] Descriptor … [Device Name]
Reading characteristic 00002a00-0000-1000-8000-00805f9b34fb with na‘e ‘Device N’me’…
7 bytes read: 364c3030304655’(b’6L00’FU’)
OK.
Writing 546573745772697465537472696e6732566572696679416363657373 ’(b’TestWriteString2VerifyAcc’ss’)
ERROR: [Characteristic] 00002a00-0000-1000-8000-00805f9b34fb (Handle: 2): Device Name (read), Error: Could not write valu’ b’MachineSerialNumberRand’md’ to characteristic 0002: Access Denied

After establishing a connection and accessing the GAP service, the services are enumerated. Within the GAP profile, a descriptor named “Device Name” is located.

To verify the permissions, after reading this field, an attempt is made to write to it. The write attempt fails because the security configuration only allows read access.

The various UUIDs exposed by the lock’s services are continued to be checked, up to a total of 44. Most of them do not have read or write permissions and do not have a descriptor that helps to understand their use.

Only those that have been found to be the most interesting for security analysis will be discussed.

Manufacturer Name 00002a29-0000-1000-8000-00805f9b34fb

This field shows the information of the device manufacturer’s name. In this case, it has been very useful because it has allowed to reveal additional information about the device.

Although our lock is the “Yale Linus” model, this attribute indicates a different manufacturer: “August Home Inc.” This allows us to find more information about the lock and obtain references to security issues that it has had in the past and that have been resolved. The read/write configuration is correct.

Serial Number 00002a25-0000-1000-8000-00805f9b34fb

Although the mobile app has additional security controls in the cloud, the serial number field is data that should not be exposed on this device. This is the only data required to configure a lock in the app. The read/write configuration was correct.

AVDTP 00000019-0000-1000-8000-0026bb765291

This is the audio and video streaming protocol profile, generally this is configured on multimedia devices such as photo frames. It should not be present on this device.

Bluetooth communications analysis

Next, the Bluetooth communications between the mobile phone (with the manufacturer’s application) and the lock were captured.

These Bluetooth frames are reviewed with the help of WireShark and it is verified that the mechanisms provided by the standard have been correctly configured, in this case the secure pairing parameters such as the secure connection (Secure Connection Flag) and prevention against man-in-the-middle attacks (MITM Flag) are active.

The button press attribute (Keypress Flag) is not configured because the lock lacks buttons.

The information obtained also shows that the communications between the lock and the mobile are encrypted, using Bluetooth encryption and an application layer encoding by exchanging fixed-length packets, sending 30-byte packets with 10-byte responses.

The packets with the longest length (30 Bytes) are the ones that initiate a communication and use the handlers 0x0014 and 0x0019 when the message originates from the lock and 0x0012 and 0x0017 if the message originates from the mobile device. The last two bytes of these packets always contain the values 0x02 0x00.

The packets with the shortest length (10 Bytes) are the ones that terminate the communications and seem to be an ACK (a signal or message sent by a receiver to indicate that it has received the communication).

Thanks to the discovery of the rebranding, the search for vulnerabilities was expanded to the manufacturer August, which was linked to the Bluetooth vulnerabilities SWEYNTOOTH.

The conclusion of this audit is that the Bluetooth security settings of the lock are correct, and are implemented with the maximum level of security possible for the version of the standard used. However, there are some defects that expose unnecessary data:

1. The “Serial Number” feature should not be publicly available, as it is the only parameter required to configure the lock in the application. This could allow for other attacks not considered to date.
2. The “AVDTP” profile/service should not be available, as it only increases the attack surface of the lock. It is recommended to disable it if it is not used.

It would be relevant to study in the future the encoding mechanism of messages exchanged between the lock and the application, in case there are weaknesses in it.

Although OWASP and NIST guidelines are not mandatory, they should be taken into account by paying attention to their recommendations to achieve the best possible security in devices.

In addition, performing an IoT security audit is essential to detect potential security flaws, such as Bluetooth vulnerabilities in smart locks, and mitigate them before they are successfully exploited by hostile actors.

References

Bluetooth Errata correction 11838: https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=470741