欢迎访问Sunbet官网(www.sunbet.us),Allbet欧博官网(www.ALLbetgame.us)!

首页Sunbet_安全预警正文

【胖猴小玩闹】智能门锁与网关: 海康萤石智能门锁的网关分析(四)

admin2020-08-20102技术

系列文章请点击查看《专题》

1.简介

本篇是关于海康萤石智能网关分析的第4篇,应该也是关于海康萤石智能网关的最后一篇,原计划是再多分享点内容,但鉴于胖猴实验室和海康的良好关系,把海康萤石的网关设备分享得非常透彻也不太好。其实,在此前的3篇文章中,我们已经完成了固件编辑和重打包,通过telnet登陆固件系统,以及使用gdbserver调试程序,在此基础之上,相信读者完全可以对设备固件进行独立分析了。

在这海康萤石智能网关的最后一篇文章中,我们就把上次的遗留问题处理了,即设备的认证方式以及加密密钥生成方法。

2.程序分析

2.1 概述

在上一篇的结尾部分,我们已经具备了调试能力,可以调试固件中的davinci程序以及libmicrokernel.so.1等动态连接库。为了节约篇幅,在本篇中我们先将一些分析结论与各位分享,然后再详细调试其中的某个细节。

在海康萤石的智能网关中,完整的通信流程涉及到3个密钥,分别是share key、master key以及session key。顾名思义,share key是智能网关与litedev服务器(与之对应的另一个服务器是MQTT服务器)共有的密钥,由设备序列号等常量经过多次MD5运算得到,每个智能网关设备的share key都是独一无二的,;master key是智能网关与litedev服务器经过密钥协商而来,用于加密传输session key,关于master key的密钥协商过程就是本篇分析的重点内容;最后session key是智能网关与MQTT服务器通信时使用的加密密钥,该密钥由litedev服务器直接下发给智能网关。

以上三个密钥在使用过程中,share key是与设备绑定,且固定不变的,一旦获取了share key,就可以完成所有的认证过程,最终被海康萤石认定为合法的网关设备;使用者通过手机app绑定智能网关时,会经过密钥协商生成master key,每绑定一次会就更新一次;最后的session key则每次运行davinci程序时,都会更新,这也意味着每次重启网关都会更新session key。三个不同级别的密钥,三个不同的密钥生存周期。

在对海康萤石智能网关的密钥体系有所了解之后,我们就可以聚焦到某些细节上,下面来着重看一下master key和share key的生成过程。

2.2 master key生成

2.2.1 认证细节分析

为了触发智能网关的密钥协商流程,我们需要先删除当前的master key,具体讲就是删除 “/cfg/dev_masterkey”文件,如下图所示:

【胖猴小玩闹】智能门锁与网关: 海康萤石智能门锁的网关分析(四)  技术 第1张

图2-1 删除dec_masterkey文件

删除当前master key之后,继续按照上一篇所述的方法启动调试器,并在上一篇结尾时提到的send_authentication_i函数下断点,等到程序中断到调试器中,如下图所示:

【胖猴小玩闹】智能门锁与网关: 海康萤石智能门锁的网关分析(四)  技术 第2张

图2-2 程序中断在send_authentication_i函数

通过逆向分析该函数,可以获知它调用的common_serialize和authentication_i_serialize用于构造将要发送的数据。我们在common_serialize函数之前下断点,然后用gdb命令查看待发送数据的内容(本次调试时,地址为0x007d2dd0),如下图所示:

【胖猴小玩闹】智能门锁与网关: 海康萤石智能门锁的网关分析(四)  技术 第3张

图2-3 第一次打印发送数据

在上图中,可以看到待发送数据内容还是空的。待函数common_serialize执行完毕之后,重新打印该地址的数据,如下图所示:


图2-4 第二次打印发送数据

该地址的前几个字节已经被赋值了。继续调试该程序,在authentication_i_serialize函数之后下断点,待程序中断时,重新打印该内存处的数据,如下图所示:

【胖猴小玩闹】智能门锁与网关: 海康萤石智能门锁的网关分析(四)  技术 第4张

图2-5 第三次打印发送数据

可以观察到,authentication_i_serialize函数执行完毕之后,待发送数据基本构造完毕。我们对比一下本次发送数据和之前我们通过wireshark抓包获取的发送数据,如下图所示:

【胖猴小玩闹】智能门锁与网关: 海康萤石智能门锁的网关分析(四)  技术 第5张

图2-6 此前wireshark的抓包结果

可以看到,本次构造的发送数据与之前的抓包结果是有一小部分相同的,而不同的这部分应该就是海康萤石智能网关密钥协商的关键部分。

为了找到产生不同的原因,我们来重点逆向authentication_i_serialize函数,可以在该函数中发现其调用了一个签名函数digital_sign_serialize函数:

【胖猴小玩闹】智能门锁与网关: 海康萤石智能门锁的网关分析(四)  技术 第6张

