从零开始pwn掉一台古董路由器

fnv1c

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;

古韵新风

牛人啊。关键问题是楼主现在才高三，想知道你是从几年级开始学这些的？

pansophy

支持研究的精神，虽然一个胶带就能解决诉求

涛之雨

秀啊！我电脑上的光污染，用黑笔涂黑的。
油性马克笔，涂完晾干。重复五六遍就好。

空中的水

拆开外壳，把LED拿掉不行吗？

FleTime

同样在准备高考，感觉我是个废物

cat-

第一时间想到的是电工黑胶布

dutyzqly

太厉害了，这得知道多少知识点才能这么灵活运用啊

Wapj_Wolf

看不懂也要先了解一下大佬的思路。谢谢分享！

fnv1c

LearningPawn5 发表于 2021-3-24 17:32
嘶，拿tmpfs挂载覆盖内容下次启动的时候还会在吗？（虽然路由器也不经常重启就是了

重启会消失，但是这个方法很方便写自动化脚本关灯。
如果要永久起效果的话可以修改他的rootfs，开机自启动加一个关灯脚本就好了，但是这样子怕变砖

aaabbbcc123

太牛了吧

lifz888

非常好的地创意，支持分享

来根烟

感谢分享！

xiaobin0606

我只能说太厉害了 完全看不懂