引言
研究背景
越来越多的智能设备和各种传感器开始进入大众的生活，但是不得不承认这些智能设备会跟踪你的健康和健身信息，所以这些设备的安全和隐私问题变得尤为重要。
更糟糕的是，一些像Fitbit这样的智能设备公司并不会给用户提供任何的数据控制权限，将用户的数据全部上传到他们的私有云上，如果用户想获得更加详细的健康分析，就要去购买。用户对于这些设备收集了哪些信息一无所知。而且近年来Fitbit已经爆出过非常多的安全漏洞，有些可以导致用户的信息泄露，有些是设备和web服务器通信上的严重漏洞，包括他设备自身也有很多问题。
这些安全问题在这些健康追踪设备上并不少见，而且是当前智能设备普遍存在的问题。
研究目标
这个项目的主要研究目标是了解Fitbit在上面这些漏洞爆出之后在他们的安全方面做了哪些改进。同时，在消费者穿戴一台智能设备之前，他们有权利知道这个设备收集了哪些信息并且如何能看到。所以这个项目还会研究Fitbit收集了哪些数据、他是怎样收集的以及这些数据是如何在设备和服务器之间往来的。
一共有以下几个步骤：
确认Fitbit从用户那里收集了哪些数据
看Fitbit给用户展示了哪些数据，和他们收集的数据作对比
恢复他们从用户那里收集但是不展示的数据
绘制出和他们系统有关的可能存在的安全漏洞和隐私问题
相关工作
在我们开始着手这个项目之前，我们为此写了一个一般性的文献综述，来确定目前现有的工具和资源。我们在一个叫做“Hacks by Pete”的博客上找到了一些关于Fitbit设备同步数据格式的资料。在Fitbit One配对之后，该博客作者对他设备上的同步日志进行了分析。我们之前也从Fitbit Flex上抓到过类似的数据，虽然他的博客证实了我们的研究成果是正确的，但是除了这些并没有提供任何有用的信息。这主要是因为博客上缺乏相关文档，并且Fitbit已经更新了他们的软件对设备上的同步信息做了加密混淆。
另一个对于我们研究有帮助的是一个叫做 “伽利略”的开源项目，由一位德国开发人员创建，他编写了允许Fitbit设备同步到Linux操作系统的软件。此项目的开发人员已在同步数据的格式方面，以及Fitbit设备与手机应用或计算机应用程序之间的通信协议方面成果显著。特别是他们标出了不同Fitbit设备通信时不同的头字节，并提供了多种数据抓取的样本。虽然这些信息有助于我们了解抓取的Fitbit Flex设备的数据格式，但它并不能对数据进行解密。一位开发人员表示已经发现使用的加密方式是AES，但是并没有提供任何证据。总而言之，我们团队对于Fitbit采用哪种方法加密以及加密秘钥是如何生成和替换的没有任何线索。
除了上述的资源，我们发现了很多独立的项目在尝试分析Fitbit通信协议。对旧的Fitbit设备（2个已经停产）的研究似乎是相当成功的，而其他的并没有很好的成果。综上，老款的Fitbit（Fitbit Tracker)）由于缺乏加密或安全通信协议而遭受了严重的安全攻击，从那时起，Fitbit在他们的手环上（Fitbit Flex， One和Zip）和应用程序上开始更加重视安全，让用户更难以捕获他们没有权限看到的东西。
除了对于Fitbit设备的研究，我们也研究了蓝牙协议。先前的安全项目，作为麻省理工学院2012年秋季的6.858计算机系统安全课程的一部分完成了，其中研究了蓝牙协议中的漏洞。这对于了解蓝牙通信是一个非常有用的成果，而且能够最大限度地发挥我们所购买的Ubertooth设备的作用。
系统概览
由于会穿戴Fitbit手环一整天。为了实现这种要求，Fitbit手环会将动态数据缓存在本地。当用户使用iOS或者Android app进行数据同步时，app会将手环里的数据发送给Fitbit-operated服务器存储。所有的用户健身数据不会保留在用户的手机或者手环里，而都是从Fitbit的云服务上获得的。
图一：Fibit系统组件，我们将攻击面划分为五个区域：(a)，(b)，(c)，(d)，(e)
Fitbit设备和智能手机或个人电脑之间的同步是通过蓝牙进行的。它使用的是BTLE （低功耗蓝牙）协议。智能手机或个人电脑和Fitbit云服务之间同步是在互联网上加密传输的。
在图1中，我们将Fitbit系统集成组件划分成五个分析区域。下文将按照这些部分依次进行分析。第4节介绍Fitbit Flex设备硬件的分析（a）。第5节介绍Fitbit Flex和Nexus 5的蓝牙通讯分析（b）。第6节是Fitbit Android应用程序的分析（c），第7节是Fitbit设备和Fitbit Web服务之间的网络通信分析（d）。我们将Fitbit API和Web服务分析作为未来的工作放在第8节（e）。
硬件设备分析
图二：这个是Fitbit主板正面。红色是主CPU，橙色是BTLE芯片，蓝色是一个充电器，黄色的芯片不太清楚
根据iFixit提供的对Fitbit的完美拆解，主板上的主芯片是ARM cortex处理器STMicroelectronics 32L151C6。对芯片的进一步研究显示，该设备具有通常所说的JTAG接口，这允许研究人员和开发人员调试设备并可以转储固件。不幸的是，该设备还有JTAG保险丝，如果安装了调试器，设备将跳线短路并擦除系统固件。我们通过拆开一个坏的Fitbit并检查芯片的背面证实了这一点。因为难以连接调试器，而且JTAG接口已经在出厂的时候被堵死，我们决定侧重于研究该设备的其它部分。
蓝牙分析
Fitbit Flex设备向智能手机或个人电脑的同步过程是通过蓝牙协议完成的，我们开始尝试动态嗅探蓝牙通信。可以实现嗅探的商业工具高达数千美金，但幸运的是我们找到了名为“Ubertooth”的开源工具，这大大降低了我们的花销。Ubertooth的硬件通过USB接口插入任何一台电脑，且开源项目提供了现成的软件工具来监控、跟踪并捕获蓝牙通信。更重要的是，由于Fitbit没有通过标准的蓝牙4.0协议而是通过BTLE工作，Ubertooth也能够嗅探出BTLE的通信。通过使用Ubertooth套件中的“ubertooth-BTLE”工具，我们能够从Fitbit Flex设备捕获所有的流量，并跟踪其与Fitbit应用通过多个蓝牙跳频信道进行通信。捕获的蓝牙数据包以PCAP格式存储到磁盘上，然后可通过安装相应的BTLE插件在Wireshark2查看。
结果
使用上述方法，我们捕捉到初始的设备配对以及所有后续数据同步到服务器过程中发生的所有的蓝牙通信。我们通过初步分析数据发现，Fitbit Flex会响应来自所有范围内的蓝牙设备的广播。这使我们能够获得Fitbit Flex设备的私有地址，和所有其他BTLE设备附近的私人地址，其中大多数是其他Fitbit设备。根据BLTE的规范，其最好的特性之一是隐私意识，它允许开发人员更换设备的私有地址以避免被追踪。这样的特征应该被智能设备积极利用来保护用户的隐私。然而，在我们的实验过程中，我们并没有在任何Fitbit Flex设备上观察到私有地址的变化。Fitbit选择不使用BTLE的隐私功能，可能导致潜在的隐私泄露，因为它允许第三方跟踪特定用户的活动。此外，由于Fitbit应用程序报告附近设备专用地址的服务器，这些私有地址永远不会改变，这意味着Fitbit有能力构建出每个用户的周围环境和正在进行的活动轮廓。
我们还发现有人称BTLE密钥交换可以被Ubertooth捕获，从而暴露加密密钥。漏洞发现者迈克・瑞安开发了一个叫crackle3的工具，他可以自动化的从抓到的Wireshark PCAP格式的蓝牙数据包中提取加密秘钥。我们试图通过捕获从Fitbit Flex设备到Fitbit移动应用程序的配对过程的数据包来利用此漏洞。然而，crackle没有识别出秘钥交换的过程，这表明为了混淆加密密钥，Fitbit没有按照标准BTLE密钥交换协议。我们没有进一步采取暴力破解密钥的方法，因为这将非常费时，并且超出了项目时间的允许。
安卓应用程序分析
我们探索未来的攻击向量是Fitbit Android应用程序。在这一节中，我们将描述我们的实验装置，包括用于反编译的软件和硬件，分析、修改应用程序和分析结果。
方法
我们使用了一个Nexus5安卓手机作为一个测试平台，用于修改我们的安卓应用程序。为了反编译，修改和重建安卓应用程序，我们使用一套在OS X上运行的工具。
在逆向工程的第一步，安卓应用程序是获得应用程序本身。为此，我们使用APK提取器。APK安装器的电子邮件应用程序你作为附件。
提取的应用（.APK文件）是压缩和签署的应用资源和静态链接的程序文件。为了检查程序，我们需要解压缩档案，分析其中的classes.dex文件。
classes.dex包含Dalvik机器代码的Fitbit应用。靠本身，机器码是很难理解的。因此，我们采用两种逆向工程Dalvik代码常见的方法。
首先，我们可以反编译为Dalvik代码使用Java dex2jar。这是一个单向的操作，从Dalvik程序的图像生成Java源文件很简单，但是很难从编译产生的Java源回Dalvik图像。因此，我们使用Java的源码得到提示应用程序正在做什么。
其次，我们可以把Dalvik代码分解得到Smali的代码，一个Dalvik虚拟机汇编语言。有了Dalvik虚拟机的机器代码和Smali组件之间的一个简单的一对一的映射，所以很容易修改的Smali源和重新包装使用的应用在我们的Nexus 5。我们用bakali拆解应用程序并且使用Smali重新打包我们修改过的代码。
重新包装和重新安装修改后的版本在Nexus 5测试Fitbit APP，我们更换classes.dex与重新打包的修改后的Smali代码。然后我们重新压缩档案对齐在4字节与zipalign并且用keytool卸载apk。zipalign和keytool都是Android开发工具包中的部分工具。我们使用adb，也是安卓开发工具软件包的一部分，将修改后的软件包安装到我们的关系5测试平台上。
分析
反编译Android应用程序并试图弄懂代码意义之后，我们发现了“实时数据模式。”“实时数据模式”是Fitbit设备的功能，当连接到Fitbit设备上时会显示实时的指标。我们确定了“实时数据模式”是运行在未加密的数据上的。首先，我们假设，我们可以修改未加密传输中的数据（在手机里），并安装一个重放攻击。通过验证，这是不成功的，但是，因为在“实时数据模式”传递的动态信息永远不会连接Fitbit在线服务，这些权威的数据记录–只是用于显示目的的缓冲装置。当追踪 “实时数据模式”机制时，我们注意到日志类被重复调用的步骤。然而，经检查我们注意到，该步骤没有采取任何行动。
图3：Android工具用来修改Fitbit应用程序。
我们怀疑，开发商后来注释了或删除了日志记录。我们在功能中插入记录语句并重新编译应用程序。新的记录数据有泄露。特别的，我们找到了数据分步比Fitbit所提供的更好的粒度。该应用程序只显示汇总到5分钟间隔内的步骤，而无线网络的数据包必须间隔15分钟。日志记录语句包含以1分钟的间隔步数据。
通过直接使用应用程序这些数据不可用（且不适宜输出）。当日志记录功能完善时，我们决定进一步调查由“动态数据模式”类提供的日志。我们观察到动态数据包类似于图4中所示。我们有重要的发现，动态数据包都几乎相同，这表明没有使用加密（或至少没有使用随机加密方式）来实现动态数据包。我们决定尝试利用这一点。我们修改其中该应用读取的实时数据，在数据包中的代码的一部分中改变步骤的计数。这部分成功了，我们就能够控制移动设备上显示值。其中一种情况下，我们能够控制应用程序一整天只计数7个步骤。然而，这种数据也没有传播到服务器。我们认为，实时数据的存在的唯一目的就是使得用户可以得到即时的更新，并且它所发送的数据被**在具有更好保护的同步包里。
从这里，我们将焦点转移到手机和flex之间的蓝牙协议是如何运作的。通过进一步研究日志记录，我们可以观察出大部分的蓝牙协议的工作原理。通过随机位计算MAC，并采用CBC-MAC与XTEA分组加密，应用程序的设备进行认证操作。不存在我们能够发现的进一步的验证。
图4：我们对日志记录功能的修改。上图显示记录功能运Fitbit的生产的Android应用程序。图的底部是我们对日志记录功能的修改。
flex发送到手机上的有两种类型的数据包。第一种类型是一个控制包。这是一个第一个字节为-64的包。该控制包的其余部分映射到一个操作码上，这以某种方式改变了手机的状态。第二种类型是数据包。这种类型用在相关的信息被发送时。数据包除了最后一个可以有所不同之外所有的都是20个字节长。此手机在使用它们之前验证这些字节。
我们认为，这种通信是加密的。数据包中没有明显的模式，所以也有可能使用了一些随机加密方式。然而，事实上，数据包的时间戳在细的粒度上是可以使包的整体看起来是随机的，有可能是因为时间戳混淆了模式。因为日志记录表明，有一个随机认证的问题，且发送的字节数是被验证过的，我们的结论是，不可能仅仅通过运行重放攻击获得额外的步骤。
图5：一分钟的粒度在一天中第一个15分钟里
图6：数据包是非常相似的
网络分析
方法
Android应用程序通过加密的TLS连接Fitbit Web服务并进行通信。为了查看流量，我们使用查尔斯代理（Charles Proxy ）。查尔斯代理使你能够通过在电脑上运行代理来检查你的智能手机中的网络流量。代理拦截所有的TLS通信量和使用自定义的查尔斯证书替换服务的TLS证书。加入查尔斯作为手机上的一个值得信赖的认证后，我们通过代理在session期间能够成功的检测流量。
分析
我们从与手机的初始配对开始。手机从它在配对过程显示为指示所述服务器请求的图像。然而，在配对过程中的后一个步骤中，手机从一个无害的message.xml请求数据，然后服务器返回一个大的Javascript数据。同时，Android的日志发布警告称，该应用程序正在运行不安全内容的消息。这是一个可能的攻击向量。看来应用程序并不会检查任何通过WIFI接受的Javascript脚本。
我们在配对过程中截获另一个有趣的数据包是BTLE秘钥。
图7：BTLE凭据
配对处理后，大部分的无线通信是从该服务器得到请求的数据并显示。该步骤的数据全部聚集到15分钟的时间间隔同应用程序的显示的一样。手机从服务器上获取其他数据似乎有点过度，但是这似乎并没有成为一个问题。为了发送该步中追踪器收集的数据，手机上传一个megadump到Mixpanel（一个分析公司）。这个服务器与手机请求数据的服务器不是同一个。Megadump中包含了所有合适的数据，似乎通过base64进行编码。它的内部肯定是有一些结构，但是，因为megadump总是以同样的串“KAIAAA。”我们可以在这里尝试进行一些密码分析，但我们更关注系统的蓝牙方面，因为这部分的反汇编代码更加的清晰。
总结和未来的工作
综合迄今发现的情况我们的研究结果简要总结如下：
*通过蓝牙的分析，我们确定了从第5节得到的结果，即该设备的私有地址并没有改变。如所第5节提到的，这可能通过其Fitbit的蓝牙广播允许了跟踪。
*在配对过程中，手机毫无必要地暴露了其范围内的所有Fitbits服务器。
*在检查手机时，我们发现其中包含比手机应用程序提供用户登录更多的数据。
*我们发现，BTLE凭证从服务器以明文发送到手机上，虽然是通过TLS。
*另外，还有发送Javascript到手机，这可能产生攻击向量。
我们的研究结果表明，虽然Fitbit安全设置总体看来似乎是合理的，但是还需进一步的探索和分析。我们在图1中提出的途径以供将来分析五个标识的区域。
Fitbit固件捕获和逆向工程
虽然JTAG熔丝造成调试设备本身的困难，我们仍然认为获得对设备的固件的权限可能实现的，然后使用逆向工程进行修改。这可以通过Fitbit应用程序插件来完成，使用之前存储在磁盘上或存储器中固件更新。固件的图像分析是past5中可能存在的安全漏洞的一个成功载体，会以加密例程和程序设备本身信息的方式提供更多。
虽然未加密的固件映像将是理想的，有可能以这样的方式进行更新–直到安装到该设备上固件才被加密。分析端到端通信涉及到更新，而我们在本文中已经完成了通信的其余部分，这将是一个很好的着手点。
蓝牙
正如我们上面所描述的，Fitbit设备与智能手机或电脑应用程序之间的蓝牙通讯使用基于XTEA的CBC中的 MAC模式进行身份验证。因为手机必须包含用于验证通信的密码，我们可以对手机进行更多的分析来提取密码。有了密钥和算法，伪造一个MAC并实施蓝牙重放攻击对我们来说将成为一种可能。
Android应用
实时数据不存储在手机上或在传输过程中被译码事实，使得它难以在Android应用程序中利用来获取用户数据。然而，Android的应用程序保留了一个有趣的sqlite3表集，我们怀疑这可能表明，这种开发模式可能会导致在本地存储动态数据的存在。这将值得花费更多的时间来检查该应用是否有可能利用这些表的替代代码路径。
网络分析
我们在第7节指出，配对交换期间有JavaScript发送到应用程序。我们怀疑该JavaScript包含用户界面更新，因为其他资源（图像，**文本）包括了其他的JavaScript。由于Javascript必须在设备上执行，我们认为，一个有趣的攻击向量可能是注入我们自己的JavaScript到配对交换中。然而，由配对过程是通过SSL的，这种攻击的效果可能会减轻，。
Fitbit服务器
最后，我们并没有进行Fitbit API或Mixpanel分析服务设备和Fitbit的Web服务之间的网络安全审计。检查Fitbit服务的漏洞将会很有趣，可能会有常见的安全漏洞（如跨站请求伪造或跨站脚本攻击），或者未公开的私有API调用。
结论
回想一下，我们的三个目的是描述（1）从Fitbit收集它的用户数据，（2）Fitbit提供给它的用户的数据，（3）回收未提供给设备的用户的数据的方法。我们相信，对每一个目标我们都取得了显著的成果。
我们确定Fitbit收集了有关用户，包括其附近的Fitbits的MAC地址的无关信息。我们还发现，Android应用程序可以将访问步骤与数据的粒度下降到一分钟，但用户界面不会呈现。我们能够修改源以显示日志中的这些数据。
我们最成功的分析技术包括对Android应用程序的逆向工程，在第6节中有详细描述。
总体而言，Fitbit提供的用于用户数据的隐私在合理的水平中，但我们更希望提供给有效用户一个易于访问方法，从而通过设备来获取全部的数据集。
该文观点仅代表作者，本站仅提供信息存储空间服务，转载请注明出处。若需了解详细的安防行业方案，或有其它建议反馈，欢迎联系我们。
