gejigeji Web安全 2019年8月25日发布

收藏

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

NAND闪存转储

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

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

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

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

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

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

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

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

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

果真是！那我们继续吧！

一切出乎意料的顺利！

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

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

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

现在，让我们进入Ewon SquashFS。

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

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

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

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

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

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

进入bin/folder试试：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以下是更详细的图：

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

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

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

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

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

那么“＃_1_”做什么的呢？

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

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

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

还有就是“ctr_decrypt”函数：

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

对固件进行逆向分析

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

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

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

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

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

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

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

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

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

现在，找到固件文件。

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

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

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

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

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

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

现在，才算完全解密！

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

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

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

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

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

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

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

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

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

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

让我们在固件文件的加密博客上运行一些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

输出的信息如下所示：

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

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

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

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

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

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

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

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

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

我们尝试了大量不同的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（例如，设备太旧），请考虑围绕它构建额外的安全控制。