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
Twitter
Google+
LinkedIn
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 senior e-threat analyst for Bitdefender, with a strong background in security and technology. Reporting on global trends and developments in computer security, he writes about malware outbreaks and security incidents while coordinating with technical and ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
SOC 2s & Third-Party Assessments: How to Prevent Them from Being Used in a Data Breach Lawsuit
Beth Burgin Waller, Chair, Cybersecurity & Data Privacy Practice , Woods Rogers PLC,  12/5/2019
Navigating Security in the Cloud
Diya Jolly, Chief Product Officer, Okta,  12/4/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-19619
PUBLISHED: 2019-12-06
domain/section/markdown/markdown.go in Documize before 3.5.1 mishandles untrusted Markdown content. This was addressed by adding the bluemonday HTML sanitizer to defend against XSS.
CVE-2019-19616
PUBLISHED: 2019-12-06
An Insecure Direct Object Reference (IDOR) vulnerability in the Xtivia Web Time and Expense (WebTE) interface used for Microsoft Dynamics NAV before 2017 allows an attacker to download arbitrary files by specifying arbitrary values for the recId and filename parameters of the /Home/GetAttachment fun...
CVE-2019-19617
PUBLISHED: 2019-12-06
phpMyAdmin before 4.9.2 does not escape certain Git information, related to libraries/classes/Display/GitRevision.php and libraries/classes/Footer.php.
CVE-2012-1114
PUBLISHED: 2019-12-05
A Cross-Site Scripting (XSS) vulnerability exists in LDAP Account Manager (LAM) Pro 3.6 in the filter parameter to cmd.php in an export and exporter_id action. and the filteruid parameter to list.php.
CVE-2012-1115
PUBLISHED: 2019-12-05
A Cross-Site Scripting (XSS) vulnerability exists in LDAP Account Manager (LAM) Pro 3.6 in the export, add_value_form, and dn parameters to cmd.php.