前言
Web Fuzzer,作为Yakit平台的核心组件之一,已经超越了传统的“重放数据包”的功能,成为了一个多面的工具,支持更加丰富的功能,本篇文章会围绕最近添加的 Fuzzer 序列功能和 PoC 模板生成功能展开讲讲。
多请求 PoC 的免写攻略
在此前的poc免写攻略文章中,我们以 ThinkPHP RCE 为例,通过 "点点点" 的方式,生成了一个还算合格的 Yaml PoC 插件,相信小伙伴们在阅读后,心中多半会有一个疑问,例子中的 ThinkPHP RCE 只需要发送一次请求包即可判断漏洞是否存在,那么对于下列的一些漏洞场景,怎么办呢?
- 访问漏洞 API 前,需要先获取 token 的场景
- 上传文件后,想要对上传的文件是否成功进行判断的场景
- ... 其他需要前置包的场景
仔细思考可以发现,这些场景和 Web Fuzzer 序列功能十分契合,本质就是通过设置数据包发送的顺序,达到触发漏洞的目的,因此,对于多数据包的 PoC 生成也理所应当的被放在了 Fuzzer 序列中。
我们再以 ThinkPHP RCE 为例,为了体现出多次发包的要求,我们不再使用回显 phpinfo() 的方式判断漏洞检出,我们首先构造文件写入数据包,随后访问写入文件是否成功的方式来判断漏洞是否存在。
我们使用 Vulhub 启动一个 ThinkPHP 的靶场,随后在 Web Fuzzer 中构造如下数据包
HTTP
// 上传一个名为 test.php 的文件,文件内容是打印 Yakit md5 后的值,并且在访问后会自行删除 test.php 文件
GET /index.php?s=index/\think\template\driver\file/write&cacheFile=test.php&content=%3C?php%20echo%20md5(%27Yakit%27);unlink(__FILE__);?%3E HTTP/1.1
Host: 127.0.0.1:8888
送文件写入数据包
验证文件是否上传成功,通过我们上面发送的 Payload 内容可以知道,上传成功的标准应当是 response 中有 "Yakit" 字符串 md5 后的结果
点击发送数据包,观察结果,完美符合预期!复现漏洞阶段结束,接下来我们开始把这两个数据包变为一个插件,首先需要对第二个数据包设置一个匹配器,用于设置漏洞是否存在的条件,也就是我们前面提到的 Response body 中有 Yakit md5 后的结果
我们可以根据需求,选择使用硬编码匹配的方式进行判断,如下设置匹配 "53d363904730659dc7c1338948f77772"
也可以配合 设置变量功能 使用更加灵活的方式来设置匹配器,通过对结果和设置的变量进行比较来确认漏洞是否存在,如下所示:
之后我们可以把前面的两个数据包添加进一个 Fuzzer 序列组中,
点击开始执行,我们可以在 验证 数据包中,看见匹配成功的字样
随后我们就可以点击右上角的 "生成为 Raw 模板"
生成如下的 Ymal PoC
点击执行后,可以发现检出了漏洞
至此,我们使用序列构造的多请求包 PoC 就完成了,可以后续完善一些漏洞信息即可保存为 Yaml 插件,方便后续的使用了
Fuzzer 序列场景:CSRF Token 保护下的爆破
在官网的 Web Fuzzer 教程中,有热加载实现的 热加载场景案例:csrf token保护下的爆破,我们现在使用 Fuzzer 序列的方式来实现一下。
我们以pikachu靶场为例,安装pikachu靶场后(记得要初始化),我们打开如下页面:
任意输入账号密码之后,使用 Yakit 的 MITM 模块拦截登录请求,我们可以看到请求如下:
注意到除了用户和密码之外,还存在一个 token 的 post 参数,这是一个 CSRF token,它主要是用来防止CSRF攻击的,但是这也给我们的爆破增加了一定的难度,因为每次爆破都需要使用一个新的 token。
观察返回包中的 token ,后续的请求需要带上这个 token。
理清思路后,本次的爆破流程如下图所示
第一步,我们首先需要提取 token,使用 Web Fuzzer 中的提取器,添加一个变量名为 token 的 Xpath 提取器,使用 //input[@name='token']/@value进行匹配
由于第二个登录数据包中每次都需要一个新的 token,所以我们需要在进行登录尝试前,都去获取一次 token,因此,对于字典的设置,需要在第一个数据包中进行设置,第二个数据包中使用,最终,第一个数据包 "提取 token" 如下图,我们设置了一个名为 pass 类型为 fuzztag的字典,用于在后续包中使用。
提示
由于此靶场的Cookie 和 CSRF Token 有绑定关系,在获取 token 的数据包中,需要删掉Header 中的 Cookie
第二个数据包的设置就十分简单了,只需要使用数据包一中设置的两个变量token和pass。如下图
随后将数据包一和数据包二变成一个序列组,设置执行顺序即可开始进行爆破了
最后可以通过搜索字符串来进行验证,发现所有的 token 都正常使用
同时爆破出了 admin/123456 的用户名和密码
至此,我们通过序列对 CSRF Token 场景的爆破也已经完成。
小结
本文通过两个例子,分享了一些 Fuzzer 序列的场景,希望对大家有所帮助。