上次发文章还在上次（近一年前了），当时写的好稚嫩啊2333，各位大师傅看我这篇文章应该也会有同样的感受吧hhh想来上一次挖洞还在一年前的大一下，然后就一直在忙活写论文，感觉挺枯燥的（可能是自己不太适合弄学术吧QAQ），所以年初1~2月的时候，有空的时候就又会挖一挖国内外各大知名厂商的设备，拿了几份思科、小米等大厂商的公开致谢，也分配到了一些CVE和CNVD编号，之后就没再挖洞，继续忙活论文了QAQ。某捷算是国内挺大的厂商了，我对其某系统进行了漏洞挖掘，并发现了一个可远程攻击的未授权命令执行漏洞，可以通杀使用该系统的所有路由器、交换机、中继器、无线接入点AP以及无线控制器AC等众多设备，危害还是相当严重的。根据厂商的要求，在修补后的固件未发布前，我对该漏洞细节进行了保密。如今新版本固件都已经发布，在这里给大家分享一下这一次的漏洞挖掘经历（包括固件解密、仿真模拟、挖掘思路等），希望能给各位师傅带来些许启发（大师傅们请绕道QAQ）。声明： 本文仅供用于安全技术的交流与学习，文中涉及到的敏感内容都进行了删减或脱敏处理，仅分析了漏洞链。若读者将本文内容用作其他用途，由读者承担全部法律及连带责任，文章作者不承担任何法律及连带责任。CVE编号：CVE-2023-34644 / CNVD编号：CNVD-2023-682492023-02-27：发现漏洞，并将该漏洞上报给了厂商
2023-02-28：厂商确认了漏洞，并启动了应急响应，开始修补并内测
2023-03-06：厂商给予了一定的奖励（不过有点少QAQ）
2023-05-24：厂商修复了所有影响的设备并发布了安全通告及致谢安全通告：
028K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6%4N6%4N6Q4x3X3g2J5N6h3W2B7K9h3g2Q4x3X3g2U0L8$3#2Q4x3X3g2U0L8W2)9J5c8X3N6&6i4K6u0r3P5s2N6Q4x3X3c8S2M7i4c8Y4i4K6u0V1k6%4N6Q4x3V1j5&6x3e0x3^5z5g2)9J5c8R3`.`.
abfK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6%4N6%4N6Q4x3X3g2J5N6h3W2B7K9h3g2F1k6i4c8%4L8%4u0C8M7#2)9J5k6h3y4G2L8g2)9J5c8Y4y4#2M7s2m8G2M7Y4c8Q4x3V1k6K6k6h3y4#2M7X3W2@1P5f1u0#2L8r3I4W2N6r3W2F1M7#2)9J5c8X3y4&6j5X3g2J5M7$3g2U0N6i4u0A6N6s2W2Q4y4h3k6T1N6h3I4D9k6i4c8A6L8Y4y4Q4x3V1j5I4x3o6l9H3x3b7`.`.CVSS 3.1评分：9.8（严重，CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H）可以从厂商官网下载到最新固件，然而可以发现其中的固件大多都是加密的，用binwalk是无法解开的：
这大概是想要分析该固件所需迈过的第一道坎了，不过好在还是比较容易解密的。原因在于，只是大部分固件都被加密了，但是仍有少部分固件（或过渡版本的固件）并未加密，很容易想到这些固件升级的过程中肯定也会使用到解密的程序，因此可以通过解开这些未加密固件，找到解密程序，并逆向分析出相关算法，这也是固件解密最常用的一种手段。并且，一般一个厂商的固件加密算法都是相同的，故这样所有的固件我们都能够解开了。此时，我们惊喜地发现xxx系列产品的xxx型号固件并没有被加密，可以成功解开。然而，如何找到固件的解密程序呢？显然，固件的解密操作肯定是在刷固件之前进行的，因此我们可以查找OpenWrt中用于刷固件的mtd命令进行定位：
很显然，此处的rg-upgrade-crypto自然就是我们所要找到固件解密程序，并找到它的路径/usr/sbin/rg-upgrade-crypto，对其逆向分析。（由于该加解密算法仍然被广泛应用于某捷的各类核心产品中，故这里不放出具体逆向分析的过程，此处省略xxx字........）后注： 有很多师傅在问我，找不到过渡版本的固件怎么办？常见的可以考虑是简单的异或加密，对于本固件来说，可参考：https://bbs.kanxue.com/thread-278816.htm#msg_header_h2_1 ，我和ZIKH26师傅简单说了一下，ZIKH26师傅记录的也很详细，我这里就不再赘述了。因此，我们只需要根据rg-upgrade-crypto写出解密脚本，即可成功解开固件了：
之后，解开不同类别、不同型号设备的固件，可以发现众多设备均使用的是该系统，因此只要挖出一个洞，就可通杀所有设备了。由于授权洞的实际影响并不算太大，所以我们期望挖出未授权远程命令执行漏洞。此部分以xxx固件为例进行分析，该固件是aarch64架构的。其他固件也许架构或部分字段的偏移不同，但均存在该漏洞。显然，此类固件的cgi部分是用Lua所写的。我们既然想要挖未授权的漏洞，那么首先就要找到无鉴权的API接口，定位到/usr/lib/lua/luci/controller/eweb/api.lua文件。可以看到，只有对/cgi-bin/luci/api/auth发送请求的时候，不需要权限验证：根据调用的rpc_auth函数，可见此处对应的处理文件是/usr/lib/lua/luci/modules/noauth.lua：进一步分析/usr/lib/lua/luci/utils/jsonrpc.lua中的handle及其相关函数，可以得知这里通过JSON数据的method字段定位并调用noauth.lua中对应的函数，同时将Json数据的params字段内容作为参数传入（由于与该漏洞原理关系不大，此处不展开分析）。在noauth.lua中，有login，singleLogin，merge和checkNet四个方法。其中，singleLogin函数无可控制的参数，不用看；checkNet函数中参数可控的字段只有params.host，并拼接入了命令字符串执行，但是在之前有tool.checkIp(params.host)对其的合法性进行了检查，无法绕过。再来看到login登录验证函数，这里可控的字段乍一看比较多，比如params.password，params.encry，params.limit等字段。其中，对params.password字段用tool.includeXxs函数过滤了危险字符，故大概率之后会有相关的命令执行点。再来看到继续调用的tool.checkPasswd函数（在/usr/lib/lua/luci/utils/tool.lua中），其中检测了传入的encry和limit字段的真假值，并在这两个字段中写入了相应的固定字符串，checkStat.username又是传入的固定用户名admin，因此真正可控的只有password字段，并调用了cmd.devSta.get函数进一步处理。然而，虽然password字段用includeXxs函数
...(已截断)
---
来源: 看雪论坛
原文链接: https://bbs.kanxue.com/thread-277386.htm