蓝牙低功耗（BLE，Bluetooth Low Energy）协议在资源受限的设备之间实现高能效的无线通信。为了简化其应用，BLE需要有限的交互或不需要用户交互才能在两个设备之间建立连接。不幸的是，这种简单性是几个安全问题的根本原因。在本文中，重点分析了两个先前连接的设备重新连接的情况，从而分析了BLE链路层的安全性。在对BLE规范定义的重新连接过程进行形式化分析的基础上，本文重点说明了该规范中的两个关键安全漏洞。结果，即使是正确实现BLE协议的设备也可能容易受到欺骗攻击。
为了证明这些设计缺陷，并进一步研究其安全隐患，本研究开发了BLE欺骗攻击（BLESA，BLE Spoofifing Attacks）。这些攻击使攻击者可以模拟BLE设备并将欺骗性数据提供给另一个先前配对的设备。 BLESA可以很容易地针对BLE协议的某些实现进行实施，例如Linux中使用的一种。此外，对于Android和iOS使用的BLE堆栈实现，发现了一个启用BLESA的逻辑错误，将此安全问题报告给了受影响的各方（Google和Apple），他们也承认了本文的发现。
0x01 Introduction
低功耗蓝牙（BLE）是使用最广泛的低能耗通信协议，到2023年，支持BLE的设备数量有望达到50亿。 BLE协议支持无线短距离通信，该通信允许两个设备连接和交换数据。非典型使用场景由智能手机和通过BLE进行通信的“小工具”设备（例如健身追踪器）组成。每个BLE连接都涉及充当客户端的设备（在此示例中为智能手机）和充当服务器的另一设备（在此示例为健身追踪器）。第一次，两个设备进行连接（允许它们交换数据），它们执行特定的配对过程，具体过程取决于所连接设备的类型及其用户界面的功能。
促成启用BLE的设备的快速增长的主要因素是其低成本和最终用户所需的最少设置工作。先前的研究表明这些用户友好的功能对该协议的安全性具有负面影响。由于BLE通信通常用于对安全敏感的设备中，例如物理安全设备（例如，锁）或健康监控设备（例如，医疗植入物）[16]，因此这种担忧尤其令人担忧。
研究人员通过手动分析其规范指出并研究了BLE协议中的许多实现缺陷。此外，一些先前的工作还对BLE规范进行了自动的形式化分析。但是，这些形式化方法仅关注整个协议的有限方面，例如BLE配对机制。这种局限性是由于以下事实：完全规范化和自动分析BLE规范具有挑战性。挑战来自BLE协议的复杂性，建模其多层设计的困难，其多种变体和可选功能（这使该协议能够支持功能明显不同的各种设备）。
0x02 Threat Model
在本文中，研究了BLE协议一个尚未探索的机制。具体来说，专注于处理重新连接两个先前连接的设备的机制。例如，当服务器设备（例如，健身跟踪器）移出所连接的客户端设备（例如，智能手机）的BLE无线通信范围之外，然后稍后，这两个设备足够靠近时，该机制就起作用了重新建立连接。
为了开始对此场景的分析，首先使用ProVerif协议验证程序对相关的BLE链路层规范进行了正式验证。本文的形式化分析强调了BLE官方规范中的两个弱点。这些漏洞（在某些BLE堆栈实现中）使攻击者可以发起欺骗性攻击，在这种攻击中，攻击者伪装成先前配对的服务器设备，从而诱使客户端设备接受欺骗性数据。
特别是发现BLE规范允许以多种方式实现此协议的多个方面，其中某些方面很容易受到攻击。因此，即使在规范之后正确执行BLE协议栈，也很容易受到欺骗攻击。例如，发现BLE协议栈（通过gatttool进行访问）在Linux客户端设备（例如，Linux笔记本电脑）中正确遵循BLE规范时，很容易受到所识别的欺骗攻击的影响。
此外还发现，即使以理论上不易受到已识别攻击的方式实现的BLE协议栈，由于特定的逻辑漏洞，在实践中仍然容易受到攻击。具体来说，在Android设备使用的BLE堆栈和iOS设备使用的BLE堆栈中发现了类似的实现问题。此问题使许多Android和iOS设备容易受到已识别的攻击。已将发现的问题报告给Google和Apple，他们已确认了这些漏洞。截至2020年6月，Apple已为漏洞分配了CVE-2020-9770并对其进行了修复，但经过测试的设备（即运行Android10的Google Pixel XL）中的Android BLE实施仍然很容易受到攻击。
为了展示确定的问题，设计了一种新颖的攻击称为BLESA（BLE欺骗攻击）。在BLESA中，攻击者假装是先前配对的服务器设备，拒绝了来自客户端设备的身份验证请求，然后将欺骗性数据提供给它。然后，表明运行Ubuntu且其BLE堆栈的最新版本的Linux笔记本电脑容易受到BLESA的攻击。另外，通过将它发布到Google Pixel XL手机上来展示BLESA的有效性，该手机记录了来自称为OuraRing的可穿戴活动跟踪设备的信息。特别是，通过使用BLESA，攻击者成功假冒了该手环，将欺骗数据注入到手机中，并且在手机上运行的环的配套应用程序接受并显示了欺骗数据。
假设攻击者具有与Dolev-Yao模型相同的功能，即，攻击者可以窃听，拦截和修改服务器与客户端之间传递的合法消息。 攻击者还可以将任何消息注入通信渠道。 但是，攻击者不知道服务器和客户端之间共享的密钥，并且所使用的加密功能是完全安全的。 而且，攻击者无法替换服务器或客户端的固件。 由于BLE是一种短距离通信协议，因此假设攻击者与客户端之间的距离以及攻击者与服务器之间的距离都在蓝牙范围内， 用欺骗性消息误导客户。
0x03 Formal Analysis of BLE Reconnection
当客户端与先前连接的服务器重新连接时，将对BLE链路层身份验证机制进行正式验证。利用ProVerif进行此协议验证。
A.ProVerif模型
当客户端在新会话中与服务器重新连接时，将为身份验证过程建立一个正式的模型。身份验证过程被建模为两个通信状态机，一个用于客户端，一个用于服务器。在BLE规范中，对与客户端的属性请求的传输相对应的状态机和与服务器上的属性请求的处理相对应的状态机进行建模。该模型全面涵盖了不同类型的消息，包括与属性访问请求，属性访问响应和错误响应相对应的消息。客户端和服务器之间的通信被建模为自由（或开放）通道（free plain_channel：channel），在该通道中，攻击者具有威胁模型中描述的功能。
还考虑了属性的所有特征，以涵盖服务器设备的不同使用场景。因此，将服务器上的属性建模为可读和可写。此外对两种类型的属性进行建模：（1）无需配对即可访问的基本属性（即，在安全级别1），以及（2）敏感属性配对后即可访问（安全级别为2或更高）。最后，对客户端进行建模以将访问请求发送到服务器，以按不同的顺序读取/写入这两种类型的属性。配对期间建立的共享密钥用于在需要加密时对通信进行加密/解密。
安全目标：根据上面代码中列出的传统安全目标来分析上述模型。这些安全目标包括：（1）机密性，即，所传达的消息不应将任何敏感数据泄露给攻击者（第6-9行），（2）完整性，即所传递的消息不应被攻击者篡改而不被检测到（第6-9行），以及（3）真实性，即可以验证所传递的消息是由真实发件者生成的（第11行）。此外，当启动来自客户端的请求并处理服务器上的请求时，还将检查从规范中指定的规则中提取的一个BLE特定安全目标。仅当连接的安全级别与访问该属性的要求一致时，服务器才应授予对客户端的读/写访问权限（第13行）。
B.发现的设计缺陷
通过正式验证，当先前连接的设备重新连接时，本研究发现了一些违反已检查的安全目标的情况。这些违规导致以下两个安全漏洞，攻击者可能会利用这些漏洞来发起欺骗攻击。
漏洞1：可选身份验证
发现链路层加密/身份验证是可选的：客户端和服务器可以针对特定属性选择禁用它。因此，在基本属性的情况下，可能会违反属性访问请求和响应的机密性，完整性和真实性目标，如ProVerif的以下结果所示。
反例：
注意到，服务器根据所请求属性的访问控制策略来确定其与客户端的连接的安全级别。如计数器示例所示，当访问控制策略允许连接的最低安全级别（即安全级别1）时，可以以纯文本形式发送属性访问请求和响应。在这种情况下，将不会部署任何链路层身份验证。因此，攻击者可以对服务器和客户端设备发起欺骗攻击。
由于连接的安全级别由服务器指导，因此如果服务器仅允许安全级别为1的连接，则客户端将无法强制执行更高安全级别的连接。这方面使得服务器和客户端都容易受到欺骗攻击。
漏洞2：规避身份验证
当客户端在配对后与服务器重新连接时，BLE规范提供了两种可能的身份验证过程。
（1）响应式认证：在此过程中，客户端在建立连接后立即以纯文本（即，安全级别1）发送属性访问请求。仅当服务器响应并显示一条错误消息，表明连接的当前安全级别与访问该属性所需的安全级别不一致时，客户端才会通过启用加密/身份验证做出反应。对于此过程，形式分析表明可以违反访问响应的真实性，如下面的ProVerif输出所示。
反例：
尽管存储在服务器上的敏感属性没有泄漏给攻击者，但攻击者可以窃听客户端发送的请求，模拟服务器并用与敏感属性相对应的欺骗响应来欺骗客户端。Linux上的现有BLE堆栈实现（当通过gatttool访问时）遵循此反应式身份验证，从而使相应的客户端容易受到欺骗攻击。
（2）主动式身份验证：在此过程中，客户端设备会在向服务器发送任何请求之前主动启用加密/身份验证。特别是，客户端使用先前建立的预共享密钥启用加密，然后继续进行身份验证。在这种情况下，如果服务器未能启用加密（这也意味着它未能启用身份验证） ，客户端将中止连接。形式化验证表明，所有检查的安全目标都在主动身份验证期间成立，如以下结果所示。
不幸的是，Andriod和iOS使用的现有BLE堆栈实现无法正确遵循此过程，从而使相应的客户端容易受到欺骗攻击。
0x04 BLE Spoofing Attack (BLESA)
通过形式化验证确定的设计漏洞来构造BLE欺骗攻击（BLESA）。在这种攻击中，攻击者向伪装成先前配对服务器设备的客户端设备提供欺骗数据。
攻击设置：本研究检查了服务器和客户端在上一个会话中安全配对的情况，当前它们已断开连接，但它们打算开始新的会话。例如，当客户端移出服务器的通信范围然后又返回时，就会发生这种情况。
在这种情况下，攻击者首先发现服务器并与其连接以获得有关服务器属性的信息（例如标识符）。由于BLE协议旨在允许任何设备与另一个BLE设备连接并获取有关提供的属性的信息，因此攻击者可以轻松获取此信息。此外，由于BLE广播数据包始终以明文形式发送，因此攻击者可以通过广播相同的数据包并克隆其MAC地址来轻松地模拟良性服务器。然后，攻击者开始广播欺骗性的广告包以确保无论何时客户端尝试启动与先前配对的服务器进行新会话后，它可以发现欺骗性广播包并与攻击者建立连接。此时，攻击者已准备好针对客户端启动BLESA。在以下各节中，将按照被动身份验证过程以及遵循主动身份验证过程针对客户端介绍BLESA的工作流。
A.针对响应式身份验证的BLESA
上图a展示了客户端和服务器重新连接以及反应式身份验证过程在良性环境中进行的示意图。客户端首先向最低安全级别（即，安全级别1级的服务器发送属性读取请求），无需任何加密/身份验证。如果属性是敏感的并且可以在更高的安全级别（例如，具有加密和身份验证的安全级别3）上是只读的，则服务器会以错误消息（例如，加密不足）来响应客户端。收到错误消息后，客户端通过使用预共享的密钥启用加密和身份验证来提高安全级别，然后再次发送请求。此时，服务器很容易接受读取请求并返回属性值。
现在，介绍BLESA的工作流程，如上图b所示。在此，攻击者拦截来自客户端的属性读请求并以欺骗性的属性值进行响应。由于客户端没有遇到任何错误消息，因此错误地假定可以在最低安全级别（即，以纯文本格式）访问该属性。因此，客户端不启用加密/身份验证，并且接受欺骗的属性值。在BLESA的此实例中，使攻击成为可能的根本原因是客户端设备依赖于服务器的错误消息来进行攻击。调整使用的安全级别。
B.针对主动式身份验证的BLESA
上图a显示了客户端设备与良性服务器重新连接时触发的主动身份验证过程的工作流程。连接后，客户端立即请求使用预共享密钥启用加密（和身份验证），服务器将遵守该请求。然后，客户端安全地发送属性读取请求，并且服务器使用（加密和认证的）属性值安全地进行响应。如果BLE堆栈正确地执行了主动身份验证，遵循了规范，则BLESA将失败。但是进一步分析表明，基于Android和iOS的客户端设备都遭受逻辑错误，使BLESA可以针对这些设备。
上图b展示了BLESA如何使用主动身份验证过程成功胜过客户端设备，但受到所解释的实施漏洞的影响。具体地，在连接到攻击者之后，如果客户端尝试启用加密，则攻击者向客户端发送一条错误消息，指定长期密钥不可用，从而使加密失败。此时，客户端未正确遵循BLE规范（在这种情况下，建议中止连接），但继续与攻击者建立连接，客户端随后继续以明文形式发送对目标属性的读取请求。与服务器不同，攻击者很容易授予对属性的访问权限，使其在最低安全级别（即安全级别1）下可用，并将伪造的属性数据提供给客户端。因此，客户接受来自攻击者的欺骗性数据。
漏洞利用：根据BLE规范，当客户端与先前配对的服务器重新连接时，如果在主动身份验证过程中加密启用过程失败，则客户端应与服务器重新配对（如上图所示）或中止连接。但是，某些客户端（即基于Android和iOS的设备）中的BLE堆栈无法正确遵循规范。具体来说，发现即使启用加密过程失败，客户端也可能不会中止连接并以明文形式继续通信，而无需与服务器重新配对。攻击者可以利用此缺陷来启动BLESA。怀疑此实现漏洞可能是由官方文档中解释BLE协议这一部分的方式引起的。
为了访问基本属性，并且某些服务器设备不支持链路层加密（即设计漏洞1），BLE规范做出了一些规定，以维护与这些资源受限的服务器设备的兼容性并增强可用性。因此，当加密/身份验证失败时，仍然可以按照规范中的说明以纯文本格式传输BLEdata和控制消息（上图）。认为上图中所示规范中的细节引起的矛盾可能使BLE堆栈开发人员感到困惑。这样，他们犯了逻辑错误，即在加密过程失败的情况下不中止连接，这对于访问先前配对的服务器上的安全敏感属性是必不可少的。
0x05 Implementation and Impact
A.设计漏洞-1的检查
为了确定是否确实存在某些不使用链路层身份验证的BLE服务器设备，采用两种方法：（1）通过静态分析来检查一组BLE设备的配套应用程序的行为。（2）对一组实际的BLE设备进行采样，并通过运行时分析检查它们的通信数据包。
移动应用程序的静态分析：典型的BLE设备（例如Fitbit健身追踪器）依赖于其伴随移动应用程序（例如Fitbit应用程序），该应用程序使最终用户能够访问和管理记录的属性数据（例如步数）。由于配对过程（建立密钥）是启用链路层身份验证的先决条件之一，因此，如果在其伴随应用程序中未调用配对API，可以很容易地确认BLE设备不支持链路层身份验证。为此，利用静态分析框架FlowDroid来检查Android BLE应用程序。更具体地说，对于每个伴随应用程序，在FlowDroid中使用Class Hierarchical Analysis（CHA）选项来构建调用图，并确定是否应用程序确实从其任何入口点（例如，活动）调用配对API。由于CHA是用于调用图构造的相对保守的方法，因此可能会丢失部分方法调用。但是，与其他选项（例如，SPARK）相比，分析结果更加精确，误报率极低。因此，它使用配对提供了一个较低范围的BLE app。
静态分析从33,785个受欢迎的应用程序开始，这些应用程序于2020年1月和2020年2月从AndroZoo网站自动爬取。基于这些应用程序的构造调用图和相应的API，发现只有127个应用程序包含读取的BLE数据读/写操作。然后，检查在这些应用程序中是否调用了配对API（createBond( )）。不幸的是，发现在127个检查的应用程序中，只有41个（32.3％）包含配对过程，这意味着大多数被调查的BLE伴侣应用程序（67.7％）没有实现链路层身份验证。
传输数据包的运行分析：研究了12种BLE设备（如上表所示），这些设备被选择代表了主流BLE设备制造商的各种应用。将每台服务器设备与Google Pixel XL手机相连，并读取其属性。在这些实验中，使用Ubertooth One无线电拦截运行时通信的数据包。通过分析截获的数据包，发现在检查的12个BLE设备中，有10个不支持任何链路层加密/身份验证。为此得出的结论是，大多数现实世界中的BLE设备都不采用链路层身份验证。
B.设计漏洞-2的检查
为了检验第二个漏洞，测试了四个不同的客户端设备，它们涵盖了具有不同BLE堆栈实现的所有主要平台。在下表中提供了有关这些设备的详细信息。在每个平台上进行实验，以探讨以下两个问题的答案：（1）两种身份验证程序中的哪一个客户端设备在与服务器设备重新连接时会利用吗？ （2）如果客户端设备遵循主动身份验证过程，则其BLE堆栈实现是否存在任何逻辑缺陷，使其容易受到欺骗攻击？
为了回答这两个问题，首先将每个经过测试的客户端与一台服务器（使用Linux笔记本电脑进行仿真，如下表所示）配对，然后断开它们的连接。之后将经过测试的客户端与同一服务器重新连接，并要求客户端读取服务器的属性之一，同时使用Wireshark捕获所有生成的BLE流量。
通过分析与用作客户端的Linuxlaptop对应的流量数据，发现Linux BLE堆栈（即通过gatttool访问的BlueZ）实现了响应式身份验证过程。结果，Linux BLE遭受了漏洞2的困扰。相反，发现Android，iOS和WindowsBLE堆栈实现了主动身份验证过程，其中Windows BLE堆栈严格遵循BLE规范。但是，即使加密/验证失败，Android和iOS设备也会继续重新连接。
责任披露：已于2019年4月8日向Apple和Google报告了此漏洞。Apple已确认本文的发现，已将CVE-2020-9770分配给该漏洞，并进行了修复。尽管Google也确认了该漏洞，但被告知漏洞报告类似于比本研究早三天提交的另一份报告。注意到，测试设备（即具有Android 10的Google Pixel XL）中，较新的Android BLE实施（截至2020年5月）仍然很容易受到攻击。
C.针对Linux客户端的BLESA
为了攻击Linux客户端（前表第三行中列出），使用另一台Linux笔记本电脑作为服务器设备。模拟的服务器运行python脚本以提供与敏感属性相对应的服务，该属性可以在安全级别3（即具有加密和身份验证的连接）下读取。为了模拟攻击者，使用带有CSR 4.0蓝牙加密狗的Linux桌面（如下表所示）。攻击者还运行一个Python脚本，该脚本处理从客户端接收到的消息，并针对该客户端启动BLESA。此外，在客户端设备上使用thegatttool发送属性读取请求并接收响应。
为了启动BLESA，攻击者执行以下步骤：❶扫描（bluetoothctl）服务器发送的广告包以记录其MAC地址； ❷将攻击者的蓝牙MAC地址（BlueZ中的bdaddr工具）更改为服务器的MAC地址，以便客户端可以与攻击者重新建立连接； 通过向加密狗发出主机控制器接口（HCI）命令，HCI_LE_Set_Advertising_Parameters，HCI_LE_Set_Advertising_Data和HCI_LE_Set_Advertising_Enable来广播与服务器相同的（模拟的）广播包； ❹在从客户端接收到ATT_READ_REQ消息后，通过ATT_READ_RSP消息注入欺骗数据。
通过执行这些步骤，攻击者成功绕过了Linuxclient的反应式身份验证过程，并诱使客户端接受欺骗数据。
D.针对Android / iOS客户端的BLESA
由于BLESA通过将连接降级为纯文本来绕过链路层身份验证，因此与不使用任何应用程序层安全性机制（例如，加密或身份验证）的BLE服务器设备通信的所有基于Android和iOS的客户端设备都容易受到BLESA的攻击。注意到根据先前的研究，从BLE服务器设备读取数据时，有46％的Android应用程序（累计安装量为23.79亿）未利用应用程序层安全性。这意味着至少46％的Andriod应用程序容易受到BLESA的攻击。Apple应用程序商店中的易受攻击的应用程序所占的比例很可能相似。
在这里展示了攻击者（如前表所示）如何通过模拟Oura环将BLESA投放到Google Pixel手机上。攻击者执行前三个步骤，即❶扫描环的广播数据包； ❷克隆广播包和环的MAC地址。此后，攻击者执行以下操作：❹发送HCI命令HCI_LE_Long_Term_Key_Request_Negative_Reply，指示在收到HCI事件HCI_LE_Long_Term_Key_Request时，密钥无法绕过加密和身份验证；❺在之后从ATT_READ_RSQ消息中通过ATT_READ_RSP消息注入欺骗数据。注意到，攻击者可以按照相同的步骤针对iOS客户端设备启动BLESA。
通过执行这些步骤，攻击者成功地将欺骗的数据注入到智能手机中，并且在智能手机上运行的环的配套应用程序将欺骗的数据显示给用户。 上图a显示，在实验中，Oura Ring设备的实际电池电量为43％。 通过BLESA，成功地向应用程序注入了伪造的电池电量（0％），如图b所示;同时，还注入了另一条欺骗性消息，该消息触发了应用程序中的通知，提示充电已完成，如图c所示。
注意到，尽管第一个欺骗消息使应用程序认为电池电量为0％，但有趣的是，该应用程序接受了另一个欺骗消息（对应于充电完成）并向用户显示错误通知。可以在https://pursec.cs.purdue.edu/projects/blesa.html 上访问此攻击的演示。
0x06 Mitigation of BLESA
为了防止BLESA，需要确保客户端与其之前配对的服务器设备之间的重新连接过程安全。可以通过改进BLE堆栈实现和/或更新BLE规范来实现这一目标。
更新实施：就Linux BLEstack（通过gatttool访问的BlueZ）而言，可以将客户端设备更新为仅采用主动身份验证。根据BlueZ开发人员，他们已将gatttoolas标记为不推荐使用，它将从BlueZ中完全删除gatttool及其源代码，并且仅保留bluetoothctl。此外，可以通过正确遵循BLE规范来缓解已发现的Android和iOS客户端使用的主动身份验证的实现漏洞。更新的实现必须确保当与先前配对的服务器的身份验证失败时，客户端将中止连接并重新启动配对过程。
一个更根本的问题是，即使对于主动身份验证，BLESA也会在实现中存在其他潜在错误的情况下绕过链路层身份验证。这是安全研究人员建议在多层上进行身份验证的典型方案。实际上，如果在应用程序层进行身份验证/加密，则链路层问题就不会成为可利用的问题。不幸的是，这种改进可能会不能广泛部署，因为很大一部分资源受限的设备无法远程更新。
修订规范：虽然修复错误以使BLE设备快速抵御BLESA是很重要的，但制定出规范以防止更高级的欺骗攻击也同样重要。为此，应防止客户端首先发送属性访问请求然后根据服务器返回的错误消息调整连接的安全级别。换句话说，在发送访问请求之前，客户端应首先获取有关存储在服务器上的属性的访问要求的真实信息，然后调整连接的安全级别以满足这些要求。但是，此方法要求客户端在配对过程中记录服务器上每个属性的安全要求。因此，需要更新规范中的配对过程，以便服务器可以将其每个属性的安全性要求发送给客户端。
0x07 Conclusion
在本文中对BLE规范中定义的重新连接过程进行了形式验证，并发现了BLE链路层身份验证机制中的两个设计缺陷。通过利用这些设计缺陷，本研究提出了BLESA，这是一种新颖的BLE欺骗攻击，攻击者可以通过它模拟BLE服务器设备并将欺骗数据提供给先前配对的BLE客户端设备。 BLESA可以轻松地针对运行Linux的BLE设备启动（通过gatttool访问）。
此外，对已发现的现实BLE实现中的漏洞的进一步检查，揭示了Android和iOS BLE堆栈中的一个相关实现漏洞。由于存在此漏洞，这两个堆栈都容易受到BLESA的攻击。为了展示BLESA，详细介绍了如何使用此攻击来将来自健身追踪器的数据欺骗到Android智能手机。此外，估计了可能受到此攻击影响的现有Android应用程序的数量。最后讨论了重新连接过程中可能的改进，以从根本上减轻BLESA等欺骗攻击的威胁。
还没有评论，来说两句吧...