蓝牙安全风险分析：以灯泡、跳蛋、小米手环为例

【编者按】本文来自乌云，作者FengGou。

0x01 前言

因为自己曾DIY过所谓的“智能硬件”，学习过程中除了接触各种芯片、传感器、电路知识外，也拆了不少设备分析其设计思想学以致用。再后来又接触了如：Wi-Fi、ZigBee、Bluetooth、NFC、IR、普通射频甚至音频等通信技术，才发现空气中那些形形色色的边界，才是整个物联安全的关键。

今天的内容是我在乌云内部做的技术分享，也是我以前对低功耗蓝牙技术的一些接触，整理后决定对社区公布。一来可以让社区对神秘的蓝牙技术破冰；二来也是抛砖引玉，希望能看到更多有趣的案例；三来比起那些华丽丽的show，我更喜欢分享一些实际的内容。

0x02 BLE 协议栈总览，GAP、GATT讲解

0x03 BLE嗅探

0x04 伪造BLE通信

（理论细节过于繁复，暂且略去，感兴趣的童鞋可进乌云平台原文查看）

0x05 分析BLE私有数据协议，以灯泡、跳蛋、小米手环为例

有了上面的理论基础，要开始实战了。我手头上只有蓝牙灯泡和小米手环，后来一个猥琐的朋友借我个跳蛋希望帮忙分析…

YeeLight 2 代蓝牙灯泡

首先这个灯泡我在分析前就敢肯定它是存在问题的，因为灯泡的操作逻辑不会过于复杂，无非是一开一关、变色等等，所以我就拿它来做个“Hello world”。

1. 抓包灯泡的开关灯动作的value

   
   

2c2c2c3130302c2c2c2c2c2c2c2c2c2c2c2c（开）

2c2c2c302c2c2c2c2c2c2c2c2c2c2c2c2c2c（关）

看到差异了么？

0x313030 = 100 0x30 = 0 从 4bytes 开始，就是该灯泡的亮度部分，100最亮，0没有亮度，也就是关。

2. 抓包灯泡的换颜色动作

3235352c302c302c3130302c2c2c2c2c2c2c（红色）

302c302c3235352c3130302c2c2c2c2c2c2c（蓝色）

同上道理

0x3235352c302c30 = 255,0,0

0x302c302c323535 = 0,0,255

这就是RGB的颜色格式，很简单直接告破：）

最后看下 Handle 0x0012，来源如图

最后，简单的看下Bluez协议栈自带的gatttool工具的使用方法

通过抓包分析得知操控灯泡颜色的handle是0x0012，我读了下他的uuid为fff1，私有的。用char-write-cmd命令直接写入我们分析好的协议，灯泡变色，然后再读取之，数据确实成功写入。

Demo（视频进入乌云平台可看）

小爱爱智能跳蛋

（这个真不是我的，某个小伙伴借给我研究的）

这个产品感觉逻辑也简单，就是网络远程发送震动指令到手机，手机在通过BLE链接设备进行你懂、我懂、他也懂的事情，羞～

这个跳蛋有三种模式：预定义节奏的震动、随着音乐翩翩起舞的震动以及体位交互震动。

前两个没啥难度，基本抓到操作重放出来就OK了，最后这个模式比较卡哇伊，玩玩它咯。

与灯泡不同的是，进入体位模式后，Master会给Slave发送一个状态开启这个模式。所以你盲目的发送抓到的震动操作这个蛋是不震的，因为你要先让她进入状态。

给 Handle 0x0013 发送 0x0811060f01010232 后，它就进入状态了。

然后 0x3e ＝ 震动，0x7f ＝ 生理暴击（你狂按手机的时候就疯狂的震动）

这个分析很简单，因为都是些开关类的操作没有太多实际的含义，所以无需解开数据，直接重放就可以，我做了个发送SOS急救信号的demo。

Demo （视频见乌云漏洞平台）

小米手环

小米手环是明星产品，对它的分析也充满了趣味与困难。因为从一开始我就遇到了一个认证机制，如果蓝牙链接后不写入一段特殊格式的数据，那你只能读少量信息不能对手环进行操作。

我通过抓包分析GATT中的write操作，过程省略2万字，最终定位了一个向 Handle 0x0019 进行的write操作，该Characteristic返回了个Notify，然后手环就可以随意写指令了（如私有协议中的震动、LED颜色变化、开启实时步数监控等）。

不过认证怎么能叫PWN？

不过认证怎么能叫PWN？

不过认证怎么能叫PWN？

重要的事情说三遍。小米手环的认证数据分析好了，结构如下

这个签名是最重要的部分，前面的数据都可以伪造，只要签名过了，手环就会允许你后续的写指令，才能做到真正的PWN。那这个签名是咋算出来的？请看番外篇。

番外篇：小米手环认证机制分析

剑走偏锋，通过BlueZ得到了小米手环一个完整的私有协议UUID，然后去Github搜索，希望找到官方的代码（其实这部分通过逆向Android app相信就能得到，不过说好的剑走偏锋么）

