CCS 2019论文解读：基于自动化App分析的BLE设备指纹识别

一、背景

低功耗蓝牙（BLE，Bluetooth Low Energy）是一种成本低廉的低功耗无线解决方案，在物联网设备中得到了广泛的应用。在一个典型IoT场景中，用户需要首先将IoT设备与其配套的手机App进行连接，将手机作为IoT设备与网络通信的桥梁。而根据蓝牙协议的规定，BLE设备在配对前需要广播它的UUID，报告其设备类型，移动应用据此寻找其支持的IoT设备并发起连接。

这个配对过程存在一个根本缺陷。IoT设备与移动应用的交互使用了GATT（Generic Attribute Profile）协议，GATT协议使用UUID对设备服务、设备属性进行索引，在IoT设备的整个生命周期中，这些UUID都是保持不变的。由于设备本身所包含的情报有限，因此从设备配套应用出发，寻找App操作BLE设备时使用的UUID，我们就能够对发送BLE广播的设备进行精确识别，知道这些设备的类型及具体功能。

由于IoT设备本身的局限性，很多设备并没有与用户交互的人机接口，因此只能采用蓝牙配对中的Just Works模式与用户终端进行连接，这种连接采用了较弱的加密方式，容易被攻击者监听或劫持连接，如果蓝牙协议版本小于4.2，攻击者通过监听设备配对过程，即可获得设备与用户终端之间的长期密钥（LTK，Long Term Key），从而解密所有后续通信数据。

本文通过分析BLE设备配套应用，从应用中解析出UUID，实现从UUID反推设备类型与功能用途。并通过实地测试，证明了这种方式能够识别日常生活中的大多数设备（94.6%），同时发现其中部分设备（7.4%）存在潜在问题。

二、本文内容

本文的研究目标分为两个部分，第一步是通过对Google应用商店中使用蓝牙BLE功能的App（如BLE设备的配套应用等）进行逆向分析，提取出App所关联的设备UUID，并研究App在蓝牙通信过程中是否存在脆弱点。第二步，在实际场地上对BLE设备广播进行嗅探，验证实际发现的设备能否与App中提取出来的UUID关联上，从而实现BLE设备的精确识别。

作者最终在Google应用商店的200万个应用中，识别到18166个应用中存在对BLE设备的扫描、连接行为，在这些应用中提取并去重后得到了13566个UUID。这些应用中61.3%使用Just Works模式与设备进行连接，这些应用与BLE设备之间的连接是不安全的。在这些不安全的应用中，13.6%的应用在BLE通信过程中，对数据没有使用任何加密，12.9%的应用发送的数据全部是硬编码的值，攻击者可以绕过用户直接对设备进行操作。

在实地嗅探中，作者在约3.3平方公里（约等于北京大学校园面积）的城市区域内探测到了30862个蓝牙设备，其中5822个是包含UUID的BLE设备，其中94.6%的设备可以关联到BLESCOPE提取出的UUID，7.4%的设备能够被窃听或控制。

1BLESCOPE提取应用中设备UUID

为了实现第一步对商店全量App进行的分析，本文提出了一种自动化移动应用分析工具BLESCOPE。这个工具基于Java静态分析框架Soot开发，能够对安卓App进行自动化分析，从安卓系统的关键API出发，寻找并分析BLE相关的系统API调用，再从发起API调用的参数逆推出应用和设备所使用的UUID，并通过系统调用的先后与逻辑顺序，重建设备、服务、属性的UUID树。在提取UUID的同时，BLESCOPE对UUID变量值的来源进行检测，分析变量值生成时是否经过了加密、哈希函数，变量值中有哪些部分来源于用户输入，哪些部分是硬编码的值。

UUID的提取

UUID在BLE通信过程中起到重要的作用，在广播、连接、交互过程中，作为操作对象（设备、服务、属性）的唯一标识符。一个典型的UUID是一段128位的数据，在应用apk包中通常存储为十六进制字符串。前面我们提到，连接一类特定的设备所使用的UUID是固定不变的。因此，对设备配套应用进行反编译，我们就能够提取到一部分的UUID。如图 1就是智能医疗设备品牌Kinsa的App中的代码片段。

