Unauthenticated Pre-Pairing GATT Write Vulnerability in Smartwatch Ecosystems

Unauthenticated Pre-Pairing GATT Write Vulnerability in Smartwatch Ecosystems

Speakers: Gurjot Singh, Security Researcher, Innspark Solutions; Vipin Venu, Senior Security Researcher, Innspark Solutions; Arjun V, Innspark Solutions

Conference: Nullcon

YouTube: https://www.youtube.com/watch?v=q-yIqXaOIeo

Overview

This talk, presented by Gurjot Singh, Vipin Venu, and Arjun V from Innspark Solutions at Nullcon, unveils a critical security flaw dubbed Unauthenticated Pre-Pairing GATT Write Vulnerability affecting a vast segment of the smartwatch ecosystem. The researchers demonstrate how an attacker can exploit this vulnerability to read sensitive user data and write arbitrary commands to smartwatches without requiring any prior authentication or pairing. This means an adversary can send fake calls, trigger custom notifications from any app, set alarms, activate "Find My Device," or even factory reset a victim's watch, all while remaining undetected.

The significance of this research cannot be overstated. With an estimated 200 million smartwatches shipped annually worldwide and 70% of the Indian market potentially vulnerable, the implications for user privacy, security, and even public safety are profound. The vulnerability leverages fundamental implementation oversights in how Bluetooth Low Energy (BLE) Generic Attribute Profile (GATT) characteristics are handled by many budget-friendly smartwatch manufacturers, turning these personal devices into tools for social engineering, disruption, or even physical harassment.

The researchers not only detail the technical intricacies of the vulnerability but also showcase a proof-of-concept application capable of automating these attacks. Their work highlights a widespread class of vulnerability stemming from common firmware development practices, urging both users to be cautious and manufacturers to adopt more robust security protocols that prioritize authentication and encryption from the outset, rather than relying on default, insecure configurations.

Background

▶ Watch: Live demo: Hacking a smartwatch in-flight (0:00)

To understand the Unauthenticated Pre-Pairing GATT Write Vulnerability, it's essential to first grasp some foundational concepts of Bluetooth Low Energy (BLE). Unlike classic Bluetooth, which is designed for continuous, high-bandwidth data streaming (like audio), BLE is optimized for low power consumption, making it ideal for small Internet of Things (IoT) devices such as smartwatches, fitness trackers, and sensors that need to send small packets of data intermittently. This power efficiency is achieved by allowing devices to "sleep" between data transmissions.

A common misconception, as highlighted by the speakers, is equating "connection" with "pairing." A connection is a temporary session, akin to browsing an HTTP website without authentication – you can see what's there, but not necessarily interact deeply or securely. Pairing, on the other hand, is a secure process involving the exchange of session keys and encryption, similar to enabling TLS or logging into a secure website. Many vulnerable smartwatches allow connections without requiring proper pairing for critical operations.

BLE communication is structured around two key profiles: Generic Access Profile (GAP) and Generic Attribute Profile (GATT). GAP is responsible for device discovery (broadcasting), connection initiation, and connection management. It's why your phone can "see" nearby Bluetooth devices. Once a connection is established via GAP, GATT takes over for data exchange. GATT operates on the concept of "attributes," which include services, characteristics, and descriptors. In this architecture, the smartwatch typically acts as the server (or peripheral), providing data and services, while the phone acts as the client, requesting and consuming that data.

