Last week, we had the privilege to participate in and present at the 15th edition of CanSecWest in beautiful Vancouver, BC, along with its famous accompaniment, the ever famous Pwn2Own competition. Yes, once again all major browsers were hacked, but they were not alone! BIOS and UEFI, 4G modems, fingerprints, credentials, virtual machines, and operating systems were among the victim systems successfully hacked by our fellow presenters.
The event gathers a very technical audience with a shared interest in the most recent attacks and the presenters delivered with a variety of demos that showcased their intended vulnerabilities beautifully and thus reinforced the conclusion that digital voodoo can turn obscure and seemingly innocuous vulnerabilities into mind-numbingly cunning attacks.
One of the most discussed presentations, and certainly one of our favorites, showcased the power of BIOS and UEFI hacking: two guys, Corey Kallenberg and Xeno Kovah of Legbacore, armed with $2,000 and 4 weeks of hard work were able to show how a long list of vendor BIOSes were not only vulnerable but could successfully be loaded with LightEater, an SMM implant capable of pilfering sensitive information from Tails OS and even exfiltrating that information in such a way as to bypass the OS entirely. We clearly agree with their conclusion, it´s time to start taking a harder look at firmware!
Firmware insecurity: absence of evidence is not evidence of absence
One of the very possible attack is the well-known 'evil maid' or the 'border guard' approach: someone with physical access to your computer can just plug a small device (see below) and successfully reflash your system's BIOS, rewriting it with malicious code, without so much as booting up the system.
Press a button and in a few seconds the handy green light will indicate the BIOS is p0wned
Another very interesting presentation by Jan "starbug" Krissler showed how high resolution photos could bypass biometric authentication. Pictures acquired through high-resolution cameras from a safe distance amounted to the successful theft of fingerprints, faces, and irises used by current biometric systems for authentication. The distance can even be extended through the use of infrared imagery! We spent the talk imagining the breach possibilities as an increasing number of ATMs nowadays rely on biometric input.
Please authenticate access to your bank account using a password you can never change: your fingerprint
We also saw presentations on MacOS DLL (dylib) hijacking, userland exploits on iOS 8, attacks using Windows PowerShell, and even the installation of a bootkit in a 4G modem by simply sending an SMS! All sandwiched between explanations of the work of the ever fascinating Google Project Zero Team. In one of these, Chris Evans walked the audience through how a 'simple' crash caused by a call with a negative length became an exploit on Adobe Flash Player.
Our own presentation was a walkthrough of the misuse of whitelisted tools to further all kinds of attacks, from APTs and Targeted attacks to banking trojans and ransomware. This ongoing project is intended to highlight the faulty foundations of the whitelisting approach to security and how whitelisting alone simply won't protect you, from advanced and intermediary attackers alike! Stay tuned for a post on our findings.
In the end, we expanded our view as to the true breadth of vulnerable software and hardware. on which we depend daily. Security is a truly elusive state in an ecosystem composed of interwoven, dependent systems, each responding to the diverging priorities of a developer, an administrator, a user, and, of course, an attacker as well. The role of the security researcher that lives and breathes attack vectors and obscure vulnerabilities in search of the right digital voodoo has never been more important. And we can't help but echo the sentiments of Dragos Ruiu and our own Eugene Kaspersky in thanking CanSecWest for bringing all these researchers under one roof and one banner to share that digital voodoo and successfully stave off the balkanization of our industry just a while longer.
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 knowingTweet
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.Scanning
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:
- Header (201210051f)
- Verification byte
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 restrictionsTweet
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).Conclusion
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 stopTweet
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.