令人疑惑的boofuzz
本文最后更新于:2024年1月6日 早上
令人疑惑的boofuzz
本文最后更新于:2023年8月22日 晚上
0x0: 写在所有之前
boofuzz这一基于生成的fuzz框架,笔者一直有所耳闻
且在笔者学习Iot后,对于能fuzz网络协议的boofuzz,更是产生的极大的兴趣。所以,笔者抱着学习boofuzz后能在Iot漏洞挖掘中提高效率的目的于最近浅浅的接触了一下boofuzz。
然后,没有然后了
给笔者整破防了,直接原地道心破碎
PS:笔者这篇文章主要是记一点无用的板子和吐槽,各位大师傅如果想看源码解析或者逻辑思路的可以点×了。
0x1: 还算正经的板子
笔者这边fuzz的target是Tenda AX3
首先要抓包抓一点原始数据
1 |
|
其实根据这个就可以写原语了,但这个Request是login请求,没什么多大意义
于是笔者找了个存在漏洞的函数接口,先fuzz试试效果
1 |
|
具体怎么写框架笔者就不赘述了
在我指定漏洞位置(/goform/SetNetControlList)和危险参数的情况下,boofuzz效率确实还行,大概一分钟就跑出来了
可以看到在第1524个case DoS了
那说明1523个case发生了什么
很好,list参数造成了crash
笔者一开始还很兴奋,毕竟与AFL++的Qemu mode相比,boofuzz在fuzz Iot中无论是效率还是自由度高的不是一点半点,但是这是笔者定位好了漏洞所在位置的情况下。因为之前几个礼拜笔者对Tenda AX3小挖了一手,对历史漏洞自然是能很快的定位。但是,如果面对一个新设备,不同的功能函数接口有几十个,且不同功能对应的参数也不同,这时fuzz的效率就很令人质疑。
于是笔者便设置了3组group,每组group中设置了5个参数,将上面利用过的漏洞放入其中,类似
1 |
|
但不幸的是,跑了5、6个小时,快100万条case,还是没跑出来
且就算跑出crash,也只是大致漏洞定位,具体的poc还是得人工仔细审。
0x2: 一些怨气碎碎念
神奇的callback
因为发现DoS后py程序并不能停止,还是会不停尝试连接,于是便抄了一个callback板子根据http的回显来判断服务是否停止
1 |
|
结果发现我POST都没发送呢你先执行callback了,于是乎整个程序在case 1就直接down掉了
我是SB,我真nm是SB,😝——>🤡
原来我以为callback是放session.connect里的,结果要放到session里就好了,我真TM是个SB啊
1 |
|
神奇的monitor
boofuzz 只提供了三种 monitor:
ProcessMonitor 大概是和 Procman 进行 rpc 通讯来监控;
NetworkMonitor 具体用法不太清楚,看文档里说用了 wireshark,ubuntu没装wireshark,hai
CallbackMonitor 是默认的 Monitor,提供回调函数的功能,就是前面哪个callback
然后笔者试了process monitor,结果跑不起来一点,后来一想process monitor也不怎么重要,实在不行用gdbserver拿case一跑就行了
神奇的log
想把每个case都写进文件,到时候打exp拿payload会方便。结果问gpt全是错的,后来总算找到了一个把log写进.csv文件的方法
1 |
|
Tips
对于某些要先登录的设备,可以这么写
1 |
|
0x3: 最后的最后
有失望,或许吧,开始学Iot的时候一直想寻找一个能全自动化固件模拟,漏洞分析的工具,然而,想想就有点不太现实(但Shambles这东西感兴趣的师傅可以了解下,铸币笔者因为实在太穷不是很了解,但感觉很diao的样子,md快6位数一年的费用想想就恐怖)。
现在我可能会倾向于用FirmAE、fat、fap这些模拟一遍然后再用qemu进行手动验证吧,当然有真机能实操那就太棒了。
扯远了,前几天觉得AFL对这些闭源的固件用处不是很大,现在看来boofuzz的作用也有限,😂
可能过几天会看看FirmAFL,好像手上还有一篇对应论文来着。
翻出来了三个月前想入门Iot时和Iot界的传说的聊天记录