Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

News & Commentary

12/9/2014
12:50 PM
Liviu Arsene
Liviu Arsene
Partner Perspectives
Connect Directly
LinkedIn
Twitter
RSS
50%
50%

Bitdefender Research Exposes Security Risks of Android Wearable Devices

In the rush to supply early adopters with trendy technology, security has been compromised.

In the wake of the recent smartwatch and smartband boom has come a surge in phone-paired devices that broadcast or receive personal user information.

Early adopters have been prompting companies to develop interconnected devices that perform once-onerous tasks, such as constantly checking your phone for notifications or messages, to make the transition to wearable technology more seamless and intuitive.

There’s nothing wrong with simpler and easier lives. But in the rush to supply early adopters with a new trendy gadget, security has been compromised in some cases. Every developing technology being pushed to market inevitably has drawbacks. Whether it’s a fashionable colored armband or some interesting functionality that most will never use, security concerns have probably been bumped further down the priority list.

Our own security researchers from Bitdefender have been testing the theory of whether the new generation of smartwatches poses any security risk to wearers. The information you have on your phone is extremely private -- hence the need to restrict access with PIN codes or passwords.

Watch Liviu discuss his team’s findings.

The Big Question
We embarked on a search to answer a question that too few have been asking: “How safe is the actual communication between your smartphone and your smartwatch?”

The answer was both surprising and somewhat expected, as experience has taught us that every new trending technology takes time to develop the right set of mechanisms that ward off tampering fingers and prying eyes.

All communication between Android devices and smartwatches is handed via Bluetooth. That’s pretty safe, as attackers need to be close to actually sniff traffic. But it does not mean the scenario is impossible.  

The security research team at Bitdefender has been investigating the way information is passed between smartwatches and the wearable apps on your smartphones to determine whether an attacker could peek at your text messages, Facebook conversations, or Hangout chats.

The proof-of-concept involved a set of tools, not uncommon to average security geeks, along with a Samsung Gear Live and a random Android device – in this case a Google Nexus 4 with Android L Preview.

At first glance, the findings were pretty consistent with our expectations. Bluetooth communication between smartwatch and Android device involved encrypted Bluetooth communication using six-digit PINs to obfuscate the broadcast and prevent any curious newbie from seeing entire conversations in plain text with a sniffing tool. Using available tools, this six-digit PIN can easily be brute-forced and used to decrypt the conversation between smartwatch and smartphone.

Further investigation into the obfuscation algorithm used was somewhat surprising as it was not all that difficult to brute-force the six-digit PIN and de-obfuscate the Wear communication protocol, revealing all sorts of information passed between the two devices.

A non-technical reader might skip ahead to the Implications section, as the next few paragraphs may be somewhat dry.

The Technical Tidbits
Four types of messages are encapsulated in the obfuscated communication between the smartwatch and Android device in a peer-to-peer manner:

  • ID Exchange – Every device sends an ID to the other device (smartwatch to Android device and vice-versa)
  • Control – Encapsulates Remote Procedure Calls affiliated to various actions. These RPCs are commonly used in inter-process communication between two devices sharing the same network, in this case Bluetooth pairing
  • Data – The contents of each notification and affiliated metadata
  • Asset Transfer – An asset is an object that can encapsulate large data such as photos

For the purposes of this article, we won’t dwell on the first type of data packets, as they’re mostly used to establish each device’s identity. The asset-transfer packets are also of little importance, as sending photos, audio files, or movies between an Android device and a smartwatch is not as interesting as being able to read actual messages and conversations. Asset transfer is usually used for sending large amounts of data.

The interesting parts lie in the control and data packets, as their use seems to involve the actual communication between on-device applications and the smartwatch. The Wear API takes care of this communication using methods similar to “send (tag, path, object)” formatting.

