sourcell.xu@海特实验室

Boffins 披露了一个被称为 BIAS 的蓝牙安全漏洞 (CVE-2020-10135),攻击者可利用该漏洞欺骗远程配对设备。海特实验室研究员针对于该漏洞进行了详细分析。

在经典蓝牙(Bluetooth Classic)的世界中,link key 是安全的基石。根据蓝牙核心规范 5.2,我们有三种类型的 link key,它们分别为:

combination key

temporary key

initialization key

本文中,我们关注的是 combination key。该 link key 由两个已经配对的 BR/EDR 设备共享。它主要有如下两个作用:

1、已配对设备再次连接对方时,会使用 link key 鉴权:

2、鉴权通过后,连接双方可以使用 link key 导出用于加密后续通信数据的 encryption key。

本文分析的 BIAS (Bluetooth Impersonation AttackS) 漏洞影响了前者,而后者也曝出过 KNOB (Key Negotiation Of Bluetooth) 漏洞。概括的说,BIAS 利用如下三点绕过了 BR/EDR 设备的鉴权机制:

Legacy authentication 允许单边鉴权

Secure authentication 可协商降级为 legacy authentication

经典蓝牙允许 master 与 slave 角色转换

下面将分别分析这三个弱点。
Legacy Authenticationd 单边鉴权

Legacy authentication 定义了两个角色 verifier 与 claimant。鉴权的具体流程如下:

首先 verifier 把一个随机数 RAND 发送给 claimant,向它发起挑战。之后 verifier 与 claimant 会各自在本地使用固定的算法 E1 计算 SRES (Signed RESponse):

SRES = E1(link_key, claimant_bd_addr, RAND)

同时 claimant 会将计算得到的 SRES 回传给 verifier。Verifier 则比较该 SRES 与自己计算的 SRES’ 是否相同。如果相同则鉴权通过。

可见 legacy authentication 并未强制要求 claimant 反过来验证 verifier 的身份。那么攻击者可以伪装成 verifier,在不知道 link key 的情况下,略过 SRES’ 与 SRES 的比对,直接让 claimant 通过鉴权。

Secure Authentication 降级

在 2020 年,绝大多数 BD/EDR 设备都支持 secure authentication,且默认启用。具体的鉴权流程如下:

从上图可知这种鉴权方法是双向的,因此 legacy Authenticationd 单边鉴权的弱点不能被直接利用。不过,为了兼容较老的仅支持 legacy authentication 的设备,经典蓝牙允许设备间协商鉴权方法。如果一方设备仅支持 legacy authentication,那么 secure authentication 将不被启用。

具体的,当两个设备的 controller 与 host 都支持 secure connection 特征时,secure authentication 才会被启用。于是攻击者可以伪造不支持 secure connection 特征的设备,即可降级 secure Authentication 为 legacy authentication,从而继续利用旧鉴权方法单边认证的弱点:

Master 与 Slave 角色转换

攻击者在利用 legacy authentication 的单边鉴权弱点攻击目标时,可能并不知道目标的上层应用要求 master 鉴权 slave 还是 slave 鉴权 master,即不确定自己应该扮演 slave 还是 master。

不过,经典蓝牙允许 master 与 slave 的角色转换,具体流程如下:

这样攻击者就可以灵活切换自己的角色,让自己成为 verifier,始终掌握主动权。

总结

需要明确的是,虽然 BIAS 可以绕过鉴权,但它仍不能获取 link key,即无法在鉴权后与目标进行加密数据的交互。不过该限制正好可以被 KNOB 突破,所以 BIAS + KNOB 这套组合拳威力巨大,动摇了经典蓝牙安全的根基。

另外 BIAS 攻击的前提是获取已经与目标设备配对的其他设备地址,这个地址用于发起连接后,跳过配对过程,直接进入存在漏洞的鉴权过程。

References

BIAS

BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 2, Part F page 723, 4.1 AUTHENTICATION REQUESTED

BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 2, Part H page 972, 5 AUTHENTICATION

BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 2, Part H page 982, 6.4 E3-KEY GENERATION FUNCTION FOR ENCRYPTION

点击收藏 | 0 关注 | 1
  • 动动手指,沙发就是你的了!
登录 后跟帖