记录黑客技术中优秀的内容, 传播黑客文化,分享黑客技术精华

实测一款IoT路由的安全性如何?从web到硬件,我们进行了全面的漏洞挖掘和分析(下)

2019-08-25 13:10

EwoPrivKeyHeader.png

上一篇文章,我们讲了IoT路由的设备在理论上的安全性和可能的安全漏洞,本文,我们就来实测一下。

NAND闪存转储

在经历了最初的挫折之后,我们把NAND闪存的焊接都给拆了,并把它和DATAMAN读卡器相连。几分钟后,我们成功地进行了一次Flash转储。为了正确起见,我们转储了两次,结果都是相同的。

28.png

现在我们已经成功进行了NAND转储,这意味着我们可以开始提取固件并开始分析文件的结构了。

首先,我们下载了转储工具,它非常棒,是任何NAND转储的首选工具。

我们在网上搜索了一些关于NAND 闪存芯片组MT29F1G08ABADA的信息。尽管该芯片的说明书上写的是1G的存储空间,但实际上,读卡器的NAND转储量为138.4 MB。

然后我们查了芯片组的idcode。老实说,这花了不少时间搜索,PTP的Dave (@tautology0) 上有许多关于这方面的说明。

29.png

现在让我们看看Binwalk会给我们带来什么输出结果:

30.png

Binwalk是用于搜索给定二进制镜像文件以获取嵌入的文件和代码的工具。 具体来说,它被设计用于识别嵌入固件镜像内的文件和代码。

可以看出,该文件中有许多有趣的部分。让我们先来看看UBI部分,我们将使用DD从dump.bin文件中提取该部分内容。

31.png

提取很顺利!让我们看看它是否真的如此:

32.png

果真是!那我们继续吧!

33.png

一切出乎意料的顺利!

现在已经成功地提取了固件,看起来我们也同时拥有了root文件系统和Ewon应用程序文件系统。

我们将首先介绍Root文件系统,因为我们觉得这将使你能更好地了解Ewon系统是如何构建的。

老实说,“init.d”中只有一个文件是有意义的,这个文件的作用就是启动Ewon服务。“init.d”中没有其他用户,没有ssh的私钥,没有密码哈希。

现在,让我们进入Ewon SquashFS。

SquashFS文件结构看起来像是专门针对Ewon环境的,并安装在/opt/ewon/上。

我们提取的大多数文件夹都是空的,但bin/和patch/文件夹有很多有价值的信息。patch/ folder如下所示:

34.png

patch/folder中的这些文件仅用于从上次运行的固件、一些较新的二进制文件和一些较新的库中进行更新。

35.png

同样,该文件夹的大部分都很无聊,但它确实表明它们经常在设备的更新中添加linux-arm二进制文件和库。

在Andrew (@cybergibbons) 提示之后,我们现在总是扫描文件夹结构来寻找任何可执行脚本(bash脚本):

36.png

这两个文件,虽然都使用了基本的bash脚本,但实际上只提供了构建信息,现在还没有任何帮助我们的东西。

37.png

进入bin/folder试试:

38.png

现在,我们有一个二进制文件,一些配置脚本和一些bash脚本。另外,还有看起来像Java二进制文件和jar文件的文件。我想我们先从配置文件开始,然后再讨论Ewon二进制文件。

配置文件非常简单,正如你所看到的,显然是针对一组不同的运行环境,At91sam9g (AT91SAM9G35是400 MHz的ARM926嵌入式MPU,支持高带宽通信和先进的用户界面),QEMU(可能用于调试目的)和RaspberryPi(同样用于调试和构建目的)。

配置非常相似,大多数值完全相同,只有名称和操作系统相关的内容发生了变化。

以下是all_config.conf文件的一个示例:

39.png

第二行写的是 “所有产品的共同部分”,并列出了Flexy和Cozy Ewon产品,这是否意味着它们是同一种产品?

40.png

虽然有很多相似之处,但也有一些巨大的差异。比如,指在通过互联网提供轻松的远程访问。

此外,就是端口443(HTTPS)。为什么Cozy的浏览器使用https,而Flexy却没有呢?

我们试图运行Java二进制文件,不过它却出错了,我们希望从该文件中,可以确实给我们提供更多有用的信息:

41.png

使用JD-Gui (JD-GUI是一个用于Java编程语言源代码“.class”文件反编译软件,你可以使用JD-GUI中文版浏览和重建源代码的即时访问方法和字段,以代码高度方式来显示反编译过来的代码),我们对它试图访问的JAR文件进行了反编译:

42.png

稍后,我们可能会深入研究该JAR文件,但是现在让我们先来看看Ewon二进制文件。

对Ewon二进制文件进行逆向分析