图 1 IoT应用Kinsa反编译代码片段

除了硬编码的数据值之外，部分应用所使用的UUID值是通过一些运算得到的，针对这个问题，BLESCOPE采用了程序切片（Program Slicing）和值集分析（Value-set Analysis）的方法，先从Dalvik指令出发，生成程序的控制流程图，再通过安卓系统提供的蓝牙API作为程序切片的终点，再追踪API的调用参数，沿着控制流程找到参数定义位置作为程序切片的起点，并记录沿途对此变量的操作，通过对变量操作的模拟得到最终传入蓝牙API的UUID值。

BLESCOPE通过跟踪表 1中API调用以提取UUID。

表 1 BLESCOPE用于UUID提取的目标API

UUID层级关系重构

提取到UUID的值的同时，我们还需要知道这些UUID之间的关系，哪些UUID代表GATT服务，一个服务下有哪些属性。BLESCOPE在模拟执行过程中，记录每一次蓝牙API调用的对象实例与参数之间的关系，并将这个关系转化为输出的树状结构中的一条边。

举个例子，指令v0.getCharacteristic(v1) 对应了表 1中第2个API，变量v0是getService的返回值，因此v0关联的UUID可以通过计算getService的参数取值获得，而v1关联的UUID就是getCharacteristic的参数值。这样我们就得到了一个服务UUID和一个属性UUID的对应关系。依此类推，我们就能获取一个应用调用的所有BLE设备的UUID与它们的层级结构。

应用脆弱性检测

BLESCOPE实现了两种应用脆弱性的检测，明文数据传输与通信参数硬编码。这两种脆弱性存在的前提，是设备采用了Just Works方式配对，因为只有通过这种方式配对的连接，存在LTK被攻击者嗅探、通信被窃听的风险。

安卓BLE开发指南说明了两种安全的蓝牙配对方式。一是通过createBond() API，二是定义一个接收事件ACTION_BOND_STATE_CHANGED的广播接收器。如果应用里找不到这两种配对方式，则BLESCOPE认为这个应用采用了Just Works方式配对。

BLESCOPE检测明文数据传输的方式是，通过对表 2中BLE设备通信相关API调用的参数取值来源进行分析，追溯参数赋值路径上是否存在表 3中加解密、哈希相关算法的调用，如果所有的蓝牙通信调用中，都没有找到加解密相关的函数调用，则认为这个应用与其配套设备之间的通信是明文传输的。

表 2 BLESCOPE关注的BLE设备通信API

表 3 BLESCOPE关注的加解密、哈希算法API

通信参数硬编码的检测，也是对表 2中函数调用的参数进行分析。如果所有参数的取值来源都是硬编码的，无外部输入，则这个应用存在相应的脆弱性。论文中没有定义“外部输入”的判别方式，我们可以认为其包括网络请求、文件读写、用户输入、随机数生成等。

通过对Google商店1.8万个支持BLE通信的App进行分析，BLESCOPE发现其中61.3%的应用使用了Just Works方式配对，15.8%的应用的BLE连接过程存在上述两种漏洞。

图 2 支持BLE通信的应用漏洞分布

2测试结果

抓取到所有可用的UUID以后，作者在学校附近的一片区域进行了一次嗅探实验。作者使用树莓派和一根高增益天线，在大约1.28平方英里（约合3.3平方公里，与北大校园大小接近）的区域内对蓝牙设备广播进行探测。在区域内探测到了30862个蓝牙设备，其中5822个是包含UUID的BLE设备，其中94.6%的设备可以关联到BLESCOPE提取出的UUID，7.4%的设备能够被窃听或控制。

图 3 BLE设备分布热力图

BLE设备的广播包中包含设备的基本信息，这其中包含供应商的vendor ID，在Bluetooth SIG的数据库中能够查到供应商ID对应的公司名称。在作者的实地测试中，Google的设备最多，占比达到44.6%。

图 4 BLE设备数量Top 10与对应的应用包名

在所有存在漏洞的设备中，数量最多的几种设备包括温度计、车钥匙、钥匙防丢器、玩具等。存在漏洞的设备总共431个，所以相同类型的设备并不多。图 5是存在脆弱性的设备种类Top 10。