图2-7 authentication_i_serialize函数的内部

在该签名函数之前和之后下断点,可以观察到需要签名的数据以及签名结果。结合之前用gdb调试send_authentication_i时获得的发送数据,就可以分析出发送的数据格式如下:


图2-9 send_authentication_i函数发送的数据格式

其中,dev_subserial是设备序列号;random_1是1字节随机数,每次密钥协商时都是不同的。由于random_1字节的不同,导致了digital_sign不同,所以总共有33(1+32)字节是每次通信都不同的。经过本次通信,智能网关将random_1参数上传至litedev服务器。

通过类似的分析方法,就可以获知认证过程中的其他3个函数的作用,这3个函数分别是:wait_authentication_ii、send_authentication_iii以及wait_authentication_iv。加上send_authentication_i函数,网关和服务器之间总共同步了4个随机数。

2.2.2 认证完整过程

在上述的分析过程中,可以发现一个名为lbs_affair的结构体贯穿了整个认证过程,4个随机数也保存在结构体之中,该结构体的内容如下:


表2-1 lbs_affair结构体

其中,random_1和random_3由智能网关生成,发送给服务器;random_2和randon_4由服务器生成,发送给智能网关。

通过这4个随机数以及share key就可以生成master key了,并进一步由master key获取session key。其master key的生成算法比较简单,可以在generate_masterkey函数中找到,如下图所示:


图2-10 master key的生成过程

根据图中红框标出的偏移可以知道,master key的生成过程就是将random_1、random_2、random_3、random_4和share_key拼凑在一起,然后调用sha512函数,其hash结果就是最终的master key了。

继续分析其固件的后续内容可以发现以master key作为密钥,使用aes cbc算法解密session key相关的代码段,这里就不截图了。获取session key之后,通信数据的加密密钥就完全切换为session key,不再使用master key了。

2.3 share key生成

相比于master key的生成过程,share key的生成无疑简单了很多。可以在generate_sharekey函数中找到关于share key的各种运算,通过阅读IDA反汇编后的代码,可以确认share key是通过对dev_subserial和dev_verification_code以及一个固定的盐进行多次MD5而得到,其中dev_verification_code是设备的认证码,该认证码被贴在海康萤石智能网关背面的标签上。在md5运算过程中,固定的盐值如下图所示:

【胖猴小玩闹】智能门锁与网关: 海康萤石智能门锁的网关分析(四)  技术 第7张

图2-11 share key的生成过程

上图中,“ 88075998”是海康的联系电话,在此处,“www.88075998.com”作为盐参与了第二次MD5运算中。

3.小结

到此,关于海康萤石系列的四篇文章就结束了。在前3篇文章中,我们分别解决了开启uart串口、提取flash内容、固件重打包、gdb调试等问题;而在最后1篇中,我们分析了海康萤石的密钥体系,虽然写的有些模糊,但基本上涵盖了所有关键点,很多海康和萤石的其他IoT设备也使用了类似的密钥体系,本篇分析可以提供一个借鉴。其实关于海康萤石智能网关还有很多可以写的内容,但实在不适合在这里公开的与大家分享,还是等有机会私下交流吧。

在笔者分析海康萤石智能网关时,Ghidra尚未发布且IDA尚不支持mips decompiler,但在写本文时已经出现了很多好用的工具,合理利用这些工具可以大幅度减少分析工作量。最后,希望本篇文章能给各位读者带来一些收获。在本专题的后续文章中,我们还会继续分享其他的研究案例,敬请期待。

Yimi Hu & Light @ PwnMonkeyLabs

本文为 胖猴实验室 原创稿件,授权嘶吼独家发布,

Jenkins服务器漏洞致敏感信息泄露

Jenkins是一个开源的自动化服务器软件。近日,Jenkins发布安全公告称Jetty web服务器中存在安全漏洞,攻击者利用该漏洞可以引发内存破坏和机密信息泄露。该漏洞CVE编号为CVE-2019-17638,CVSS 评分为9.4,影响Eclipse Jetty 9.4.27.v20200227 到 9.4.29.v20200521版本。Eclipse Jetty是一个提供Java HTTP服务器和软件框架中使用的web容器的全特征工具。 Jenkins绑定了Winstone-Jetty,使用java -jar jenkins.war启动时作为HTTP和servlet 服务器。这也是使用任意安装或包时Jenkins的运行原理。 漏洞允许非认证的攻击者获取HTTP 响应header,其中可能包括其他用户的敏感数据。该漏洞影响Jetty 和Jenkins Core,是Jetty 9.4.27版本中引入的,其中加入了严重处理HTTP 响应header和预防缓冲区溢出的机制。 为解决这一问题,Jetty抛出一个异常来生成HTTP 431错误,导致发布的HTTP响应header到缓存池2次,引发内存破坏和信息泄露

网友评论