GE has released a fix for a vulnerability in a library that’s used in several of its products deployed in critical infrastructure areas. The flaw in the HART Device Type Manager library could allow an attacker to crash affected applications or run arbitrary code. The vulnerability in the DTM library affects four of GE’s products, as […]
This story began a few months ago when I got a popular brand of fitness bracelet. As this is a wearable device I installed Android Wear app, an application developed especially for wearable devices. This application easily connects to the fitness band.
However, there was something odd: the program could connect to a Nike+ Fuel Band SE, but my bracelet was another brand! It wasn't long before I realized my colleague had a Nike wristband – and he didn't even notice I had connected to his device.
After that I decided to do some research and find out how secure my wristband was.
Smart bracelets: communication with a smartphone
Today's market offers a lot of wristbands from other manufacturers. KSN provides the following statistics about the installation of Android-based applications to work with popular fitness trackers on mobile devices (the statistical data was obtained from KSN users who freely agreed to the transfer of this data).
The installation of Android-based applications designed to work with fitness trackers from different manufactures
Although this statistic demonstrates the popularity of Android applications (we cannot guarantee that the appropriate devices have users), to some extent it reflects the situation with the popularity of wearable devices.
To communicate with the smartphone most of these fitness bands use Bluetooth LE technology (also known as Bluetooth Smart). For us, this means that the devices connect in a different way from regular Bluetooth. There is no pairing password because most wristbands do not have a screen and/or a keyboard.
In some cases you can connect to a wearable device without the owner even knowing
These wristbands use a GATT (Generic Attribute Profile) which means that every wearable device includes a set of services, each of which has a set of characteristics. Each characteristic contains a byte buffer and a list of descriptors, and each descriptor contains a value – a byte buffer.
In order to demonstrate this, I used some ready code from Android SDK, an example of an application that connects to Bluetooth LE devices. I did not have to write a single new line of code; I simply opened the existing project in Android Studio and pressed Start.
The screenshot above shows the result of my attempt to connect my fitness bracelet with the help of this application. Here we see the services and their characteristics. However, it is not easy to obtain data for my bracelet from the characteristics - it requires authentication in addition to the connection. In the case of some other devices I could read the data from the characteristics and their descriptors. This was probably the user data.
So, using the example of the application from Android SDK I could connect to some devices. After that I have developed my own application which automatically searched for the Bluetooth LE devices attempting to connect to them and get their list of services.
Using this application I performed several scans.
Over two hours on the Moscow undeground subway system I could have connected to 19 devices: 11 FitBit and 8 Jawbone.
Over an hour in a gym in Bellevue, WA, USA I was able to connect to 25 devices: 20 Fitbit, and one each from Nike, Jawbone, Microsoft, Polar and Quans.
Over two hours at SAS2015 in Cancun, Mexico, I was able to connect to 10 fitness trackers: 3 Jawbone and 7 FitBit.
From just six hours of scanning I was able to connect to 54 devices despite two serious restrictions:
Although the spec suggests the maximum distance for connections is 50 meters, in reality it's rarely possible to connect to a device more than 6m away.
It seems that it is not possible to connect to a device that already has a connection to another phone. Thus if your wristband is connected to your phone, no one else can connect to it; it should not even be seen during scanning.
The second restriction should mean that when the wristband is connected to a smartphone, it cannot be attacked. This is not true though. And here is an example: while scanning with my app I was able to block the communication between my bracelet and its official application, even though they were connected.
It could be that the devices I found had never connected to a phone before or that the wristband was not connected to a smartphone while I was scanning (perhaps the Bluetooth on the phone was disabled). However it could also be that a pre-connected device was still available for connection despite the supposed restriction. Whatever the reason, potential fraudsters have ample opportunity to connect to fitness trackers.
However, in most cases, authentication is required in addition to the connection in order to gain access to the user data. Let's see how my bracelet's authentication process works.
My bracelet's authentication
To authenticate the bracelet on a smartphone the official application uses one of the four available services on the wristband. Each characteristic of each service is flagged with 'CharacteristicNotification' - this is how the app informs the wristband that it wants notifications of any change in this characteristic. Then the application gets a list of descriptors for each characteristic and sets the 'ENABLE_NOTIFICATION_VALUE' flag to inform the wristband that it wants notifications of any change in each descriptor.
After that one of the characteristics changes its value - the byte buffer. The application reads this buffer from the wristband: the 200f1f header and the byte array - let's call it authBytes.
The application creates a new array. Its first part is a constant array which is contained in the application and begins with 6dc351fd44; the second part of the new array is authBytes. The application receives the MD5 hash from the new array and sends it back to the device in the following structure:
The application then sends to the device yet another array also found in this application.
After this wristband starts to vibrate and the user just needs to press the button to complete the authentication process.
With the official application the authentication process takes about 15 seconds. I have developed an application that requires only 4 seconds to make the wristband vibrate.
It is not difficult to make the user press a single button on the wristband. You just need to be persistent. You can keep trying authentication process over and over until the user finally presses the button or moves out of range.
From just six hours of scanning I was able to connect to 54 devices despite two serious restrictions
After authentication is completed, the data on my bracelet can be accessed. Right now, wearable fitness devices do not contain much information. Typically, they have the number of steps, the phases of sleep, the pulse for the last hour or so. Approximately once an hour the app transfers this information from the wristband to the cloud.
After the authentication, it is easy to execute commands on the device. For example, to change the time you should send to the device the byte array beginning with f0020c and then the date in the form YYYY MM DD DW HH MM SS MSMSMSMS.
Things are even easier with the other fitness trackers: for some of them, part of the data is available immediately after the connection, while the application code for Nike is not even obfuscated and can be easy read (the results of one study can be found here).
The results of my research show that in some cases you can connect to a wearable device without the owner even knowing.
By hacking the bracelet I have the fraudster cannot get access to all user data as this is not stored on the wristband or in the phone - the official application regularly transfers information from the wristband to the cloud.
Fitness trackers are becoming more popular and offer a wider range of functions. Perhaps in the near future they will contain more sensors and hence much more user information, often medical data. However the creators of these devices seem to think very little about their safety.
Just imagine - if a wristband with the pulse sensor is hacked, store owners could look at your pulse rate while you are looking at the prices in the store. It might also become possible to find out how people react to advertising. Moreover, a hacked wearable with pulse sensor could be used as a lie detector.
The fraudster could take control of your wristband, make it vibrate constantly and demand money to make it stop
Of course, there are more harmful actions that are more likely. For example, by using a Trojan-Ransom the fraudster could take control of your wristband, make it vibrate constantly and demand money to make it stop.
We reported our findings to my bracelet's vendor. The company's response defines the findings as a UX Bug and not a security issue. For ethical and security reasons we are not disclosing the name and the model of the bracelet this time. If you're worried about the possible consequences of cybercriminals exploiting the security issues we discovered, don't hesitate to contact the vendor of your fitness bracelet and ask if your product is affected by the method described in the article.
We also hope that this article will be helpful not only for users but also for vendors of the bracelets to make these devices safer from the IT Security perspective.
A group of technology companies, non-profits and privacy and human rights organizations have sent a letter to President Barack Obama, the director of national intelligence and a wide range of Congressional leaders, calling for an end to the bulk collection of phone metadata under Section 215 of the USA PATRIOT Act. The letter, sent by […]
Google is continuing to refine its Safe Browsing API and now is giving users warnings about not just malicious software on sites they’re attempting to visit, but also about unwanted software. Google’s Safe Browsing API is designed to help protect users from a variety of threats on pages across the Internet. The functionality is built into […]
A security researcher says there is a bug in the Instagram API that could enable an attacker to post a message with a link to a page he controls that hosts a malicious file, but when the user downloads the file it will appear to come from a legitimate Instagram domain, leading the victim to trust […]
Google security engineers, investigating fraudulent certificates issued for several of the company’s domains, discovered that a Chinese certificate authority was using an intermediate CA, MCS Holdings, that issued the unauthorized Google certificates, and could have issued certificates for virtually any domain. Google’s engineers were able to block the fraudulent certificates in the company’s Chrome browser by pushing an […]
Cisco is warning customers about several vulnerabilities in some of its IP phones that can allow an attacker to listen in on users’ conversations. The bug affects the Cisco SPA 300 and 500 Series IP phones. Cisco had confirmed the vulnerabilities, which were discovered by Chris Watts, a researcher at Tech Analysis in Australia, and is […]