tags:
CVE-2022-34747 漏洞分析与利用
1.漏洞描述
该漏洞于2022-09-06披露,Zyxel NAS326固件版本的格式字符串漏洞,允许攻击者通过精心制造的UDP数据包实现RCE.
2.漏洞分析
该漏洞已在新版本固件中被修复,不过在官网下载中心还可以下载到有漏洞的固件版本用于分析.
NAS326的设备固件上次更新是在1年多前了,版本不连续,不利于对比分析.
所以换成NAS540设备的固件列表看看,发现NAS540的漏洞临界版本是在1个月前更新的,所以选择这两个固件进行对比分析,定位漏洞模块.
V5.21(AATB.8)
V5.21(AATB.9)
NAS540
下载固件后使用binwalk命令对固件进行解包,得到如下结构.其实解包之后,差别特别明显,漏洞修复版本直接去掉了nsuagent这个程序,在其他的路径中也没有找到.(多出来的etc,lib是我后面修复动态链接库创建的)
AATB.8
AATB.9
由于是格式化字符串漏洞,所以主要需要定位一些格式字符处理的相关函数,在导入函数里面查找到了如下调用,通过交叉引用发现了此处的格式化字符串处理问题.
这是一个日志处理的函数,会将生产的日志信息,格式化后写入本地文件中,但是问题是这里的格式化字符串可控的.如果日志信息也可控,这里就是一个漏洞.
在sub_1aee4中,可以看到用户名密码的日志信息通过调用此函数被生产,是可以引起漏洞的一个位置.
下面开始分析程序的执行流程,如何执行到这个位置.
在main函数中,会获取参数”p:xxxx”,然后调用sub_19a80->sub_15408,其中会加载2个路径下的文件
/etc/apche/pubkey.pem
/etc/apche/testkey.pem
如果加载失败,会直接退出程序,导致流程无法继续,所以在后面调试漏洞时,要在这个路径放置证书文件.
调用成功后,将获取到的参数p:使用atoi函数转换为整形.最终调用sub_1aee4.
sub_1aee4->sub_159f8中会将传入的参数p,作为用于udp通信的端口.
然后接收长度最大为0x10d8长度的数据包,接收数据包之后通过sub_1bc48对数据包的格式进行了验证.
验证的步骤:
1.数据包的前两个字节左移8位,然后或运算前2个字节,判断结果是否为0x42
2.数据包的偏移0xA的2字节数据左移8位,然后或运算偏移0xA处2字节的高位,判断结果是否大于0xC
通过后返回偏移为3处的数据
3.在此函数外部,对偏移为3处数据进行了判断,如果为0x41,才会结束当前循环,停止继续接收数据,向下处理.
后面还有几处验证,比较简单
判断字符串中是否有参数
一些固定数据的判断
分析到此处,开始通过调试的方式辅助分析验证.
程序是arm架构的,使用qemu-arm模拟器创建调试端口配合ida动态调试.
首先要手动建立好软链接(这一步或许可以通过脚本实现?)
而后要创建前面所说的2个证书文件,都可以在解包后的文件中找到.
通过命令创建调试端口,指定udp通信端口为1111
1 | qemu-arm -g 7777 -L ./ nsuagent "-p 1111" |
运行至此处后,需要构造一个UDP数据包给漏洞程序接收
构造POC如下,使用此命令发送
1 | echo "$(</root/桌面/poc)" |nc -vu 192.168.164.129 1111 |
该程序开启了dep保护,需要在栈中构造rop进行利用.
//todo rop构造