Within GATT, characteristics are the core elements where data is stored and manipulated. Each characteristic has properties (defining what operations are allowed, e.g., read, write, indicate, notify), a handle (a unique identifier, like a port number), and a UUID (a universally unique identifier that describes the characteristic's purpose). The speakers analogize this to a web server (smartwatch) running on HTTP, openly broadcasting its API documentation (GATT characteristics) without authentication. However, the UUIDs and handles are often obscure, requiring reverse engineering to understand their function – a task the researchers undertook. The problem arises when these characteristics, especially those with "write" properties, are accessible without the necessary authentication, leading to the "pre-pairing" vulnerability.

Key Findings

▶ Watch: Clarifying 'Connection' vs. 'Pairing' in Bluetooth (4:00)

The central finding of this research is the widespread existence of an unauthenticated pre-pairing GATT write vulnerability across numerous budget smartwatch models. The researchers discovered that many smartwatches, particularly those from less established OEMs, permit write operations to critical GATT characteristics before a secure pairing process has been completed. This oversight allows an attacker in proximity to a vulnerable device to bypass security mechanisms entirely.

The vulnerability manifests in two primary ways:

1. Unauthenticated Data Reading: An attacker can connect to a smartwatch and read sensitive user data such as step counts, heart rate, sleep cycles, calories burned, and general activity data. This allows for detailed tracking and surveillance of a user's daily routine without their knowledge or consent, essentially "stalking over Bluetooth."
2. Unauthenticated Data Writing and Command Execution: More critically, the vulnerability enables an attacker to write arbitrary data and commands to the smartwatch. The demonstrated impacts include:

• Triggering Fake Calls: Sending a fabricated incoming call notification, complete with custom caller ID (e.g., "911 emergency").
• Injecting Fake Notifications: Sending custom notifications that appear to originate from legitimate applications like Instagram or WhatsApp, capable of breaking user trust or causing panic.
• Setting Alarms: Injecting multiple alarms that could repeatedly trigger at specific times, causing disruption.
• Activating "Find My Device": Triggering the watch's "Find My Device" function, causing it to vibrate and make noise, even if the watch is in silent mode, leading to disruption in quiet environments.
• Factory Resetting the Device: Remotely wiping the smartwatch, causing data loss and disrupting essential functions, as demonstrated with the example of a marathon runner losing their tracked progress.
• Physical DDoS Attacks: Repeatedly triggering functions like vibration, which can lead to excessive battery drain, overheating, and potentially physical damage to the device.

The root cause of this vulnerability was traced back to fundamental flaws in the firmware implementation of these smartwatches. Through reverse engineering of the firmware using tools like CH341A/B for flash chip extraction and Ghidra for analysis, the researchers identified two main scenarios:

• Incorrect GATT Property Configuration: Many OEMs use default configurations of BLE chips that expose GATT characteristics with the 0x04 property (write without response) but incorrectly set the security byte to 0x00, resulting in 0x0400. This 0x00 explicitly denotes unauthenticated access. To enforce authentication, the property should be 0x0408 or similar, requiring an authenticated write. The developers failed to change this default.
• Flawed Bonded State Handling: In other OEM firmwares, a variable (var2) responsible for indicating the device's bonded (paired) state was explicitly set to 0 (unbonded), effectively bypassing any checks for a secure pairing before allowing write operations.

These findings reveal that this is not an isolated vulnerability in a single product but rather a class of vulnerability stemming from common, insecure development practices prevalent among many budget smartwatch manufacturers, making a significant portion of the global smartwatch market susceptible to these attacks.

Technical Deep Dive

▶ Watch: Exploring GATT characteristics: properties, handles, UUIDs (6:00)

The technical core of the Unauthenticated Pre-Pairing GATT Write Vulnerability lies in the misuse and misconfiguration of Bluetooth Low Energy (BLE) GATT characteristics within smartwatch firmware. As established, smartwatches function as GATT servers, exposing various services and characteristics that client devices (like smartphones) can interact with.

The researchers' initial step was to identify how these interactions occur. They used BT Snoop, an Android developer option for capturing Bluetooth logs, and then analyzed these logs with Wireshark. This revealed that many BLE communications, particularly in the pre-pairing phase, occurred in plain text, making them susceptible to analysis and manipulation.

A crucial discovery was the identification of GATT characteristics that allowed write operations without authentication. Each characteristic is defined by its properties, handle, and UUID. The properties define what actions can be performed on the characteristic. The researchers specifically looked for characteristics with write properties, particularly 0x04, which signifies "write without response." This property allows a client to send data to the server without expecting an acknowledgment, making the operation fast but potentially risky if not properly secured.

To pinpoint the specific characteristics responsible for the attacks, two methods were employed:

1. OEM-Specific UUID Mapping: For certain OEMs, the researchers identified a static UUID, 000 FEE2, which consistently mapped to the characteristic responsible for various write functionalities, including sending notifications and calls. This UUID acted as a "magic identifier" for critical write operations. Once this UUID was found, the corresponding handle could be used to target the write operation.
2. Reverse Engineering and Brute Force: For other devices, a more laborious process of reverse engineering was required. By systematically testing different handles and observing their effects, the researchers were able to map unknown UUIDs and handles to their respective functions (e.g., heart rate reading, step counting, notification triggering). This allowed them to understand the "API documentation" of the smartwatch's GATT server.

Once the vulnerable write characteristics were identified, the next challenge was to craft valid payloads that the smartwatch firmware would parse and execute. Through further reverse engineering of captured traffic, the researchers deciphered the specific structure of these payloads:

• FEEA: This acts as an OEM header or magic byte, signaling the start of a valid command payload. Similar to how file formats use magic bytes, this tells the firmware to process the following data as a command.
• 20: This byte represents the command class, specifically indicating a "CMD write" operation. The firmware interprets this as an instruction to execute a command rather than just store data.
• 18: This byte specifies the declared length of the subsequent payload section, ensuring the firmware correctly parses the command data.
• 41XX (e.g., 4108): This is the application identifier. By changing the XX part, an attacker can impersonate different applications (e.g., 4108 might be a generic call, while other values could simulate WhatsApp or Instagram notifications). This allows the attacker to craft highly convincing fake notifications.
• UTF-8 Encoded Text: The final part of the payload is the actual message or content, encoded in UTF-8 and then converted into a hex blob before being sent to the watch. This allows for arbitrary text to be displayed on the watch screen.

The true root cause of the vulnerability, however, lies deeper in the firmware's security implementation. The researchers disassembled the firmware using Ghidra and discovered critical misconfigurations.

• Incorrect Security Descriptors: In many instances, the firmware specified the GATT characteristic property as 0x0400. While 0x04 correctly indicates "write without response," the trailing 00 (in the lower byte) explicitly signifies unauthenticated access. According to the MCU OEM's documentation, to enforce authenticated write access, this value should be 0x0408 or another bitmask indicating authentication requirements. The developers simply used the insecure default.
• Flawed Bonded State Logic: In other firmwares, a variable, often named var2, was intended to indicate whether the device was securely "bonded" (paired) with a client. However, this variable was consistently set to 0 (unbonded) or its check was bypassed, allowing write operations regardless of the pairing state.

These distinct root causes, leading to the same unauthenticated pre-pairing GATT write outcome, highlight that this is a systemic flaw, a "class of vulnerability," rather than an isolated bug in a single product. It points to a broader trend of inadequate security practices in the development of budget smartwatch firmware, often stemming from using default, insecure configurations of underlying BLE chips and a lack of proper security review.

Demo / Proof of Concept

▶ Watch: Smartwatch as server in Bluetooth client-server architecture (8:00)

The presentation commenced with a compelling demonstration of the Unauthenticated Pre-Pairing GATT Write Vulnerability in action. Arjun V, one of the speakers, showcased a video recorded while flying to Nullcon. In this video, he used a custom-built application to connect to his co-speaker's smartwatch without any prior authentication or pairing. The application then successfully sent a fake incoming call notification to the watch, displaying "911 emergency" as the caller ID. This live, real-world scenario immediately highlighted the practical impact and ease of exploitation of the vulnerability.

Following this initial demonstration, Gurjot Singh elaborated on the capabilities of the custom application developed by the Innspark Solutions team. The application was designed to automate the process of discovering vulnerable smartwatches and sending various types of malicious payloads. The presentation included screenshots and short video clips showcasing the application's ability to trigger different attacks on three distinct smartwatches from different vendors.

These demonstrations included:

• Custom Call Notifications: Showing how the application could make a watch display any desired caller ID, mimicking a legitimate incoming call.
• Custom Text Notifications: Illustrating the ability to send arbitrary text messages that appear as notifications from popular applications like Instagram or WhatsApp, directly to the watch screen.
• Watch Reset: A demonstration of remotely triggering a factory reset on a vulnerable device.
• "Find My Device" Activation: Showing how the application could force a watch to vibrate and sound an alarm, even if it was in silent mode, to disrupt the wearer.

The ease with which the custom application could scan for vulnerable devices and execute these commands underscored the severity of the flaw. The speakers emphasized that "finding devices is not that difficult... devices tell you to connect, right?" This highlighted that the attack requires only physical proximity and a basic understanding of the exploited GATT characteristics and payload structure, which their application conveniently automated. The PoC effectively translated the complex technical findings into tangible, impactful scenarios, demonstrating that this is not a theoretical vulnerability but a readily exploitable threat.

Defensive Implications

▶ Watch: The 'twist': Understanding handle functions is crucial (10:00)

The Unauthenticated Pre-Pairing GATT Write Vulnerability carries significant defensive implications for both end-users and, more critically, for smartwatch manufacturers and developers.

For users of smartwatches, particularly those on the budget end of the market, the primary implication is a heightened awareness of the security posture of their devices. Users should understand that simply "connecting" to a smartwatch via Bluetooth does not necessarily imply a secure, paired, and encrypted connection. Any unexpected notifications, calls, or device behaviors (like sudden resets or "Find My Device" activations) should be treated with suspicion, as they could be the result of an unauthenticated attack. While users cannot directly patch their device's firmware, choosing reputable brands that prioritize security and frequently update their software can mitigate some risks.

The onus, however, falls predominantly on smartwatch manufacturers and firmware developers. The discovery of this class of vulnerability highlights systemic failures in BLE security implementation:

1. Enforce Authentication for All Write Operations: The most critical defensive measure is to ensure that all GATT characteristic write operations, especially those that can trigger actions or modify device state, require prior authentication and secure pairing. This means correctly configuring GATT properties to disallow unauthenticated writes. Instead of using 0x0400 (write without response, unauthenticated), developers must use properties like 0x0408 (write without response, authenticated) or similar, depending on the specific Bluetooth Core Specification version and desired security level.
2. Implement Security Manager Protocol (SMP): Manufacturers must properly implement the Security Manager Protocol (SMP), which is designed to manage pairing and key distribution, providing secure authenticated and encrypted connections. High-end smartwatches, such as Apple Watches, already implement robust SMP and block pre-pairing write access, demonstrating that this is a solvable problem.
3. Validate Bonded State: Firmware should rigorously check the "bonded" or "paired" state of a connected device before allowing any sensitive write operations. The identified flaw where a var2 variable was incorrectly set or bypassed must be corrected.
4. Avoid Default Insecure Configurations: Developers should not rely on the default configurations of BLE chip OEMs, as these often prioritize ease of use or basic functionality over security. A thorough security review of the chip's default settings and the custom firmware implementation is essential.
5. Encrypt All Sensitive Communications: While the vulnerability specifically targets write operations, the observation that much of the BLE communication occurs in plain text underscores the need for end-to-end encryption for all sensitive data transfers, even after pairing.
6. Supply Chain Security: Given that many vulnerable devices originate from budget manufacturers, there's a broader issue of security within the IoT supply chain. Manufacturers need to ensure that their component providers (e.g., BLE chip vendors) and their own development teams adhere to security best practices.

The societal implications are also significant. The ability to send widespread fake notifications or trigger disruptions could be leveraged in real-world scenarios, such as creating panic in crowded places (e.g., a cinema hall or a conference) by broadcasting fake disaster warnings, or even for targeted harassment. This vulnerability exploits human trust and attention, making it a powerful tool for social engineering and psychological manipulation. Addressing this class of vulnerability is crucial not only for individual device security but for maintaining trust in the burgeoning IoT ecosystem.

Key Takeaways

• Widespread Unauthenticated Access: Many budget smartwatches suffer from an Unauthenticated Pre-Pairing GATT Write Vulnerability, allowing attackers to interact with devices without secure pairing.
• Data Exposure and Manipulation: This flaw enables adversaries to read sensitive user data (heart rate, steps, sleep cycles) and, more critically, to write arbitrary commands, triggering fake calls, custom notifications, alarms, device resets, and "Find My Device" functionalities.
• Systemic Firmware Flaws: The root cause is often traced to insecure firmware implementations, including incorrect GATT property configurations (e.g., 0x0400 for unauthenticated writes) and faulty logic for checking device "bonded" states.
• Class of Vulnerability: This is not an isolated bug but a widespread "class of vulnerability" affecting numerous OEMs and firmwares, stemming from common, insecure development practices and reliance on insecure default BLE chip configurations.
• Significant Impact: Beyond individual device compromise, the vulnerability facilitates social engineering, trust erosion, and even physical disruption (e.g., "DDoS attacks" via battery drain/overheating, or widespread panic in public settings).
• Urgent Call for Robust Security: Manufacturers must prioritize implementing strong authentication and pairing mechanisms (SMP) before allowing any sensitive GATT write access, encrypting communications, and thoroughly reviewing firmware for insecure defaults.

About the Speaker(s)

The talk was presented by a team from Innspark Solutions:

• Gurjot Singh is a Security Researcher at Innspark Solutions. He was the primary speaker detailing the technical aspects of the vulnerability, its discovery process, and the reverse engineering efforts.
• Vipin Venu is a Senior Security Researcher at Innspark Solutions. He contributed to the discussion, particularly on the broader impact and defensive implications of the vulnerability.
• Arjun V is also part of the Innspark Solutions team and served as a co-speaker, introducing the topic and demonstrating the initial proof-of-concept video. He humorously noted his preference for analog watches, given the security exploits his colleagues uncover.