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
Threaded  |  Newest First  |  Oldest First
Mobile Banking Malware Up 50% in First Half of 2019
Kelly Sheridan, Staff Editor, Dark Reading,  1/17/2020
7 Tips for Infosec Pros Considering A Lateral Career Move
Kelly Sheridan, Staff Editor, Dark Reading,  1/21/2020
For Mismanaged SOCs, The Price Is Not Right
Kelly Sheridan, Staff Editor, Dark Reading,  1/22/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment:   It's a PEN test of our cloud security.
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
How Enterprises are Attacking the Cybersecurity Problem
How Enterprises are Attacking the Cybersecurity Problem
Organizations have invested in a sweeping array of security technologies to address challenges associated with the growing number of cybersecurity attacks. However, the complexity involved in managing these technologies is emerging as a major problem. Read this report to find out what your peers biggest security challenges are and the technologies they are using to address them.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-7220
PUBLISHED: 2020-01-23
HashiCorp Vault Enterprise 0.11.0 through 1.3.1 fails, in certain circumstances, to revoke dynamic secrets for a mount in a deleted namespace. Fixed in 1.3.2.
CVE-2019-15707
PUBLISHED: 2020-01-23
An improper access control vulnerability in FortiMail admin webUI 6.2.0, 6.0.0 to 6.0.6, 5.4.10 and below may allow administrators to perform system backup config download they should not be authorized for.
CVE-2019-15712
PUBLISHED: 2020-01-23
An improper access control vulnerability in FortiMail admin webUI 6.2.0, 6.0.0 to 6.0.6, 5.4.10 and below may allow administrators to access web console they should not be authorized for.
CVE-2019-16512
PUBLISHED: 2020-01-23
An issue was discovered in ConnectWise Control (formerly known as ScreenConnect) 19.3.25270.7185. There is stored XSS in the Appearance modifier.
CVE-2019-16513
PUBLISHED: 2020-01-23
An issue was discovered in ConnectWise Control (formerly known as ScreenConnect) 19.3.25270.7185. CSRF can be used to send API requests.