然后呢？duang～

似乎是个第三方SDK，目前至少不用去逆向Android APP了开心，说实话这个我还真不擅长。通过这个SDK我找到了具体认证流程的代码：GitHub - miband-sdk-android。

从这段代码中分析，最终写入Characteristic的内容，来自 userInfo.getBytes(device.getAddress()

public void setUserInfo(UserInfo userInfo)

{

BluetoothDevice device = this.io.getDevice();

this.io.writeCharacteristic(Profile.UUID_CHAR_USER_INFO, userInfo.getBytes(device.getAddress()), null);

}

userInfo.getBytes 的设计在这里，做了简单注释

public byte[] getBytes(String mBTAddress)

{

...

ByteBuffer bf = ByteBuffer.allocate(20);

bf.put((byte) (uid & 0xff));    //uid

bf.put((byte) (uid >> 8 & 0xff));

bf.put((byte) (uid >> 16 & 0xff));

bf.put((byte) (uid >> 24 & 0xff));

bf.put(this.gender);    //性别

bf.put(this.age);   //年龄

bf.put(this.height);    //身高

bf.put(this.weight);    //体重

bf.put(this.type);  //类型

if(aliasBytes.length<=10)

{

bf.put(aliasBytes);

bf.put(new byte[10-aliasBytes.length]);

}else{

bf.put(aliasBytes,0,10);

}

byte[] crcSequence = new byte[19];  //取出用户信息的前19个字节

for (int u = 0; u < crcSequence.length; u++)

crcSequence[u] = bf.array()[u];

byte crcb = (byte) ((getCRC8(crcSequence) ^ Integer.parseInt(mBTAddress.substring(mBTAddress.length()-2), 16)) & 0xff);

bf.put(crcb);   //将签名跟前面的用户信息拼接

return bf.array();  //最终写入Characteristic的内容

}

这个数据与MAC地址最后两位FC进行异或为16byte数据，在转为2byte的hex签名结果。用户信息与手机端无需一致，只要签名正确即可。这里感谢 @瘦蛟舞 的帮忙，用java程序帮我做了个接口，这样我就能根据MAC地址任意生成有效的认证数据了。

完整代码也不放出了，毕竟可以秒杀手环认证：）

解决了认证的难题，接下来就是压轴大戏，如何对用户以及产品口碑造成真正的影响。震动？改步数？LED跑马灯？都不是，我选择在茫茫人群中，给你写入恶意的闹铃，名曰 午夜凶“铃”。试想下，背着我那台无线Hack设备，天天在早高峰蹭北京城铁13号线，自动搜索身边小米手环，然后链接过认证写入闹铃，你们猜一个月后我能“感染”多少手环？我相信不用多久，小米手环论坛就会有用户闹翻天了…光说不练耍流氓，实现它。选择设备后抓包，客户端设置几次闹铃，只要一次我就解开私有协议格式了：

一样简单，数据格式我画出来。第一位说明当前的操作是闹铃，第二位是闹铃的序号，第三位闹铃的开关，第四位开始就是闹铃时间，倒数第二位是智能唤醒（就是在你浅睡眠的时候把你叫起，但是我偏不，就是要在你深度睡眠时唤醒你，木哈哈），最后一位就是闹铃的循环日期，0x7F就是每天。

写好测试程序，搜索并链接手环通过那个“认证”获取操作权限，再用手环LED玩个跑马灯，最后华丽丽的写入闹铃释放链接。结果手机客户端连上去发现闹！铃！没！开！启！还是默认的关闭状态，不放弃继续分析，我是越挫越勇的……

通过后面的分析发现，这个地方是小米手环客户端（至少iOS客户端）的BUG，手环开发组GG认为手环的数据只有通过客户端进行开启修改，所以非客户端写入的数据不会自动同步！也就造成了恶意闹铃虽然写入成功，但客户端看不到，认为闹铃没有变化不去同步最新的状态，但这反让攻击变的更加隐蔽了，啧啧。

看演示吧，POC代码不放，因为细心动手的人可以通过我的分析解决一切问题，也避免真的有人直接利用代码对小米用户进行攻击（因测试成功后忘记取消之前设置的午夜凶“铃”，所以我成了第一个受害者，大半夜太酸爽了）。

Demo：（视频略大，没法直接上传，感兴趣的童鞋进入乌云平台看吧）

0x06 结语

内容没有涉及任何经典/低功耗蓝牙的协议加解密、签名、配对儿认证等安全机制，毕竟是初探，不搞那么复杂高大上变成学术文章。所以我先分享一些接地气儿的产品和攻击场景，希望能够建立伙伴们对物联网安全的兴趣。

BLE在蓝牙中都是很小的一部分，在物联网汪洋大海中更是一叶扁舟，学海无涯希望路上有你。

PS：以上的内容我个人认为并不是漏洞，毕竟还得10米的攻击范围内，所以直接当做技术分享吧。

为照顾用户体验，部分内容已做精简。欲了解更多技术细节，可进入乌云平台查看。