[漏洞分析] 从零开始pwn掉一台古董路由器

a1辅助网提供[漏洞分析] 从零开始pwn掉一台古董路由器的下载地址,长期提供破解软件,各种线报福利等,62860是一个很好的福利资源网站

牛人啊。关键问题是楼主现在才高三,想知道你是从几年级开始学这些的?
秀啊!我电脑上的光污染,用黑笔涂黑的。
油性马克笔,涂完晾干。重复五六遍就好。[漏洞分析] 从零开始pwn掉一台古董路由器
支持研究的精神,虽然一个胶带就能解决诉求
0x01 背景介绍
最近准备高考实在无聊,于是突然想把卧室里一个网桥路由器pwn掉。主要为了把他面板上的指示灯关掉(这玩意已经造成了了严重的光污染)。大概搜索了一下发现没有任何已发布的这个路由的提权漏洞,所以只能自己搞了。
关键词:mips逆向,shell command injection,binwalk,crc32b,zlib,linux基础知识

0x02 信息收集

路由器型号:
ZTE-E5501S (14年产,老古董了)
路由器后台:
看不出来啥线索,感觉像是用lua当cgi后端。再看看用404页面看看服务器是啥
“`                                              <H2>404 Not Found</H2>
The requested URL ‘/114514’ was not found on this server.
                                          <HR>
                                          <ADDRESS><A >Mini web server 1.0 ZTE corp 2005.</A></ADDRESS>

是个自写的东西,估计也没办法直接利用,找了半天也没有任何上传点。
后台有价值的东西只找到了一个ping测试和配置文件备份恢复
路由器固件:
售后网站已经404了。。。网上找到一个型号相近的固件。

0x03 首次尝试——shell command injection
观察到ping测试是执行内建的ping命令,推测执行逻辑是 exec("ping "+测试的地址),所以尝试用shell command injection来任意执行shell命令
例如www.baidu.com;ls实际上会执行ping www.baidu.com;ls两个命令

此处省略n次尝试…
然而失败了,应该是限制了地址的字符集,只允许字母数字和小数点。
0x04 再次尝试——魔改配置文件
第二个可以尝试的点就是配置文件备份和恢复了,这一般也是一个比较容易利用的点。

先拉下来一个备份看看,是一个4491字节的bin文件。binwalk一波

可以看到,这个文件由一个大小0xC8的未知数据块和一个zlib压缩数据组成。通过熵分析,zlib之前的数据块应该是基本的magic header和一些元数据(因为熵非常低,排除了加密的可能性)。
愉快地解包0xC8处的zlib,打开配置文件居然找到一个内建的telnet server,直接修改配置文件,打开这个server。然后zlib重新打包数据,用dd把上面的未知数据块和新的zlib拼接出来新的bin文件。

小思考:为什么可以直接把原来的header拼接回去?
答:因为新的数据只改动了两个byte,并不会影响压缩前后数据的大小。假定header里面只记录了压缩前后数据的大小,那么这种修改是正确且有效的。
把拼接好的bin文件上传,重启路由器,登录telnet,本文完。





0x04 固件逆向
想多了!这配置文件居然还有完整性验证。

再次搜索网上一波配置文件格式,发现啥都没有。除了一个配置文件解包工具是直接从0xC8处提取zlib并且解压输出的,就没有任何有价值的信息了。不幸的是,上文已经找到了0xC8这个偏移量,只是需要header的信息,网上工具对于header里面存了啥只字未提(实际上直接跳过了header)。只能自己继续分析了。先上hexeditor看看

能推测出来的有关信息都标记了,只有黄色高光的地方不知道是啥。稍微改了一下配置文件再次导出,发现只有这里不一样,因此断定这里就应该是进行完整性校验的地方。
注意到这里是个64bit的hash,确实不是个很常见的长度。因为是14年的路由器,算力估计不太行,首先排除掉md5,sha1之类的比较吃算力的算法。再查一下14年之前比较广泛使用的64bit hash,有一个crc64和murmurhash64,分别带入计算,发现都不是。。。
恐怕是自己搞的算法,只能逆向固件了。
用unsquashfs解包下载的固件的rootfs,发现web后台是用lua写的,但是lua文件全部都是预编译的字节码,没办法直接看源码。一般情况下,lua字节码都可以用luadec反编译,但是路由器环境特殊,且实测这些字节码甚至根本不能被x64主机上的lua5.1加载,只能换个地方逆向。

bin文件夹内发现一个cspd,疑似路由器功能相关的守护进程,直接ghidra打开逆向看看,搜索cfg(config简写),发现一对config加密函数和解密函数
(为了便于描述程序逻辑,下图已经对部分局部变量名重命名)

可以看到,config加密函数传入了两个char*,分别为输入文件和输出文件,

然后打开文件并且读入缓冲区。读入后通过zlib的compress函数压缩缓冲区并且填充header。很显然可以在这里寻找header的那一个神秘64bit hash的算法。整个函数除了文件orw的系统调用和zlib压缩之外,只调用了两个没有符号名的函数,其中一次在压缩缓冲区时。
先进入第一个函数看,发现没有传任何参数,也只有对一个.data段变量的写操作,从而断定这个函数应该是hash算法的准备环节(无参数传入,唯一变量是只写引用,说明加密config时传入的数据不会影响其执行结果)。算法太长懒得看,先做个标记。

再看第二个函数,传入了被hash内容的地址和大小,应该就是hash操作。核心算法只有两行,看到param3传入的~0和param3=(param3>>8)^var1[(param3&0xff)^now]就知道这是一个crc32的变种(crc32b)。看到crc之后的swap endian操作就能断定是crc32b了。正常crc32是右移八位,而crc32b是左移八位且是big endian。这时不难发现,第一个函数的作用原来是生成crc32的查找表。(为啥不能硬编码进去呢?非要现场计算一下)
这里已经完成了逆向的大部分工作。第一次hash是对于header的,第二次hash是对于数据的,两个crc32b拼接到一起成为64bit的hash(2*32bit)
直接根据这个逻辑单独写个config打包器即可。(版规好像规定不能直接贴成品,就不贴代码了)

0x05 不忘初心

打包上传,路由重启之后成功打开了telnet server。用root登录上去,是一个32M内存的MT7620,关键是rootfs不可写,基本上不能搞一些有趣的东西了。

不过本文的目的本来就不是给路由器搞一些很奇怪的应用,只是关掉他刺眼的led灯。于是继续挖掘线索,在bin找到了ledkeytest。直接执行,发现没反应。加上ledkeytest -h依然没反应,只能再次逆向。

main的逻辑很简单,通过一个奇怪的判断之后,根据参数遍历匹配指令列表(这里的指令项是一个struct,应该是char* + callback),执行对应指令。其中ledoff就是需要的指令。执行ledkeytest ledoff。依然无反应。。。
那就是第一个判断挂掉了。第一个判断是打开/proc/csp/loadtype并且读取内容,判断是否为"2",如果是的话才执行指令。不幸的是loadtype的值默认是3(2应该是出厂测试模式),
由于procfs里面的文件内容无法直接修改,只能用一些非正常手段绕过判断。

这里的方法就很多了,一种思路是直接硬改ledkeytest,patch掉那个判断从而绕过限制。但是patch完了上传到哪里?还记得上文提到了这个系统的rootfs不可写(squashfs),只能替换文件重新压缩整个fs并且整体刷写rootfs镜像,变砖概率非常大。
下面介绍一种linux系统下的通法。
尽管procfs不可写,但是可以作为mount的挂载点。可以将/proc/csp作为挂载点从而覆盖其中内容。这里以tmpfs为例
mount -t tmpfs hackled /proc/csp

这时csp目录就被挂载到tmpfs(内存文件系统),内部内容清空,直接新建一个loadtype进去即可。
echo 2 > /proc/csp/loadtype
最后成功灭灯
ledkeytest ledoff

花费一晚上时间成功解决光污染问题。某位物理黑客说三秒钟就能解决这个问题,直接用黑胶布把灯贴上就好了。
小丑竟是我自己。&#128517;

部分文章来自互联网,侵权删除www.a1fz.com/

www.a1fz.com A1fz网专注于福利分享,各种破解软件学习资料,视频教程等等,如有侵权告知管理员删除
A1fz.com,福利吧,宅男福利,宅男,福利社,福利,有福利 » [漏洞分析] 从零开始pwn掉一台古董路由器

发表评论