Here’s a breakdown of the actual variables in the control and data packets:

  • $counter_bytes – a type of counter for the control communication
  • $header_length = 31(0x1F) – an ASCII Unit Separator used for separating fields in text; 31 is the length of the $header
  • $header = com.google.android.wearable.app – name of the Android Wear app
  • $misc_id_length = 40(0x28) – an ASCII representation for Open Parenthesis; 40 is the length of the $misc_id
  • $misc_id = a197f9212f2fed64f0ff9c2a4edf24b9c8801c8c – could be a hash function that could differ from one device to another; not exactly sure of its purpose, but we managed to discern this value in our investigation
  • $tag_length and $tag, respectively $path_length and $path – affiliated to the Wear API; these are the common variables in the communication method described above used to separate and identity RPC calls
  • $data_map_length and $data_map – contains the actual sent data (this is the juicy part)

Mitigation
Mitigation could involve using Near Field Communication (NFC) to send a PIN code to the smartwatch, or using a pass-phrase during pairing. The downside to NFC is that not all devices – mobile devices or smartwatches – have NFC capabilities. Using pass-phrases is also tedious, as it involves manually typing a possibly randomly generated string onto the wearable smartwatch.

Or we could supersede the entire Bluetooth encryption between Android device and smartwatch and use a secondary layer of encryption at the application level. This, however, should be implemented either by Google or OEMs, and it might have an impact on the smartwatch’s battery lifetime, as encryption involves heavy computations.

Implications
The obfuscation method of the Wear API used when communicating between smartwatch and Android device was mostly debunked, although the currently used method wasn’t fully exposed. However, we did manage to see plain-text conversations between apps, such as Facebook Messenger, Google Hangouts, and even SMS messages when sent from the Android device to the smartwatch.

We’re pretty sure that, if someone were to do more in-depth research into how the Wear obfuscation actually works, we would soon end up with some fascinating exploit packs. Weaponizing this is only a matter of how much someone would have to gain from reading your conversation, even in close proximity.

The Internet of Things is a truly marvelous concept, but only as long as we do not overlook security implications. These security risks could easily be fixed with stronger or better methods for ensuring the safety of the entire communication.

With quite a few wearables out there that rely on Bluetooth pairing to receive text messages and to engage in various forms of chatting, security issues should be treated with the utmost seriousness.

Over-the-air Bluetooth encryption is handled by the baseband co-processor built into most Android devices. Previous research has proven that this baseband co-processor can be tampered with via over-the-air updates.

Our research involved analyzing the raw traffic before it is sent over the air via the baseband co-processor. This means that relying only on baseband co-processors to handle the encryption is not a fool-proof security mechanism. It also raises the question of how easy it is for someone to update the firmware on the baseband co-processor once a vulnerability is disclosed.

Liviu Arsene is a Global Cybersecurity Researcher for Bitdefender, with a strong background in security and technology. Researching global trends and developments in cybersecurity, he focuses on advanced persistent threats and security incidents while assessing their impact ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Edge-DRsplash-10-edge-articles
I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
News
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
Commentary
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-22392
PUBLISHED: 2021-08-05
Cross Site Scripting (XSS) vulnerability exists in Subrion CMS 4.2.2 when adding a blog and then editing an image file.
CVE-2021-3591
PUBLISHED: 2021-08-05
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Notes: none.
CVE-2021-3642
PUBLISHED: 2021-08-05
A flaw was found in Wildfly Elytron where ScramServer may be susceptible to Timing Attack if enabled. The highest threat of this vulnerability is confidentiality. This flaw affectes Wildfly Elytron versions prior to 1.10.14.Final, prior to 1.15.5.Final and prior to 1.16.1.Final.
CVE-2021-3655
PUBLISHED: 2021-08-05
A vulnerability was found in the Linux kernel in versions before v5.14-rc1. Missing size validations on inbound SCTP packets may allow the kernel to read uninitialized memory.
CVE-2021-32003
PUBLISHED: 2021-08-05
Unprotected Transport of Credentials vulnerability in SiteManager provisioning service allows local attacker to capture credentials if the service is used after provisioning. This issue affects: Secomea SiteManager All versions prior to 9.5 on Hardware.