BLE安全入门及实战(2)

目录 

BLE的分析

1、使用蓝牙扫描APP

2、使用工具bleah

3、使用工具gatttool

获取BLE的数据

1、手机蓝牙日志

2、认证过程分析

3、ubertooth嗅探

4、中间人


 BLE的分析 

1、使用蓝牙扫描APP

环境:android

工具:no.nordicsemi.android.mcp_87.apk

依次点开可以看到相应的属性及属性值

2、使用工具bleah

地址:https://github.com/evilsocket/bleah/ 安装上,直接运行bleah。

输出:

这个就是我们模拟出来的智能门锁。

使用bleah  -b  “b8:27:eb:90:28:e1”  -e  连接

输入的内容为:

工具已经做好了data的解析

可以看到handle为 000c的是可写的,uuid是: 6834636b-6d33-4c30-634b-436852436d44,是属于厂商自定义的uuid值,但是此时并不知道是写入的啥值才能操作智能门锁。

3、使用工具gatttool

直接运行 gatttool  -b  b8:27:eb:90:28:e1  -I

此时出现:

提示连接成功,此时已经与智能门锁建立了链接

使用 primary查看主要的server

使用 characteristics  查看所有的属性:

使用 char-read-hnd或 char-read-uuid来读取里面的值

我们来读

是ASCII码,转码的话可以看到就是 raspberrypi

里面还有

两个方法,就可以往智能门锁中写入蓝牙数据。

 获取BLE的数据 

1、手机蓝牙日志

首先需要打开开发者调试工具,抓取蓝牙数据包,这个网上有不少的教程,这里不再细说。

抓取到的log文件可以直接用wireshark打开,这里做了两个操作,一个开锁,一个关锁。

wireshark打开后的界面显示如下:

APP端为localhost,智能门锁为remote。

结合下文的协议栈可以看到上层的协议为ATT:

过滤协议ATT:

可以看到均是对handle为000c的写操作,符合前面的分析。

直接看数据值,有两个值:bb010203040506070809101112131415 和 aa010203040506070809101112131415

也就是说发送这两个数据就会产生开锁和关锁的操作,这里先记录下来,后面我们演示攻击时候再用。

这时候直接发送这个数据,门锁是不认的,原因是没有进行配对操作,在看树莓派上的日志输出可以看到:

里面是包含了认证的过程的。

我们在手机上抓包认证过程:

2、 认证过程分析

我们分析这个认证过程:

‑ 客户端请求handle:0x0013 uuid:6834636b‑6d33‑4c30‑634b‑436852537434

‑ 服务器端返回一个值:769675d7c11f336ae6573e7e533570ec

‑ 客户端写入一个值:e1cbdfb88d05890a935bf830fb9fbd1000

此时完成了认证过程。

客户端应该是利用服务器返回的值计算一个值,与服务端一致则可通过认证 这个值的计算过程在app中应该是存在的,我们反编译APP查找计算逻辑。

反编译的过程不再多说。

找到的逻辑为:

calculateResponse函数为:

相关的配置信息是:

从这个配置信息也能看到开锁和关锁的蓝牙数据。

加密逻辑采用了AES算法:

1.  首先使用key对传递过来的挑战码进行AES加密,生成下一步用的加密key

2.  使用生成的加密key对登入密码”DDAAFF03040506070809101112131415”进行加密,生成认证码

关键是找首次加密的key,在第一次启动的时候会有个唯一的设备号,第一次的私钥应该是和设备号的生成有关。

初始化设备和app,重新使用wireshark抓包 门锁传递密钥.log

可以看到是app给设备端写的密钥,所以应该是app生成的密钥信息,然后写给设备端。

触发这个写密钥的操作为:

app首先请求设备端的handle为0x0013的值,设备返回未空,

也就是”BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB” 后面app向0x000c写一个设备号,然后写密钥信息进去,然后设备AES计算完成配对。

其实设备端留有个后门:

有个万能密钥:4861636b6d654c6f636b4d6173746572

3、ubertooth嗅探

ubertooth是个很强大的蓝牙嗅探工具,安装比较复杂,你要信任docker的话直接用docker启动ubertooth就可以,还是比较方便的。

需要注意的是需要特权模式,将dev目录挂载到docker里面

docker  run  –rm  -it  –privileged  -v  /dev:/dev  meatmanek/ubertooth:latest

查看版本号:

root@da81bdbaf272:/ubertooth-2015-10-R1/host/kismet/plugin-ubertooth-phyneutral# ubertooth-util -v

Firmware  revision:  2015-10-R1

说明docker识别了设备

上面我们知道了模拟门锁的mac地址为:b8:27:eb:90:28:e1,只要使用ubertooth ‑f ‑t b8:27:eb:90:28:e1 跟踪数据,进行嗅探即可。

4、中间人

采用的工具是https://github.com/DigitalSecurity/btlejuice

搭建测试环境,具体过程不细说了,具体用到了一个虚拟机,可以在https://mega.nz/#!vxU0zIwJ!fMotiX3ARWcwNm67IAtn2ymHKldpVJgo43YkVZrtH4A 下载虚拟机镜像 过程中出现了vbox无法识别usb设备的问题,这个只需要把当前用户加到vbox的组里就行,还有出现一些无法发现 service的问题,具体可以在issus中查找到问题原因。

搭建好了之后:

vbox运行代理:btlejuice_proxy

宿主机运行btlejuice ‑u 代理ip ‑w

打开本地的8080端口,出现web页面

后面直接操作即可,很直观的操作。

下面主要是分析,我们用APP连接设备,看到web上有数据输出,也就是说代理已经截获到了app与设备之间的数据:

根据前面的分析得知read首先去读取的是挑战码,然后APP根据AES计算处认证值写入设备完成匹配,看到第二条数据应该就是认证码,第三条数据是写入开锁的操作。

原文链接:https://sec.xiaomi.com/article/39   原文作者:ECHO@XIAOMI