IOT安全:对小爱音箱的初步探索

  • A+
所属分类:安全文章

0x01 使用bettercap进行中间人劫持

小爱音箱和我在同一个wifi下,最简单的方式就是通过arp攻击加上流量重定向到代理上进行匿名代理拦截,大致掩饰一下bettercap的流程:

IOT安全 | 对小爱音箱的初步探索

这个环境下,我的mbp和小爱处于一个wifi下,小爱的地址是192.168.23.145,我开启arp攻击欺骗小爱,然后启用anyproxy功能将小爱的80流量引导到我的mbp上的burp端口10001。另外burp这边的proxy上要勾选这个选项

IOT安全 | 对小爱音箱的初步探索

攻击成功后,我就能在burp上抓到小爱的80流量了。

0x02 通过串口方式打开ssh

很无奈,小爱绝大部分都是https流量,我用上面同样的方式引导443到10001上,抓不到https,burp直接报证书校验错误。可见小爱大部分流量都是https并且校验证书。为了获得更大的权限我现在只能将小爱敲开,然后通过串口进入他的身体后开启ssh:

IOT安全 | 对小爱音箱的初步探索

IOT安全 | 对小爱音箱的初步探索

IOT安全 | 对小爱音箱的初步探索

找到了串口后焊上排针

IOT安全 | 对小爱音箱的初步探索

插上杜邦线后连出来,这里我直接把他连出来方便以后用

IOT安全 | 对小爱音箱的初步探索

通过usb转串口连上,putty设置成串口115200波特率,就能看到输出了:

IOT安全 | 对小爱音箱的初步探索

可以看到,小爱其实是个LEDE的路由器(现在叫openwrt)

0x03 获取root后分析小爱的相关情况

首先我要做的是开启ssh:

rm /etc/dropbear/*dropbearkey -t rsa -f /etc/dropbear/dropbear_rsa_host_keydropbear -r /etc/dropbear/dropbear_rsa_host_key

其中dropbear是嵌入式设备中爱用的一个ssh服务,执行完毕以上三句后试试是否可以SSH连接了,网上说root密码是空,然而并不是,我也懒得改密码直接打开/etc/shadow里抄出来放到cmd5里解密,这条记录是收费的。解密得到密码:moer123456至此就可以连接了。

随后我们ps一下看一下:

IOT安全 | 对小爱音箱的初步探索

可以看到一些mi带头的服务,那些基本就是小米的服务,还有一些其他的大部分也是。

 

接下来看一下开机脚本init.d中的内容,东西挺多的我也不举例了,这里我改了开机脚本里miio的选项,打开了debug日志:

IOT安全 | 对小爱音箱的初步探索

然后重启一下好了(即便你说只需要重启应用就行,但是我就喜欢reboot)重启完后tail一下/tmp/log/miio.log

IOT安全 | 对小爱音箱的初步探索

就能看到很多有趣的东西了,有时候即使抓不到包,这个debug日志里也会打印部分请求体。

0x04 尝试通过修改配置文件饶过https证书校验 

目前看来总共有三块https要绕过:

1. /usr/share/mico/messaging/messaging.conf 包含了初始化的一些接口

大概展示一下配置文件:

IOT安全 | 对小爱音箱的初步探索

通过替换里面的https为http(上图是已经替换了的),可以绕过部分接口的https问题,并且看下来http也是支持的可以不用强制转为https。

2. /usr/share/mico/messaging/mediaplayer.cfg 包含了另一些接口,同时有信任的CA证书路径

对于该文件有两种思路,一种是替换里面的https为http,另一种是将ca证书路径更改为burp的证书路径。我试试看第二种看看行不行,即指改动certs文件夹的路径,更改后的文件夹是我自己建的,里面放的是burp的ca证书

IOT安全 | 对小爱音箱的初步探索

后面我放弃了改ca路径,还是回到https替换成http的思路上来了。

3. 替换pub文件

/usr/share/mico/messaging/messaging.conf 有记录了一个pub文件,猜测是校验特定接口的公钥时候用的,目前看来可能是*.ai.xiaomi.com这个地址的pub文件

IOT安全 | 对小爱音箱的初步探索

绕过思路是通过burp的ca生成一个pub来替换。

先从burp中导出私钥

IOT安全 | 对小爱音箱的初步探索

通过命令openssl rsa -inform DER -in priburp -pubout -out burp.pub生成公钥文件,然后上传到小爱上去替换掉原来的server_2.pub文件

IOT安全 | 对小爱音箱的初步探索

修改配置文件中的pub文件配置为burp.pub

IOT安全 | 对小爱音箱的初步探索

4. 重启一下,见证奇迹

三个操作都做完了,我们重启后分别观察是否正常………………OK,并不行,主要是第三个pub文件替换没有效果,看起来那个account-dcm.ai.xiaomi.com地址的https并不受这几个pub文件控制(至少我把我能看到的pub文件都替换了)。OK换个思路,我直接去找包含这个域名的文件,结果如下:

IOT安全 | 对小爱音箱的初步探索

既然找到了这个so,我直接修改这个so里的https到http试一下吧,为了以防万一我先备份一个,然后直接vim修改so里的https为http,结果保存一下再重启………………好吧没什么用,看日志似乎直接报错了,估计得放弃部分接口的https了(这一个so后面得再研究一下)

5. 认栽,还原so和pub文件

还原so和pub文件,为了让https通过,我们将信任证书路径的操作也还原,统一该用https替换http的方式来抓取部分接口先做测试吧。最终结果如下:

IOT安全 | 对小爱音箱的初步探索

6. 一些问题

虽然已经是可以抓到部分接口的包了,但是一开始我们将这些接口替换成http后,部分接口会出现403错误,这个时候我们需要将他们再重新定向到443端口:

IOT安全 | 对小爱音箱的初步探索

这样那些443的接口就会正常了,但是这又会导致部分原本就是http的接口出现没有响应,因为他们也被强制定向到443了。这个问题手工到时候再解决一下。

0x05 总结

暂时先到这里,针对抓包而言,arp欺骗到代理,基本上是什么都能抓的,唯一比较麻烦的是https的证书校验。抛开https,其他的tcp、udp其实也是可以这样直接劫持修改的。后面我会继续没事折腾一下小爱,还是挺好玩的,这次分享的话就先在这里结束掉吧。

 

PS:如果有人因为看了这个而去抓包怼小爱接口找到了万把块钱的漏洞,希望能请我喝杯瑞幸咖啡。

本文始发于微信公众号(米斯特安全团队):IOT安全 | 对小爱音箱的初步探索

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: