One of the libraries that I work on as part of OpenYou is
libfitbit, an access library for the FitBit pedometer
device.
It's basically a tiny accelerometer that clips to clothing to work as
a pedometer. It can also communicate wirelessly with its base station,
so that whenever a user walks by their computer and assuming they have
the Fitbit server software running, it'll automatically sync. The data
is stored on fitbit's website (shown above, lower right), where they
give you a nicely designed interface to see it, compare to friends,
and for a fee, have it analyzed by on staff trainers.
The hardware itself is very well designed. In 3 months of having the
device, I have yet to lose it (which is a small miracle), and it stays
clipped to clothing. The battery seems to last pretty much forever,
and the display is nice and crisp. The wireless has quite a range too,
picking up the device while I'm in other rooms.
The problems began when it didn't have drivers for syncing via
linux. Doing what it is I do, I figured I'd whip some up real
quick. This is where things when horribly, horribly wrong.
(For those that want to skip the story telling version of this and
just read the hard technical details, the
reverse engineering document is available on the repo, which has
all of the gritty technical details.)
The first thing I normally do when looking at new hardware is to check
out what I can about the software that ships with the device. There's
usually some logs around to help out. In fitbit's case... Well, the
logs are beyond helpful. They're scary. Here's a chunk from the
beginning of one of them.
01/28 23:31:55 Sending 4357 bytes of HTML to UI...
01/28 23:31:55 Processing request...
01/28 23:31:55 Waiting for minimum display time to elapse [1000ms]...
01/28 23:31:56 Waiting for form input...
01/28 23:31:57 [POWER EVENT] POWER STATUS CHANGE
01/28 23:32:04 [POWER EVENT] POWER STATUS CHANGE
01/28 23:32:14 UI [\.\pipe\Fitbit|kyle]: F
01/28 23:32:14 Processing action 'form'...
01/28 23:32:14 Received form input: email=[USER UNENCRYPTED EMAIL HERE]&password=[USER UNENCRYPTED PASSWORD HERE]&[other stuff]
01/28 23:32:14 Connecting [2]: POST to http://client.fitbit.com:80/device/tracker/pairing/signupHandler with data: email=[USER UNENCRYPTED EMAIL HERE]&password=[USER UNENCRYPTED PASSWORD HERE]&[other stuff]
01/28 23:32:14 Processing action 'http'...
01/28 23:32:14 Received HTTP response:
Yes, that's a user's email and password, unchanged and in clear text,
being flung over to their website via a pure http connection. This
step is also logged to the user's hard drive in a clear text file,
that is world readable.
This is bad.
The log goes on to verbosely record everything the fitbit says to the
website and vice versa. Fitbit sends all commands from their website
to the device, meaning they never have to upgrade their client
software, though firmware does have to be updated on the device every
so often. This policy is actually an interesting move. It made it way
easier for me to replicate how their client works for libfitbit, but
also keeps them from having to update their client when they make new
firmware.
To continue the fun, we move onto the promiscuous base stations. As a
convenience measure, any Fitbit tracker device (the thing you wear,
lower left in the picture above) will sync with any base station (the
part that connects to the computer, upper portion of picture
above). This means that if you're at a friend's place who has a
fitbit, the device will sync, without you having to do anything.
However, in order for the information to go from the user's fitbit
that's attached to them, to their account on the website, there has
to be some identifier on the device to let the website know who's
who. The tracker serial number does this. The first thing the website
asks for is the tracker number, and it then returns the user ID
associated with the tracker number. The user ID is what's used to
access a profile page, i.e.
http://www.fitbit.com/user/[user_id]
After knowing the combination of user id and tracker serial, anyone can be
basically authenticated and can send data to the site under the
account the tracker is bonded to.
This is an incredibly easy system to spoof. I could walk around with a
netbook and a fitbit base station in my backpack, gather serial
numbers at a public meetup, then have all the account information I
wanted.
Which brings us to the crux of the problem, and the reason I believe
the software is the way it is currently: Why would I do that?
It's just steps, after all. Who cares?
This is one of the things I'm seeing more and more when reverse
engineering medical hardware. It's not financial information, it's not
important health information, so why should it be locked down?
While this may seem like a rather light issue (other than the password
in the clear thing, which is 100% inexcusable), with common thought
being 'woo, someone stole my steps!', the implications can get pretty
staggering depending on how far out we want to cast the timeline,
especially in relation to device popularity.
First off, one of the major marketing points of QS hardware right
now seems to be synergy between information stores. Fitbit can now
instantly upload a user's data to DailyBurn, Google Health, and other
sites that the user links to it. This is considered a value-add for
health hardware, since users may have been keeping information
elsewhere before whatever device they're using existed. This also
means that if I have write access to one account via the methods
described above, I have write access to many accounts via account
bonding across sites, assume the user has created those bonds.
To crank the paranoia level another notch, the amount of device
companies I've talked to that are also looking at linking to health
insurance companies really makes this a horror story. If someone
maliciously gets into a user's health device account that then links
into health insurance/health care, who knows what havoc could be
wreaked.
Finally, there's lots of metadata that can be lifted from these
devices as more and more of them go wireless. If you're wearing
something that uniquely identifies you, that means all someone needs
is a base station to tell who the user was, where they were, and
when. In the days of geolocative apps and constant check-ins, there
comes the question of whether people might want that implicitly, but
this seems like it should be opt-in versus opt-out (or in this case,
no opting at all).
So, yeah. Fitbit is a great design, and completely insecure, though
not unfixably so. Everything I've talked about above could be easily
fixed. Flip on https for transfers (but please don't encrypt
everything, as I'd like my drivers to keep working), don't log
everything ever to disk, allow users to set whether they want base
sync promiscuity or not. It's not that bad. However, the fact that
this was even seemed like a good idea in the first place is a bad
precedent for health hardware to come.
And all I wanted was a pepsi some linux drivers.
