0x00 前言

大家好，我是影子。最近设计了一套物理安防渗透课程, 在研发过程中遇到了一把蓝牙锁, 因其之前被大神Stawomir Jasek破解过, 本以为会是个简单的复现过程. 未曾想此蓝牙锁的安全机制已经完全更新, 只得从头开始研究. 这里跟大家分享一下心得. 同时借此机会向BaCde 在研究过程中的协助表示感谢。

image

0x01 开局

传统物理安全的历史由来已久, 涉及各行各业的各个领域. 门禁; 视频监控; 警报系统种类繁多. 尤其是门锁的历史甚至可以追述到古埃及. 门锁这个作为保护民众财产的重要器材, 一直就伴随着人类文明的发展. 甚至可以说锁具的发展也表现了人类智慧的结晶.随着科技一日千里, 物联网的逐步流行. 物理安防领域也发生了翻天覆地的变化. 采用蓝牙或者NFC 作为智能门锁的通讯方式几乎成了标配. 并且有人还认为智能锁比传统锁具更加安全, 比方以下这段具备代表性的网友留言。

image

然而真实情况是在方便了客户操作的同时, 因设计缺陷所导致的安全问题也层出不穷. 在过去几年里不断有研究人员在智能门锁产品中发现安全漏洞. 其中由Stawomir Jasek发现的某蓝牙锁厂商在自研加密方案上的设计缺陷非常具备代表性. 具体分析过程建议大家可以去看原文, 简单来说其发现有以下几个缺陷。

缺陷1: 蓝牙锁APP的登录验证密码是以明文的方式传输的. 只要要在客户登录的时候, 捕获蓝牙流量就可获取密码。

image

缺陷2: 蓝牙锁APP在跟锁交互之初会发送相似应答挑战的数据包. 然而这样的应答响应的发起方竟然是手机APP端. 也就是说假如采用中间人攻击的方式, 每次发给锁端的挑战数据可以是一样的, 因此锁定应答数据也会是一样. 这就给我们带来了数据重放攻击的机会。

image
image

缺陷3: 通过逆向蓝牙APP找到了开发人员硬编码的超级密码 741689. 进而分析出整个数据包的结构. 看来业界常说没事不要自研密码算法是有道理的。

image
image

原本事情到这里, 只要复现以上几个缺陷就该结束了. 没想到一上来捕获的客户登录数据包跟期待的就完全不同, 仔细一看这分明是加密后的密文啊, 说好的明文密码呢?

image

0x02 分析

先来理解下这款蓝牙锁的APP吧. 其流程很简单先跟目标锁建立连接, 随后需要输入正确的密码 (默认是123456). 连接成功后便可对锁进行开关操作。

image

对APP反编译后找到几个至关重要的信息. 例如APP包含的UUID和其功能。

image

以及蓝牙锁采用的密钥信息, 很显著开发者用硬编码的方式将AES密钥写在APP 中. 同时我们还能找到各个操作指令的硬编码, 如登录时的 616。

image

除此之外开发者还将加密前和加密后的指令信息写在了log 文件中, 也许是为了方便调试吧. 当然我们也一样可以通过logcat 指令来查看和分析。

image

0x03 验证

基于前面的分析, 可得出结论, 更新过后的Smart-lock 仍有设计缺陷, 且会被黑客滥用. 让我们一起来验证下吧。

image

缺陷1: 虽说安全机制采用了AES128. 但由于是对称性加密, 其16字节的密钥被开发人员以硬编码的形式写在APP中. 这让我们在获取蓝牙数据包后, 便可轻易破解出原文.如下图所示, 客户登录时的密文仍可被破解并获取密码。

image

缺陷2: 蓝牙锁APP在跟锁交互时发送的应答挑战数据包, 仍旧是由手机APP端发起的. 也就是说数据重放攻击隐患仍旧存在. 我们甚至只要要一台手机便可完成重放攻击的整个操作. 如下图所示将编辑好的X ML 文件导入nRF Connect 宏文件, 或者直接对UUID进行写操作就可。

image
image

0x04 结语

通过Smart-Lock这个案例, 相信大家对蓝牙锁应用的安全分析有了更多理解. 市面上的蓝牙锁种类繁多, 每款产品的安全程度也各不相同. 建议客户考虑相对重视自身安全的大品牌产品. 从开发者的角度来说在设计初期就需将安全防御考虑进去. 同时也要避免如硬编码这类错误, 以免被攻击者滥用。