越来越多的智能设备和各种传感器开始进入大众生活，但我们不得不承认这些智能设备会追踪你的健康和健身信息，因此这些设备的安全和隐私问题就变得尤为重要。
更糟糕的是，一些像Fitbit这样的智能设备公司不向用户提供任何数据控制权限，并将所有用户数据上传到他们的私有云。
如果用户想要获得更详细的健康分析，就必须去购买。
用户不知道这些设备收集什么信息。
而且近年来，Fitbit 暴露了很多安全漏洞，其中有一些可以导致用户信息泄露，还有一些是设备与网络服务器之间通信的严重漏洞，包括很多设备问题本身。
这些安全问题对于这些健身追踪设备来说并不罕见，并且是当前智能设备的常见问题。
研究目标 该项目的主要研究目标是了解自上述漏洞曝光以来 Fitbit 在安全性方面取得了哪些改进。
同时，消费者在佩戴智能设备之前，有权知道该设备收集哪些信息以及如何看到这些信息。
因此，这个项目还将研究 Fitbit 收集哪些数据、如何收集数据以及这些数据如何在设备和服务器之间传输。
有几个步骤：确认Fitbit从用户那里收集了哪些数据，查看Fitbit向用户显示了哪些数据，将其与他们收集的数据进行比较，恢复他们从用户那里收集但不显示的数据，并绘制与之相关的图片他们的系统。
可能的安全漏洞和隐私问题相关工作在开始该项目之前，我们编写了一篇一般文献综述来识别当前现有的工具和资源。
我们在名为“Hacks by Pete”的博客上找到了一些有关 Fitbit 设备同步数据格式的信息。
配对 Fitbit One 后，博主分析了他设备上的同步日志。
我们之前从 Fitbit Flex 中捕获过类似的数据。
虽然他的博客证实了我们的研究结果是正确的，但除此之外没有提供任何有用的信息。
这主要是由于博客上缺乏文档，而且 Fitbit 已更新其软件以加密和混淆设备上的同步信息。
我们研究的另一个帮助来源是一个名为 Galileo 的开源项目，该项目由一位德国开发人员创建，他编写的软件允许 Fitbit 设备同步到 Linux 操作系统。
该项目的开发人员在Fitbit设备与移动应用程序或计算机应用程序之间的同步数据格式和通信协议方面取得了重大成就。
他们特别强调了与不同 Fitbit 设备通信时使用的不同标头字节，并提供了各种数据抓取样本。
虽然此信息有助于我们了解捕获的 Fitbit Flex 设备的数据格式，但它不会解密数据。
一位开发者表示，他发现使用的加密方法是AES，但没有提供任何证据。
总而言之，我们的团队不知道 Fitbit 使用哪种方法进行加密，或者加密密钥是如何生成和替换的。
除了上述资源之外，我们还发现了许多独立项目试图分析Fitbit通信协议。
对旧款 Fitbit 设备（2 款已停产）的研究似乎相当成功，而其他设备则没有取得很好的成果。
综上所述，旧款 Fitbit 设备（Fitbit Tracker）由于缺乏加密或安全通信协议而遭受了严重的安全攻击。
从那时起，Fitbit 一直在其手环（Fitbit Flex、One 和 Zip）和应用程序上使用安全措施。
开始更加重视安全性，使用户更难捕获他们无权查看的内容。
除了研究Fitbit设备之外，我们还研究了蓝牙协议。
之前的一个安全项目是麻省理工学院秋季第 6 期计算机系统安全课程的一部分，该项目检查了蓝牙协议中的漏洞。
对于理解蓝牙通信和充分利用我们购买的 Ubertooth 设备来说，这是一个非常有用的结果。
系统概述 因为我会整天佩戴 Fitbit 手环。
为了实现这一要求，Fitbit手环会在本地缓存动态数据。
当用户使用iOS或Android应用程序同步数据时，应用程序会将手环中的数据发送到Fitbit运营的服务器进行存储。
所有用户健身数据都不会保留在用户的手机或手环中，而是从Fitbit的云服务中获取。
图 1：Fitbit 系统组件。
我们将攻击面分为五个区域：(a)、(b)、(c)、(d)、(e) Fitbit 设备和智能手机或 PC 之间的同步是通过蓝牙执行的。
它使用 BTLE（低功耗蓝牙）协议。
您的智能手机或 PC 与 Fitbit 云服务之间的同步通过互联网进行加密。
在图 1 中，我们将 Fitbit 系统集成组件分为五个分析区域。
下面将按顺序进行分析。
第 4 节介绍了 Fitbit Flex 设备硬件的分析 (a)。
第 5 节介绍 Fitbit Flex 和 Nexus 5 的蓝牙通信分析 (b)。
第 6 节是 Fitbit Android 应用程序的分析 (c)，第 7 节是 Fitbit 设备与 Fitbit Web 服务之间的网络通信分析(d).我们将 Fitbit API 和网络服务分析作为未来的工作放在第 8(e) 节中。
硬件设备分析图2：这是Fitbit主板的正面。
红色是主CPU，橙色是BTLE芯片，蓝色是充电器，黄色芯片看不清楚。
根据 iFixit 提供的 Fitbit 完美拆解，主板上的主芯片为 ARM 皮质处理器意法半导体 32LC6。
对芯片的进一步调查表明，该设备具有通常所说的 JTAG 接口，允许研究人员和开发人员调试设备并转储固件。
不幸的是，该设备还有一个 JTAG 熔丝，如果安装了调试器，该设备将短路跳线并擦除系统固件。
我们通过拆开损坏的 Fitbit 并检查芯片背面来证实这一点。
由于连接调试器很困难，而且 JTAG 接口在工厂被屏蔽，因此我们决定将重点放在设备的其他部分。
蓝牙分析 Fitbit Flex 设备与智能手机或 PC 的同步过程是通过蓝牙协议完成的，我们首先尝试动态嗅探蓝牙通信。
能够实现嗅探的商业工具要花费数千，但幸运的是我们找到了一个名为“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 能够构建每个用户周围环境和正在进行的活动的轮廓。
我们还发现 Ubertooth 可能捕获 BTLE 密钥交换的说法，从而暴露加密密钥。
漏洞发现者Mike Ryan开发了一款名为crackle3的工具，该工具可以自动从捕获的Wireshark PCAP格式的蓝牙数据包中提取加密密钥。
我们尝试通过捕获从 Fitbit Flex 设备到 Fitbit 移动应用程序的配对过程中的数据包来利用此漏洞。
不过，crackle 并未识别出密钥交换过程，这表明 Fitbit 并未遵循标准 BTLE 密钥交换协议，以便混淆加密密钥。
我们没有进一步暴力破解密钥，因为这将非常耗时并且超出了项目时间所允许的范围。
Android 应用程序分析 我们探索的未来攻击媒介是 Fitbit Android 应用程序。
在本节中，我们描述我们的实验设置，包括用于反编译、分析、修改应用程序和分析结果的软件和硬件。
方法 我们使用 Nexus5 Android 手机作为修改 Android 应用程序的测试平台。
为了反编译、修改和重建 Android 应用程序，我们使用一组在 OS X 上运行的工具。
对 Android 应用程序进行逆向工程的第一步是获取应用程序本身。
为此，我们使用 APK Extractor。
您的电子邮件应用程序的 APK 安装程序作为附件。
提取的应用程序（.APK 文件）是经过压缩和签名的应用程序资源和静态链接的程序文件。
为了检查程序，我们需要解压存档并分析里面的classes.dex文件。
classes.dex 包含 Fitbit 应用程序的 Dalvik 机器代码。
机器代码本身很难理解。
因此，我们采用两种常用的方法对Dalvik代码进行逆向工程。
首先，我们可以使用Java dex2jar反编译Dalvik代码。
这是一种单向操作。
从 Dalvik 程序的镜像生成 Java 源文件很简单，但将生成的 Java 源代码编译回 Dalvik 镜像却很困难。
因此，我们使用 Java 源代码来获取应用程序正在执行的操作的提示。
其次，我们可以分解Dalvik代码得到Smali代码，一种Dalvik虚拟机汇编语言。
通过 Dalvik VM 的机器代码和 Smali 组件之间的简单一对一映射，可以轻松修改 Smali 源并重新打包应用程序以在 Nexus 5 上使用。
我们使用 baksmali 反汇编应用程序并重新打包修改后的代码使用斯马里。
为了重新打包并重新安装修改后的版本以在 Nexus 5 上测试 Fitbit 应用程序，我们将classes.dex 替换为重新打包的修改后的 Smali 代码。
然后，我们使用 zipalign 重新压缩存档以对齐 4 字节，并使用 keytool 卸载 apk。
zipalign 和 keytool 都是 Android 开发工具包的一部分。
我们使用adb（也是Android开发工具包的一部分）将修改后的包安装到我们的Relationship 5测试平台上。
在分析反编译的 Android 应用程序并尝试理解代码后，我们发现了“实时数据模式”。
“实时数据模式”是 Fitbit 设备的一项功能，可在连接到 Fitbit 设备时显示实时指标。
我们确定“实时数据模式”正在未加密的数据上运行。
首先，我们假设我们可以修改传输中（在手机中）的未加密数据并安装重放攻击。
但经核实，这是不成功的，因为“实时数据模式”传递的动态信息从未连接到Fitbit在线服务，这些权威数据记录只是为了显示目的而被缓冲。
在跟踪“实时数据模式”机制时，我们注意到重复调用日志类的步骤。
然而，经过检查我们发现这一步没有采取任何行动。
图 3：用于修改 Fitbit 应用程序的 Android 工具。
我们怀疑开发人员后来注释或删除了日志记录。
我们在函数中插入日志语句并重新编译应用程序。
新记录数据已被泄露。
特别是，我们发现数据分段的粒度比 Fitbit 提供的更好。
该应用程序仅显示聚合为 5 分钟间隔的步骤，而无线网络的数据包必须间隔 15 分钟。
记录语句包含间隔为 1 分钟的步骤数据。
直接使用应用程序无法获取此数据（且不适合导出）。
当日志记录功能完成后，我们决定进一步研究“动态数据架构”类提供的日志。
我们观察到类似于图4所示的动态数据包。
我们发现动态数据包几乎都是相同的，这表明没有使用加密（或至少没有随机加密）来实现动态数据包。
我们决定尝试利用这一点。
我们修改数据包中应用程序读取实时数据的代码部分，更改步数。
一旦这部分成功，我们将能够控制移动设备上显示的值。
在一个案例中，我们能够控制应用程序全天只计算 7 步。
但是，该数据也不会传播到服务器。
我们认为实时数据的唯一目的是让用户能够得到即时更新，并且其发送的数据被复制在具有更好保护的同步包中。
从这里开始，我们将重点转移到手机和 Flex 之间的蓝牙协议如何工作。
通过进一步研究日志记录，我们可以观察蓝牙协议的工作情况。
通过随机位计算MAC，并使用CBC-MAC和XTEA块加密对应用程序的设备执行身份验证操作。
我们无法找到进一步的验证。
图 4：我们对日志记录功能的修改。
上图显示了 Fitbit 的 Android 应用程序上运行的记录功能。
图的底部是我们对日志记录功能的修改。
Flex向手机发送的数据包有两种类型。
第一类是控制包。
这是一个第一个字节为-64的数据包。
控制数据包的其余部分映射到操作码，该操作码以某种方式改变手机的状态。
第二种是数据包。
发送相关信息时使用该类型。
除了最后一个数据包可能有所不同之外，数据包的长度均为 20 字节。
该电话在使用这些字节之前会验证它们。
我们相信这种通信是加密的。
数据包中没有明显的模式，因此也可能使用了一些随机加密。
然而，数据包的时间戳是细粒度的，这一事实可能会使整个数据包看起来随机，可能是因为时间戳混淆了模式。
由于日志记录表明存在随机身份验证问题，并且发送的字节数已得到验证，因此我们得出结论，仅通过运行重放攻击不可能获得额外的步骤。
图 5：当天前 15 分钟的一分钟粒度 图 6：数据包与网络分析方法非常相似 Android 应用程序连接到 Fitbit 网络服务并通过加密的 TLS 进行通信。
为了查看流量，我们使用 Charles Proxy。
Charles Proxy 使您能够通过在计算机上运行代理来检查来自智能手机的网络流量。
代理拦截所有 TLS 流量，并用自定义 Charles 证书替换服务的 TLS 证书。
将 Charles 添加为手机上的可信身份验证器后，我们能够通过代理成功检查会话期间的流量。
分析 我们从与手机的初始配对开始。
如图所示，手机会在配对过程中显示来自其请求的服务器的图像。
然而，在配对过程的后续步骤中，手机从无害的 message.xml 请求数据，并且服务器返回大量 Javascript 数据。
与此同时，Android Log 发布了一条消息，警告该应用程序正在运行不安全的内容。
这是一个可能的攻击媒介。
该应用程序似乎不会检查通过 WIFI 接受的任何 JavaScript。
我们在配对过程中截获的另一个有趣的数据包是 BTLE 密钥。
图 7：处理 BTLE 凭证配对后，大部分无线通信都是从服务器获取请求的数据并显示它。
此步骤的数据全部聚合为 15 分钟间隔，如应用程序中所示。
手机从服务器获取其他数据似乎有点过分，但这似乎不是问题。
为了发送跟踪器在此步骤中收集的数据，手机会将大型转储上传到 Mixpanel（一家分析公司）。
该服务器与手机请求数据的服务器不同。
Megadump 包含所有适当的数据，并且似乎是通过 base64 编码的。
然而，它内部一定有某种结构，因为 megadump 总是以相同的字符串“KAIAAA”结束。
我们可以尝试在这里进行一些密码分析，但我们将更多地关注系统的蓝牙端，因为这部分反汇编代码更清晰。
总结和未来的工作 迄今为止发现的内容的综合 我们的发现简要总结如下： 通过对蓝牙的分析，我们确认了第 5 节得到的结果，即设备的私有地址没有改变。
正如第 5 节中提到的，这可能允许通过 Fitbit 的蓝牙广播进行跟踪。
在配对过程中，手机不必要地暴露了其范围内的所有 Fitbit 服务器。
当我们检查手机时，我们发现它包含的数据多于手机应用程序向用户提供的登录数据。
我们发现 BTLE 凭据以明文形式从服务器发送到手机，尽管是通过 TLS 发送的。
此外，还向手机发送 Javascript，这可能会产生攻击向量。
我们的研究结果表明，虽然 Fitbit 的整体安全设置似乎合理，但仍需要进一步探索和分析。
我们在图 1 中为五个确定的区域提出了一条路径，以供未来分析。
Fitbit 固件捕获和逆向工程 尽管 JTAG 熔丝给设备本身的调试带来了困难，但我们仍然相信可以访问设备的固件，然后使用逆向工程对其进行修改。
这可以通过 Fitbit 应用程序插件，使用存储在磁盘或内存中的先前固件更新来完成。
固件的图像分析是过去可能的安全漏洞的成功载体，并将以加密例程和有关程序设备本身的信息的形式提供更多信息。
虽然未加密的固件映像是理想的，但可以以固件在安装到设备上之前不加密的方式进行更新。
分析端到端通信涉及更新，虽然我们已经在本文中介绍了通信的其余部分，但这将是一个很好的起点。
蓝牙 如上所述，Fitbit 设备与智能手机或计算机应用程序之间的蓝牙通信使用基于 XTEA 的 CBC 中的 MAC 模式进行身份验证。
由于电话必须包含用于验证通信的密码，因此我们可以对电话进行更多分析以提取密码。
有了密钥和算法，我们就可以伪造MAC并实施蓝牙重放攻击。
Android应用程序的实时数据不会存储在手机上，也不会在传输过程中进行解码，这使得Android应用程序很难利用它来获取用户数据。
然而，Android应用程序保留了一组有趣的sqlite3表，我们怀疑这可能表明这种开发模型可能会导致动态数据存储在本地。
值得花更多时间检查应用程序是否有可能利用这些表的替代代码路径。
网络分析 我们在第 7 节中指出，在配对交换期间有 JavaScript 发送到应用程序。
我们怀疑此 JavaScript 包含用户界面更新，因为其他资源（图像、复制的文本）包含其他 JavaScript。
由于 JavaScript 必须在设备上执行，我们认为一个有趣的攻击媒介可能是将我们自己的 JavaScript 注入到配对交换中。
然而，由于配对过程是通过 SSL 进行的，因此可能会减轻这种攻击的影响。
Fitbit 服务器 最后，我们没有在 Fitbit API 或 Mixpanel Analytics Services 设备与 Fitbit 的网络服务之间进行网络安全审核。
检查 Fitbit 服务的漏洞会很有趣。
可能存在常见的安全漏洞（例如跨站请求伪造或跨站脚本攻击），或未公开的私有 API 调用。
结论 回想一下，我们的三个目标是描述以下方法：(1) 从 Fitbit 收集有关其用户的数据，(2) Fitbit 向其用户提供的数据，以及 (3) 回收未提供给设备用户的数据。
我们相信，对于我们的每一个目标，我们都取得了显着的成果。
我们确定 Fitbit 收集与用户无关的信息，包括附近 Fitbit 的 MAC 地址。
我们还发现 Android 应用程序可以以低至一分钟的粒度访问步骤和数据，但用户界面不会呈现。
我们能够修改源以在日志中显示此数据。
我们最成功的分析技术涉及 Android 应用程序的逆向工程，详细描述见第 6 节。
总体而言，Fitbit 为用户数据提供了合理的隐私级别，但我们希望为有效用户提供一种易于访问的方法来获取通过设备的整个数据集。