图 5 存在脆弱性的BLE设备Top 10

三、结论

本文假设了一个前提：一个面向消费者的IoT设备一定会在应用商店上架其配套的移动应用。从这个前提出发，本文通过对BLE设备的配套应用的分析和实地测试，证实了我们可以通过这种方式，识别出绝大部分家用场景下的BLE设备，并识别出其中一部分设备存在的脆弱性，取得了较好的效果。更重要的是，通过这种方式能够积累一个设备指纹-设备类型-配套应用的对应关系的知识库，对其他角度的安全分析提供一定的参考价值。

从防护的角度，我们可以分为两个方面来讲。针对IoT设备配套应用，对IoT设备配套应用的加固可以较好的防护攻击者的逆向分析与信息提取，大大增加自动化信息收集的难度。针对设备本身，使用高版本的蓝牙协议栈或在应用层对数据传输进行加密，或像某些设备一样在应用层实现双向认证，可以降低IoT设备通讯被窃听的风险。但UUID不会变化的根本问题，算是协议层面的脆弱点，至少在可见的未来，不太好得到解决了。

参考链接：

[1].Chaoshun Zuo, Haohuang Wen, Zhiqiang Lin, and Yinqian Zhang. 2019. Automatic Fingerprinting of Vulnerable BLE IoT Devices with Static UUIDs from Mobile Apps. In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security (CCS '19). ACM, New York, NY, USA, 1469-1483. DOI: https://doi.org/10.1145/3319535.3354240

[2].Mark Weiser. 1981. Program slicing. In Proceedings of the 5th international conference on Software engineering. IEEE Press, 439–449.

[3].Gogul Balakrishnan and Thomas Reps. 2004. Analyzing memory accesses in x86 executables. In International conference on compiler construction. Springer, 5–23.

[4].2019. Soot - a framework for analyzing and transforming java and android applications. http://sable.github.io/soot/.

[5].2019. 16 Bit UUIDs for Members. https://www.bluetooth.com/specifications/assigned-numbers/16-bit-uuids-for-members/.

[6].2019. BluetoothGatt | Android Developers. https://www.bluetooth.com/specifications/gatt/generic-attributes-overview/.

[7].2019. GATT Overview | Bluetooth Technology Website. https://developer.android.com/reference/android/bluetooth/BluetoothGatt

关于格物实验室

格物实验室专注于工业互联网、物联网和车联网三大业务场景的安全研究。 致力于以场景为导向，智能设备为中心的漏洞挖掘、研究与安全分析，关注物联网资产、漏洞、威胁分析。目前已发布多篇研究报告，包括《物联网安全白皮书》、《物联网安全年报2017》、《物联网安全年报2018》、《国内物联网资产的暴露情况分析》、《智能设备安全分析手册》等。与产品团队联合推出绿盟物联网安全风控平台，定位运营商行业物联网卡的风险管控；推出固件安全检测平台，以便快速发现设备中可能存在的漏洞，以避免因弱口令、溢出等漏洞引起设备控制权限的泄露。

内容编辑：格物实验室  张浩然   责任编辑：肖晴

往期回顾

本公众号原创文章仅代表作者观点，不代表绿盟科技立场。所有原创内容版权均属绿盟科技研究通讯。未经授权，严禁任何媒体以及微信公众号复制、转载、摘编或以其他方式使用，转载须注明来自绿盟科技研究通讯并附上本文链接。

关于我们

绿盟科技研究通讯由绿盟科技创新中心负责运营，绿盟科技创新中心是绿盟科技的前沿技术研究部门。包括云安全实验室、安全大数据分析实验室和物联网安全实验室。团队成员由来自清华、北大、哈工大、中科院、北邮等多所重点院校的博士和硕士组成。

绿盟科技创新中心作为“中关村科技园区海淀园博士后工作站分站”的重要培养单位之一，与清华大学进行博士后联合培养，科研成果已涵盖各类国家课题项目、国家专利、国家标准、高水平学术论文、出版专业书籍等。

我们持续探索信息安全领域的前沿学术方向，从实践出发，结合公司资源和先进技术，实现概念级的原型系统，进而交付产品线孵化产品并创造巨大的经济价值。

长按上方二维码，即可关注我们