浅析Zigbee协议与应用安全

前言

说得非常浅请见谅,因为这个用来讲ppt所以顺便写到云笔记和博客上归档一下,后附一些较为详细的参考资料

一般一个物联网/工控网络的攻击面:

可能的攻击面:“云网端”

平台层:云端、管理应用

网络层:网络通信设备

感知层:硬件设备以及软件程序

zigbee就是处在感知层和网络层之间的通信协议,作为和设备直接通信的门户,针对zigbee协议可以做到的事情有:

操控设备进行某些操作

获取设备rootshell,并且长期驻留

攻击内网里面的其它物联网或者pc、服务器设备

至于受限于100m的传输范围,其实我们可以拓宽一下思路,比如使用无人机来搭载zigbee的发射模块?

现状就是很多很多设备的zigbee协议没有做到最好,即使做到最好,那也有可能被某些问题导致其安全性受损,接下来尝试浅析一下zigbee协议本身和落地应用的安全

zigbee协议简介

作为一种自组网、低功耗、短时延、自愈能力强、可容纳大容量节点的局域网通信技术,Zigbee主要使用在智能家居、各类工业或者城市的传感器场景,而且芯片便宜,非常适合大规模部署的设备

有两个原因使得Zigbee网络和通信通常被认为难以受到攻击:

1)Zigbee网络具有封闭性质,配备了专用的调试流程来将新设备添加到网络中。除调试外,Zigbee网络处于关闭状态,控制器不会处理加入请求。来自未经授权设备的数据包将被拒绝。

2)Zigbee协议使用AES算法加密和CCM*模式认证来保护应用层(即网络层的有效负载)。如果没有正确的安全密钥(在调试期间交换),攻击者无法渗透Zigbee系统。

但真实情况恐怕并非如此

Zigbee三种安全模式

1、非安全模式:不采取任何安全服务策略,默认,仅适合调试;

2、访问控制模式:通过访问控制列表限制非法节点获取数据,但不对传输进行加密;

3、安全模式:不仅进行访问控制,也采用AES 128位加密算法进行通讯加密

接下来仅讨论第三种情况,因为前两种情况安全性非常差,仅仅适合用于调试而非部署,

对其进行安全性的分析,可以不关注通信层面繁多的知识 ,而应该重点关注:网络层、应用层如何做认证

Zigbee如何实现传输安全

zigbee很早就考虑到了传输安全问题,使用AES128的加密传输措施以及CCM模式认证,对网络层的payload进行加密传输,数据帧的封装情况如下

物理层-数据链路层-网络层(NWK,Network)

最后使用MIC(MessageIntegrity Code)验证数据完整性,类似于CRC校验

在2003年,Jakob Jonsson已经证明了AES-CCM在隐私性和真实性方面的安全性与其他提议的模式(如OCB)一致。

因此,还是研究Zigbee认证机制的安全性显得更为有意义。

Zigbee协议的两个安全密钥

要了解Zigbee协议网络架构安全性的区别,首先又要了解以下两种密钥

NetworkKey网络密钥

网络层的唯一密钥(zigbee局域网的门户)NetworkKey网络密钥,用来保证网络层的安全传输,主要用在广播通信,每个节点都要有网络密钥才能与其他节点安全通信。

可以是通过网络设备向信任中心发出请求,要求将密钥发送给它获得

LinkKey链接密钥

应用层端到端加密的两两之间独立密钥:

LinkKey链接密钥,如果节点之间希望进行通信,则节点需要向信任中心请求一个链接密钥,用来保证端到端的安全

Zigbee协议安全模型

分为以下两种模型

集中式安全模型:复杂但最安全的模型

分布式安全模型:简单,但是安全性较低。

Zigbee分布式网络(mesh组网)

分布式安全模型(mesh组网)为什么安全性较低?

网络中的所有节点都使用相同的网络密钥Network Key来加密消息。

为了配置方便,所有节点在注册入网络之前都已预先配置了一个链接密钥Link key,用于在注册过程中加密传输网络密钥(Network Key)。

攻击者只需获取一个节点的网络密钥,即可解密和伪造该网络中所有节点之间的通信。

不推荐使用这种不安全的网络,如果一定要使用,做好密钥的保密和防窃听工作吧

Zigbee集中式网络

集中式安全模型提供了更高的安全性,因为集中管理所有安全策略和密钥分发和周期性的更新,能有效地防止密钥的重用、未经授权的设备加入网络,

并且每组通信使用新协商的link key链接密钥,这也让敌手无法通过单点的设备来解密整个网络的通信

接下来尝试浅析集中式网络这一网络架构的安全性

Zigbee的密钥分发过程

Link key链接密钥分发

如果网络里面设备A想和设备B进行通信,这个过程是没有太大问题的

整个过程都使用Network key进行AES加密的通信来进行

