0x0B 逆向分析Ewon文件
根据之前的截图，我们无法在NAND Flash转储文件中找到太多信息。我希望系统会使用预设的工具（如apache2、lighthttpd或者nginx）来设置web接口，或者使用vsftpd及其他解决方案来设置FTP服务。幸运的是，当开发者决定使用自己定制的服务版本时，可能会忽略掉许多安全功能或者保护措施。
逆向分析二进制文件时，我们很自然就会搜索其中包含的字符串。
我在文件中简单grep搜索某些字符串，比如password、pass以及private，回头我们再来分析搜索出的结果。
利用IDA Pro分析二进制文件，获取反汇编代码。结果并不是特别完美，但至少能给出一些信息。
首先我想澄清的就是配置文件中加密存储的值（VPN秘钥、密码）。
一番搜索后，我找到了一个函数：cfgcrypt_DecryptCfgStr。
该函数在IDA中的布局图如下：
详细布局如下：
在Dave小伙伴（人形自走反汇编器）的帮助下，我们发现#_1_可以表示正在使用的是什么加密算法。
此外，在Ewon的comcfg.txt文件中有一项设置：CryptMode:1，刚好与我们的判断相符。
此时我们还没有看到配置文件中有其他可变值，但相信我们的研究方向没有问题，因为Ewon二进制文件中硬编码了许多相同的秘钥及IV（初始向量）。
如果CryptModd设置>2的值，那么函数就会输出错误消息，将这个值设置为0。
我认为如果是#_0_，那么设备就会使用blowfish加密算法，我们也拿到了算法所使用的秘钥及IV，然而这里设备使用的是#_1_。
那么#_1_的具体代表的是什么？
固件中有个cfgcrypt_CheckCryptmode函数，该函数会检查加密字符串的头部，根据头部值返回一个结果值。
然而设备永远不会调用这个函数，这一点比较奇怪，但cfgcrypt_DecryptCfgStr函数中有一个相似的代码结构。
似乎设备会在多个地方复用代码。
最终所有的加密及解密函数都会汇聚到ctr_encrypt函数。
ctr_decrypt函数代码如下：
这里我不会讨论具体细节，只需要知道ctr_encrypt代码中包含一个XOR函数。
0x0C 逆向分析固件
一开始我就被固件困住了脚步，我们可以从Ewon官网上下载到这个 固件：
当想详细分析固件时，我们发现固件经过加密处理：
文件头部较为清晰，包含版本号、发布时间等都以明文表示，但后面就是一些看不懂的数据。
因此回到Ewon二进制文件，查找引用了固件文件名的部分数据。
首先我们可以找到对SD卡的引用：
因此，如果SD卡上存在固件，那么设备就会尝试更新。这一点非常正常，然而根据用户文档，我们可以将ewonfwr.ed文件上传到FTP（如果通过身份认证的话），随后Ewon就会根据需要处理固件。
我在固件文件中搜索满足这些处理逻辑的内容，最终找到了一个函数：loem_UncryptFile。该函数似乎会打开一个文件，然后调用解密函数。
Ewon程序会检查固件文件是否已上传到ftp服务器或者SD卡中，加载manifest信息（检查固件版本、日期等），然后解密固件文件及数据。
固件加密基于Blowfish算法（程序中大量引用了这个算法），并且程序中硬编码了加密秘钥。
非常棒，那么我们再次回到固件文件。
查看数据后，我判断加密数据从0x0140h开始，直到文件结尾。将这部分内容拷贝出来，尝试使用程序内置的秘钥进行解密。
我们的确能解出一些数据，但似乎只能解密一半数据，这一点非常奇怪，但至少我们的方向没有错。
回到二进制程序中，似乎程序会使用这个IV，在升级前备份固件，那么这个IV究竟在哪？
Dave又站了出来，提示我如果这个值不在程序中，那么很有可能在固件中，这一点非常正常。
再次回到固件上，查找头部数据。我们来寻找可以使用的8bit据流。删除加密后的无关信息后，我们留下了一部分数据，比较明显的8bit数据流就位于数据末尾（下图高亮部分）：
将这个值输入python脚本中，观察运行结果：
现在我们终于解出完整数据。
来观察文件系统，特别是update.sh文件：
这里似乎出现了很多文件，但实际上只是NAND Flash转储数据中Ewon的/opt目录，因此这里并没有什么新的信息。
再来观察update.sh：
非常好，来具体看一下程序的处理逻辑，能否找到有趣的点：
我看到可能存在命令执行点！
我修改了update.sh，重新生成固件，然后设置成高版本后重新上传该固件：
令人失望的是，这种方法无法奏效。似乎设备会对该文件执行CRC校验，因为我们在Ewon日志中找到了“riftp-Invalid checksum”错误：
再次回到程序逻辑上来：
这里包含一个CRC16x2校验。我不能百分版确定校验针对的是固件的加密数据，还是针对加密前的squashfs数据。
来对比两个固件版本。我将两个文件中共同的部分设置为相同值，以减少文件存在的差异：
上图中红色部分数据就是头部中存在差异的数据。
进一步分析后，我看到两个文件中红色区域仍有一些相似性：
在固件文件的加密数据上执行一些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
似乎有所收获！
这正是加密数据对应的CRC32值！正是在头部文件中！在0x00B0处！我们来稍微修改一下，看一下改动后的校验结果：
好吧，还是有些地方不对。
让我们再次回到Ewon程序中。当在程序中搜索时，我发现有个函数会涉及到一些头部数据：
这里riftp_EDFHeaderPtr是固件文件的开头处，因此为0。
在144行，代码会比较rfiftp_EDFHeaderPtr + 16的值，判断这个值是否等于v10（CRC16 x 2校验值）。
比较困惑我（和其他小伙伴）的一个点就是CRC校验函数。从二进制代码中，我们知道（或者至少认为）程序正在计算加密数据块的CRC16x2校验值，但具体计算逻辑如下：
Dave和我决定重新CRC16x2函数，看一下能得到什么结果：
虽然我们得到的结果不大一样，但我们认为已经非常接近事实真相了。
此外我们还对固件文件进行暴力尝试，想看看是否有任何数据与头部中存储的值相匹配：
不幸的是，这也是我们研究的终点，不能再进一步。
我们尝试了各种不同的CRC16校验方法，不同的xor位等，但得不到更进一步的结果，无法匹配0xA8处的值。
这个过程中我们使用了pycrc，这款工具非常强大，帮我们省了不少功夫。
0x0D 披露时间线
2019-01-29 首次联系Ewon反馈漏洞
2019-02-04 官方确认漏洞并预估处理时间节点
2019-02-11 PTP与Ewon都认为处理周期有点长
2019-05-23 在最终披露前进行协商
2019-05-28 Ewon反馈并提供测试固件
2019-06-04 Ewon披露相关公告
2019-06-18 PTP披露相关公告，现在大家可以在此处下载更新版的FW 13.3s0
我们在2019年1月29日向EWon Flexy的制造商HMS Networks报告了相关情况。整个过程略微曲折，但最终官方确认并修复了漏洞，这里不再赘述。
0x0E 缓解措施及建议
用户角度
不要将Ewon Flexy（或者任何ICS设备）放在公开互联网中，这会引来不必要的麻烦。
记得修改默认凭据。
分段规划IT及OT网络，部署适当的访问控制机制。
厂商角度
HMS有一个安全远程访问解决方案：Talk2M，应该能缓解这个问题。
我们还没测试过Talk2M，无法发表关于安全性方面的意见，但添加一个防御层始终不算坏事。有空时我会分析一下新的固件。
修复bug后的新固件可从此处下载。
我们的建议
更新Ewon Flexy固件，升级到最新版。
同时记得更新所有的工控系统。如果无法更新ICS（版本太老、官方不再支持或者过于关键无法改动），可以考虑针对性部署额外的安全控制机制。
0x0F 总结
我不想草草结束这篇文章，回头我会发表第二篇分析文章。
整个研究过程比较曲折，我个人也学到了许多知识。现在我非常喜欢IDA，但我使用Ghidra的次数越来越多（这是款免费产品，某些地方更加方便）。
Ewon Flexy是一款非常不错的设备，这个研究过程也是我自己想看一下我的能力范围，还有哪些地方需要提高等。
如果我成功构造出能够正常工作的固件，那么后续会有更多研究成果可以公布。