Reverse Engineering the Nike+ FuelBand's Communications Protocol
An anonymous reader writes: Security researcher Simone Margaritelli has reverse engineered the Bluetooth low-energy communications protocol for his Nike+ FuelBand SE, a wrist-worn activity tracker. He learned some disturbing facts: "The authentication system is vulnerable, anyone could connect to your device. The protocol supports direct reading and writing of the device memory, up to 65K of contents. The protocol supports commands that are not supposed to be implemented in a production release (bootloader mode, device self test, etc)." His post explains in detail how he managed this, and how Nike put effort into creating an authentication system, but then completely undermined it by using a hard-coded token. Margaritelli even provides a command list for the device, which can do things like grab an event log, upload a bitmap for the screen, and even reset it.
Now we know how many Calories he burned. we are doomed...
Developer: That's insecure.
Phil Knight: Just do it.
Are people going to reverse-engineer these things so that when they're worn into secure facilities, they inject-attack systems in the secure facility?
Are they going to act as a vector to attack other Bluetooth Low Energy capable security systems?
I simply want to know what kind of maliciousness can be achieved through exploiting bugs in a very, very special-purpose device.
Do not look into laser with remaining eye.
from a social standpoint these devices are near and helpful. From a FOSS standpoint these devices are intrusive and treat their users like cattle. Check out Fitbit for example, the largest provider of digital harvesting/tracking hardware. the privacy policy insists they sell de-identified data (because metadata is a dirty word these days) to third parties. So if you're wondering why health insurance companies are pushing biometric competitions at the workplace using subsidized devices its because your health is not their primary concern. Determining an accurate insurance rate for a component of workers that are at heightened risk for diabetes, heart attack, and alzheimers is what they care about. Your corporation in turn cares about your health, and might reward you with water bottles or gift cards to sporting goods stores that, in turn, might turn into a newer fitbit/fuel.
the protocol used to affect data and function of the device is trivial, Galileo and libfitbit hacked this a few years ago. The real problem is your biometric data which is transferred across the device in an AES/md5 header encrypted blob. This violates countless freedoms of the application, starting with 0. The key to decrypt this data doesnt exist for you, and hence you're tethered to a website and a product that if it were ever usurped by say, fitness applications on your phone, would go bankrupt, shutter its doors, and leave you with a nice chunk of plastic that showed numbers and belched motivational platitudes. the real work in these devices should be decrypting the collected data without the use of the companies respective servers and web resources.
Good people go to bed earlier.
In what way should anybody be surprised that a wearable, wireless device has implemented security in a completely incompetent way?
These are products which are intended to be cool, shiny, and pretty ... but secure? Not even a little.
I continue to be unsurprised by this crap, and I continue fairly firm in my indifference to owning any of this stuff ... and the same goes the for "Interweb of Stuff"; I assume that out of the gate it's going to be insecure and stupid.
Unless companies have actual legal liability for shit security, you'll continue to see shit security.
So just don't buy it if you value security or privacy -- because they're all pretty much designed to upload your information to analytics companies anyway.
Lost at C:>. Found at C.
As I understand the analysis, this exploit could be used to turn Fuelbands into data mules. It could also let someone temporarily brick all the Fuelbands within range (could be fun at the start of a marathon or at the gym).
>> Cmd_Bootloader: Set the device to bootloader mode ( basically it locks down the device, the official app won't work either ... only resetting it with the usb cable will unlock it ).
>> Cmd_SampleStore: Use the device memory to store a custom object (!!!)
This whole IoT concept is treating security as a joke. In the first of wave computing, the mini-computers (particularly Windows) treated security as an after-thought. That created the virus-laden era of the 1990s and early 2000s. The second wave, the "new" smart phone, learned the lessons, and use sandboxes, walled garden, permissions, encryption, tokenization, etc. pervasively. It's not fool-proof but at least the door is locked. Now we are approaching the third wave, the Internet of Things, and manufacturers think these devices are so personal that no security is needed. What do they say about people who don't learn any history?