Zigbee1.0和Zigbee2.0的Network key分发

但是问题恰恰就出在Network key的分发上面

首先向父节点路由发送MAC关联请求。 如果关联成功,则设备处于已加入但未认证状态

父节点给设备发送MAC关联成功的响应之后,再向Trust Center发送更新设备消息,指示新节点希望加入ZigBee网络。

然后由Trust Center决定是否允许设备加入。如果允许该设备加入,Trust Center则向父节点发送Network Key

Zigbee1.0和Zigbee2.0的严重安全问题

由于入网前新设备不知晓任何密钥信息,所以此处有Network密钥的明文分发过程,然而,Zigbee1.0和Zigbee2.0在这部分是明文传输的

这造成敌手可以监听这部分的流量,从而截获Network Key,并且已经有成熟的工具,如Killerbee,Zigator,Attify Zigbee Framework

有不少厂商甚至直接采用链接密钥的默认值:5A69 67 42 65 65 41 6C 6C 69 61 6E 63 65 30 39,ASCII转换过来就是:ZigBeeAlliance09

Zigbee3.0的Network key分发

zigbee3.0做了一些安全上的改进,例如:

ZigBee 3.0的设备在出厂的时候,必须固化一个预定义链接密钥(Preconfigured Link Key,有时候也被称作installation code)用于密钥分发,然后通过带外的(设备底座贴纸,或者扫二维码)密钥分发,

虽然简单,但这对无法物理接触设备的敌手来说有奇效

引入新的认证模式,是否真的足够安全?

协议设计很美好,实现起来无懈可击仍然不易,有很长一段路要走

再次从云网端出发,反向思考对zigbee协议的攻击面

目前能想到的有

• 厂商配置

• 管理应用的缺陷

• 干扰zigbee协议工作,造成信息泄露

• 代码实现/硬件上的缺陷

厂商配置

配置错误,造成协议无法发挥其安全能力

使用Zigbee版本,是否是最新的3.0?

使用了Zigbee3.0,是否启用最高的安全等级?

使用最高的安全等级,是否启用预定义的链接密钥?

是否在管理端应用、终端应用上存在某些让Zigbee不够安全的实现?

管理应用的缺陷

需要扫二维码来获取install code 将设备加入网络

在跳过情况下,Zigbee协调器使用默认的“信任中心”链接密钥(ZigBeeAlliance09)来加密“传输密钥”命令。一切又回到了Zigbee2.0

干扰zigbee协议工作,造成信息泄露

针对未加密字段进行信息收集,假设敌手能够接入网络,可以发送特制的数据包并观察返回的区别来进行信息收集,了解网络拓扑、网络数据帧nwk payload包含的指令,从而让攻击者知道更多信息以计划进一步的攻击

如下图,在加入网络后,可以根据nwk payload长度、跳数、来源的机器种类等信息,来知晓被加密nwk payload内包含的指令

类似的研究还有很多:

敌手可通过引起PAN ID冲突观察设备响应,Zigbee3.0会有不一样的响应。

敌手可利用注入信标请求并观察响应,来区分Zigbee路由器和协调器。

设备的扩展地址是全球唯一的64位IEEE地址,包含组织标识符。可借此缩小可能的硬件设备种类范围。

……

代码实现/硬件上的缺陷

Zigbee的协议解析应用层的消息的相关实现的程序错误,可能会造成安全问题:

代码实现缺陷

CVE-2020-6007 (菲利普智能家居的bridge组件解析Zigbee应用层消息时,由于错误地处理类型,造成堆溢出,导致可以通过zigbee网络远程获取设备shell)

硬件上的缺陷

CVE-2020-27892(Texas Instruments CC2538工业控制芯片 在解析Zigbee应用层消息时,由于没有正确处理ZCL Discover命令接收后的响应信息造成dos)

对于工业控制系统而言,dos会让其损失可用性,这已足够致命

参考资料

这个可以看看zigbee安全相关的标志位的细节https://www.digi.com/support/knowledge-base/zigbee-3-0-security

故障注入,干扰https://www.anquanke.com/post/id/210403#h3-12

适合刚开始看https://blog.csdn.net/qq_32505207/article/details/107682978

killer bee相关用法的很好的展示,比如https://anquan.baidu.com/article/431

如果使用默认link密钥,即使是zigbee3.0也可以做一些事情https://www.freebuf.com/vuls/372429.html

zigbee的zcl协议解析不当造成的MIPS架构下ulibc的堆溢出,很罕见也很精彩https://research.checkpoint.com/2020/dont-be-silly-its-only-a-lightbulb/

这篇文章对zigbee3.0的安全改进的概括是比较完整的https://www.ebyte.com/new-view-info.html?id=2170

评论

  1. Nop
    2 月前
    2024-8-27 14:25:28

    666666666666

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇
粤ICP备20015830号