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

无人岛屿颈

0x01 配景介绍
最近准备高考实在无聊，于是突然想把卧室里一个网桥路由器pwn掉。主要为了把他面板上的指示灯关掉（这玩意已经造成了了严重的光污染）。大概搜刮了一下发现没有任何已发布的这个路由的提权毛病，所以只能自己搞了。
关键词：mips逆向,shell command injection,binwalk,crc32b,zlib,linux基础知识

0x02 信息收集
路由器型号:
ZTE-E5501S （14年产，老古董了）
路由器后台：
看不出来啥线索，感觉像是用lua当cgi后端。再看看用404页面看看服务器是啥
```                                              404 Not Found


The requested URL '/114514' was not found on this server.
                                          
                                          Mini web server 1.0 ZTE corp 2005.

是个自写的东西，估计也没办法直接利用，找了半天也没有任何上传点。
后台有代价的东西只找到了一个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


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


来源：http://www.12558.net
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！