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).
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.
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:
From just six hours of scanning I was able to connect to 54 devices despite two serious restrictions:
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.
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. You have to understand that your fitness is someone's business, but nothing personal.
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. 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.