硬核黑客笔记-不聪明的蓝牙锁

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

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

然而真实情况是在方便了用户操作的同时, 因设计缺陷所导致的安全问题也层出不穷. 在过去几年里不断有研究人员在智能门锁产品中发现安全漏洞. 其中由Stawomir Jasek发现的某蓝牙锁厂商在自研加密方案上的设计缺陷非常具有代表性. 具体分析过程建议大家可以去看原文, 简单来说其发现有以下几个缺陷。
缺陷1: 蓝牙锁APP的登录验证密码是以明文的方式传输的. 只需要在用户登录的时候, 捕获蓝牙流量即可获取密码。

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


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


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

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

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

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

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

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

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

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

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

https://github.com/kevin2600/BTLE-SmartLock-Hacking

https://smartlockpicking.com/tutorial/how-to-pick-a-ble-smart-lock-and-cause-cancer/