正如你从之前的截图中看到的那样,我们在NAND 内存转储中并没有看到太多有价值信息。我们希望web界面使用预先构建的工具(如apache2、lighthttpd或nginx)进行设置,并使用vsftpd或类似的工具对FTP进行设置。

逆向二进制文件时,可以直接处理字符串。

我在二进制文件“密码,传递和私有”中,对字符串做了一些基本的grep操作

43.jpg

将二进制文件使用IDA Pro(反汇编工具)分析,可以立即进行反汇编。IDA Pro(并不完美,但却非常实用。

44.png

我们想要调查的第一件事就是对配置文件中的存储值(VPN密钥、密码)进行加密,经过一段时间的搜索,我们发现了这个函数cfgcrypt_DecryptCfgStr。

下面是该函数的IDA布局图:

45.png

以下是更详细的图:

46.png

在Dave的帮助下,我们能够计算出标头“#_1_”使用了什么加密方法。

此外,在实际的Ewon comcfg.txt文件中有一个“CryptMode:1”设置,对我们的分析非常有帮助。

47.png

在此期间,我们没有看到任何此标头的其他变化形式,但是我们认为这就是在Ewon二进制文件中多次出现相同密钥和IV硬编码的原因。

如果CryptMode设置为> 2,则该函数将进行错误输出并将该值设置为0。

48.png

我们相信,如果它设置为“#_0_”,就将使用“blowfish”并且我们使用了Key和IV,但在这种情况下,它被设置为“#_1_”。

那么“#_1_”做什么的呢?

有一个名为“cfgcrypt_CheckCryptmode”的函数,它负责检查加密字符串的标头并根据标头值集返回一个值,记住,它总是被视为“#_1_”。

49.png

然而,这个函数在应用程序中从未被调用。奇怪的是,“cfgcrypt_DecryptCfgStr”函数中有类似的代码库。

50.png

这看起来像是完全的代码重用,因为基本上所有的加密和解密函数都归结为“ctr_encrypt”函数。

51.png

还有就是“ctr_decrypt”函数:

52.png

具体原因我们就不讲了,但“ctr_encrypt”代码中包含一个XOR函数。

对固件进行逆向分析

本文一开始,我们就遇到了固件问题,你可以从Ewon网站轻松下载该固件。

53.png

但仔细观察一下,就会发现加密在起作用:

54.png

很明显,由于版本号、发布日期等都是以明文形式存在,所以它们得题名都是按着顺序来的。

现在想想我们分析过的Ewon二进制文件,可以从中寻找引用固件文件名的任何东西。

第一组结果是对SDcard的引用:

55.png

因此,如果固件出现在SD卡上,它会尝试更新。老实说,这是相当标准的,但是,从用户文档中,你只需将“ewonfwr.edf”文件上传到FTP(如果你有身份验证)。然后,Ewon将根据需要处理固件。

我们花了很长时间寻找一些可以满足我们对固件文件感兴趣的东西,直到偶然发现一个名为“loem_UncryptFile”的函数,它看起来像是在打开一个文件并调用解密功能。

56.png

本质上来讲,正在发生的事情过程如下:Ewon二进制检测固件文件是否上传到ftp服务器或SD卡上,加载清单(检查固件版本、日期等),然后解密固件文件和数据。

57.png

固件加密是基于Blowfish,并且对二进制文件的密钥进行了硬编码。

58.png

现在,找到固件文件。

查看数据后,我们决定加密部分从0x0140h开始,一直继续到文件的末尾。我们在这些位置剪切文件,并尝试使用二进制文件中的给定密钥进行解密。

59.png

我们能够对数据进行适当的解密,但似乎它只解密了一半。这就奇怪了,按说只要方法正确,应该全部解密才是。

查看二进制文件,似乎提供的IV是二进制文件在升级之前创建固件的备份,那么我们需要的这个IV到底在哪里?

为此,我们请教了Dave,Dave表示如果它不在二进制文件中,那就可能在固件中,这显然很常见。

让我们返回固件并查看对应的标头,此时要寻找可以使用的8位数据流。删除加密的垃圾后,这就是我们剩下的,唯一明显的8位数据流是底部突出显示的,后面是一些空字节,然后是固件加密数据。

60.png

然后将其反馈到python脚本中,看看会发生什么:

61.png

现在,才算完全解密!

让我们来看看文件系统,特别是“update.sh”文件:

62.png

“update.sh”文件只是来自于NAND闪存转储的Ewon / opt文件夹。所以,没有新的东西可以挖掘!

63.png

如果有的话,让我们看看位于二进制文件中的进程。

64.png

我们发现了潜在的命令执行!

为此,我们更改了update.sh,重新编译了固件,并重新上传了固件的更高版本号。

65.png

令人恼火的是,这也没有奏效。看起来这是一个CRC文件,因为我们在Ewon日志中得到一个“rift – invalid checksum”错误:

66.png

让我们返回二进制文件检查一下:

67.png

可以看出,有一个CRC16x2校验(CRC是一种常见的校验,而CRC16呢,主要是因为校验结果是16个位)。现在,我们还不能100%确定它是否在固件中的加密blob上,还是在squashfs blob预加密上。SquashFS是一套基于Linux内核使用的压缩只读文件系统。该文件系统能够压缩系统内的文档,inode以及目录,文件最大支持2^64字节。

以下是两个固件版本之间的比较,显然,为了减少差异,我们将每个文件中相同的位设置为相同的。

68.png

红色部分代表标头中的差异之处,再仔细看,我们可以看到两个文件之间的红色区域有一些相似之处。

69.png

让我们在固件文件的加密博客上运行一些CRC校验和,看看是否可以在标头中看到任何相关信息!

Ver 13_2s1 = 8.433 mb (Latest)
CRC16 (encrypted blob) = AF3C
CRC32 (encrypted blob) = F388096F
Ver 13_0s0 = 12,589 mb (Not Latest)
CRC16 (encrypted blob) = A65D
CRC32 (encrypted blob) = 259BC946

输出的信息如下所示:

71.png

这是加密blob的CRC32值,在标头文件中的0x00B0处,让我们尝试修改一下:

72.png

结果发现,修改不成功。最后,又得返回Ewon二进制文件。在搜索二进制文件时,我们遇到了一个函数,它对标头部分做了一个简要介绍。

73.png

“riftp_EDFHeaderPtr”是固件文件的开头,所以我们把它设为“0”。在第144行,如果它不等于v10(CRC16×2的计算结果),就会和rfiftp_EDFHeaderPtr + 168的值进行比较。

在固件中的0xA8处,存在CRC值。太好了!我们还会从二进制文件中的其他信息位中绘制了一些其他位:

74.png

不过,令我们困惑的一件事是CRC计算过程。我们知道它是从二进制代码计算加密blob上的CRC16x2,但计算过程却是如下过程:

75.png

于是,Dave和我们决定重写CRC16x2函数,看看我们能得到什么:

776.png

虽然我们得到了不同的结果,但我们相信我们在朝着正确的方向进行。

利用重写的函数,我们还对固件文件进行了暴力破解,以查看是否有任何部分与标头中存储的值匹配:

77.png

经过测试,没有匹配的部分。

我们尝试了大量不同的CRC16校验,不同的poly对象以及xor位,但没有任何结果。这意味着,我们无法匹配0xA8处的值。

如果你想继续,建议你阅读该链接

漏洞披露时间表

2019-01-29:首次与Ewon联系,并向他们报告了相关漏洞;

2019-02-04: Ewon确认了漏洞; 

2019-05-28:来自Ewon的回复,提供了测试固件;

2019-06-04:对Ewon的漏洞进行公开;

2019-06-18: 更新后的FW 13.3s0开始发布;

缓解措施和建议

1.不要将你的Ewon Flexy或任何ICS设备,接入公共互联网;

2.更改默认凭据;

3.使用适当的访问控制,将你的IT和OT网络进行切割;

4.将免费的Talk2M安全连接云与你的Ewon设备配合使用,HMS Networks公司宣布推出Talk2M® Easy Setup,这是免费VPN客户端eCatcher中的一个新的配置向导。Talk2M Easy Setup仅需USB驱动或SD卡即可让Ewon® Cosy在线实现Talk2M安全远程云端连接。 在Talk2M Easy Setup中,新的向导可引导用户完成最普通的Internet连接设置。设置完成后,可以将生成的配置文件保存在本地PC、USB闪存盘或SD卡上。最后,将存储介质插入到对应的Ewon产品中,之后路由器就能连接到Talk2M Secure Cloud了。 

5.更新你的Ewon Flexy固件并使其维持最新版本;

6.如果你无法更新ICS(例如,设备太旧),请考虑围绕它构建额外的安全控制。

本文翻译自:https://www.pentestpartners.com/security-blog/ewon-flexy-iot-router-a-deep-dive/如若转载,请注明原文地址: http://www.hackdig.com/08/hack-55843.htm
知识来源: https://www.4hou.com/web/18708.html

阅读:30027 | 评论:0 | 标签:Web安全 IOT 漏洞挖掘 漏洞

想收藏或者和大家分享这篇好文章→复制链接地址

“实测一款IoT路由的安全性如何?从web到硬件,我们进行了全面的漏洞挖掘和分析(下)”共有0条留言

发表评论

姓名:

邮箱:

网址:

验证码:

公告

关注公众号hackdig,学习最新黑客技术

推广

工具

标签云