[原创]GL-iNet路由器安全分析

前段时间看到复现分析GL-iNet路由器CVE-2024-39226漏洞的两篇文章[原创]GL-iNet路由器 CVE-2024-39226 漏洞分析 ，CVE-2024-39226 GL-iNet 路由器RPC漏洞复现，看完也跟着了分析下，固件仿真过程踩了一些坑，开始我直接用Ubuntu24的qemu-system-arm跟着操作都会出现错误”Cortex-A9MPCore peripheral can only use Cortex-A9 CPU”，摸索了挺久发现文章用的都是debian_wheezy_armhf来仿真，但太老了以至于直接跑GL-iNet固件会出现Illegal instruction的错误，就使用Ubuntu18安装的低版本qemu-system-arm，能绕过来指定仿真开发板非支持的cpu，qemu在高版本中修复了这个问题，就出现了新些版本Ubuntu安装的qemu-system-arm启动报错问题。 后面琢磨了下，用低版本qemu-system-arm来绕过不算是好方法，试了试换个高版本内核镜像仿真就行了，可以花些时间自己制作一个，我是直接用开箱即用制作好的(edfK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6H3k6h3!0H3L8r3g2Q4x3X3g2V1k6h3u0A6j5h3&6Q4x3X3g2G2M7X3N6Q4x3V1k6Q4y4@1g2Y4K9h3!0Q4x3V1k6V1M7h3W2T1i4K6u0r3i4@1f1@1i4@1t1^5i4@1q4p5i4@1f1%4i4K6W2m8i4K6R3@1j5i4u0E0K9r3k6Q4x3X3c8$3K9i4u0@1i4K6t1&6i4@1g2r3i4@1u0o6i4K6S2o6i4@1f1$3i4@1p5H3i4@1t1&6i4@1f1$3i4K6S2p5i4@1q4q4i4@1f1^5i4K6R3%4i4@1q4m8i4@1f1#2i4@1t1%4i4@1t1I4i4@1f1%4i4K6W2m8i4K6R3@1i4@1f1#2i4@1p5@1i4K6S2p5i4@1f1%4i4K6S2q4i4@1t1H3i4@1f1%4i4K6S2q4i4@1q4r3i4@1f1#2i4@1p5J5i4K6R3K6i4@1f1%4i4K6W2m8i4K6R3@1i4@1f1%4i4@1u0p5i4K6V1I4i4@1f1%4i4@1u0n7i4K6W2o6i4@1f1&6i4K6R3#2i4K6S2p5i4@1f1%4i4@1u0p5i4@1q4q4i4@1f1$3i4K6V1@1i4@1t1&6i4@1f1@1i4@1t1^5i4K6R3H3i4@1f1@1i4@1t1^5i4K6S2n7i4@1f1^5i4@1q4r3i4@1t1@1i4@1f1$3i4K6V1^5i4K6S2q4i4@1f1@1i4@1t1^5i4@1q4p5i4@1f1%4i4K6W2m8i4K6R3@1i4@1f1#2i4K6V1H3i4@1q4r3i4@1f1#2i4K6S2m8i4@1p5^5i4@1f1#2i4K6V1I4i4@1u0p5i4@1f1@1i4@1u0n7i4@1p5@1i4@1f1#2i4K6S2p5i4@1t1K6i4@1f1#2i4K6S2r3i4@1q4r3i4@1f1K6i4K6R3H3i4K6R3J5 在分析漏洞时候，有搜索翻阅下GL-iNet官方发布的相关安全信息，发现官方整理得很有序完善详实，建立有一个漏洞修复信息仓库，有漏洞描述、影响范围、固件版本或利用方式等，修复漏洞的CVE编号没有标明，但在GL-iNet安全更新信息发布网站中可以找到每个版本更新修复的CVE编号，梳理一下可轻松找到其对应关系。在梳理时候，我发现两篇复现文章末尾都用了另外一个无需登录即可执行rpc调用的漏洞CVE-2024-39227，不过作者都没有提到是这个漏洞编号，这个漏洞的成因和利用都非常简单，但危害性巨大，并且CVE-2024-39226看起来也主要是为了配合这个漏洞来实现未授权远程执行而找到的。复现分析完文章提到的两个漏洞后，我去官网下载最新的固件版本v4.6.6扒拉了下，发现像CVE-2024-39226这种本地或授权后可以命令注入类型问题还是不少的。拥有授权sid后/usr/lib/oui-httpd/rpc目录中文件的方法基本是可以任意调用，有些文件是luac文件反编译下即可。rpc目录下有十分多的类方法，简单翻了翻发现直接和间接进行命令注入的点很多，几乎防不胜防，想逐一修复工作量不小也不太有趣，思考下觉得这更像是一个系统框架设计问题吧，便和GL-iNet安全团队邮件反馈沟通了下，给出了一些示例。进一步思考下，最重要的安全防线基本就是一道授权防护了，拥有或者绕过授权后便是如入无人之境了，历史CVE有一些是授权绕过漏洞，看了下相比授权后注入漏洞会更有意思些，不难但很经典，修复后又被绕过，或者同一个攻击面找到了别的攻击点。所以此文一是对两篇GL-iNet路由器CVE-2024-39226漏洞复现文章进一步的补充，感谢作者无私的分享精神，我来进一步传递下互助分享的火炬，也为初学者提供一些有价值的资料和信息；二是复现分析下GL-iNet路由器几个授权相关的漏洞，看看最重要的防线都是怎样被突破的，以及修复后又是怎么再被突破的。以Ubuntu24系统为例，先安装qemu-system-arm。配置宿主机网络，参考QEMU搭建ARM64环境一文，先执行安装命令，安装后后宿主机会自动创建一个默认网桥virbr0。随后执行命令，创建并启用名为tap0的TAP设备，再将其添加到virbr0网桥中，并修改文件权限。接着执行ip addr查看virbr0网桥在宿主机中的网段，比如为192.168.122.1/24，后面配置虚拟机网络时候会用到。 根据要复现分析漏洞影响的版本去下载固件，可以在GL-iNet官方安全更新和漏洞仓库里面去找相应版本。进行仿真模拟的步骤都是一样的，到4d6K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6H3k6h3!0H3L8r3g2Q4x3X3g2V1k6h3u0A6j5h3&6Q4x3X3g2G2M7X3N6Q4x3V1k6Q4y4@1g2Y4K9h3!0Q4x3V1k6V1M7h3W2T1i4K6u0r3i4@1f1$3i4K6R3&6i4@1u0q4i4@1f1#2i4K6R3^5i4@1t1H3d9h3#2S2k6$3g2K6 for armhf-virt的链接下载，这是制作好的镜像，解压后可在readme.txt文件中看到镜像使用信息说明，如qemu-system-arm启动命令、登录方式密码等。 想要仿真系统和宿主机通信的话，就不能直接使用它的启动命令，可修改下启动配置中的网络部分，改为使用tap网络接口，id为net，名称为tap0。 启动后登录进入系统，执行ip addr可以看到网卡名称eth0，再执行命令给eth0网卡分配一个网桥virbr0网段中的ip，刚才我们已经在宿主机看了virbr0网段是192.168.122.1/24。执行后即

...(已截断)

---
来源: 看雪论坛
原文链接: https://bbs.kanxue.com/thread-284223.htm

好多路由器底层都是这一套框架，比如tp-link、锐捷的部分型号，可以去翻一下说不定有惊喜

windy_ll


好多路由器底层都是这一套框架，比如tp-link、锐捷的部分型号，可以去翻一下说不定有惊喜

未授权的估计都剩得不多了吧，授权后的感觉太水了，用途危害都不是很大的样子，准备搞搞别的..

编译binwalk源码安装了全部依赖提取出来了

最后于 2025-7-25 23:24
被mb_olhkibvp编辑

，原因：