在 Web 应用漏洞程序频出的当下，人们提出了许多技术来自动发掘 Web 应用程序中的漏洞，但这些技术也都有各自的缺点：白盒静态分析工具不仅需要源码，还往往局限于某一种编程语言而难以迁移，黑盒的扫描器则仅能发现预定义的规则模板所覆盖的漏洞。大家不禁要问，能不能把AFL这种人人都在用的工具也应用到Web应用漏洞测试上呢？今天我们分享的这篇论文 Toss a Fault to Your Witcher 就朝着这个目标迈进了一步：通过利用覆盖引导变异的灰盒模糊测试技术来检测 Web 应用程序的 SQL 和命令注入漏洞，作者来自 UCSB SecLab 和 ASU SEFCOM 这两个安全研究大组，目前论文已被 IEEE S&P 2023 接收。
作者为了实现WebAFL的宏大愿景，首先总结了传统fuzzing技术在Web应用程序漏洞挖掘上的挑战：
挑战一 如何检测 Web 应用漏洞被触发？
检测程序中是否存在漏洞实际上就是要判断程序是否处于 vulnerable program state，对传统二进制软件来说，检测到段错误（segmentation fault）就表示触发了漏洞，但 Web 应用程序，并没有直接的触发信号，那么应该如何判断？
挑战二 如何生成 Web 应用程序的合理输入？
Web 应用通常只接受 HTTP 和 CGI 请求，而 传统的 fuzzer 生成的 seeds 往往不满足相应结构，不能直接用来探索目标程序的输入空间。
此外，作者也同样关心fuzzing的那些经典指标（覆盖率，测试用例变异的有效性）在Web漏洞挖掘上的提升，指出了如下挑战：
挑战三 如何有效收集覆盖率信息？
覆盖导向型的 fuzzer 需要插桩目标应用程序来收集覆盖率信息，但对解释性语言编写的 Web 应用程序来说，插桩收集到的往往是解释器本身而非目标 Web 应用程序的覆盖率信息，这种信息大多是噪音，使得 fuzzer 无法有效探索目标程序的输入空间。
挑战四 如何有效变异测试用例？
传统 fuzzer 往往把输入当作无结构的比特流来变异，难以利用 Web 应用中的上下文信息（比如网页表单中的变量名）。
为了应对上述挑战，作者设计了名为Witcher的系统，整个系统的架构如下图所示：
让我们看看Witche怎么解决作者提出的四项挑战。
针对第一项挑战，Witcher使用名为 Fault Escalator 的组件，通过修改 shell 的源码并 hook libc 中用于和数据库通信的 recv 函数，使得当产生 SQL 或命令注入漏洞时，会自动触发段错误。这里还需注意，对于 SQL 注入漏洞的判断实际上是比较困难的，本文作者是以产生语法错误作为存在 SQL 注入的依据，因为一旦 fuzzer 的输入在未经检查的情况下被拼接为 SQL 语句，大概率会在解析时产生语法错误，不过最终是否存在可利用的漏洞还需在实验中进一步辨别。
针对第二项挑战，Witcher使用 Request Harness 作为 fuzzer 和目标 Web 应用程序之间的桥梁，将 fuzz 生成的输入翻译成有效的 HTTP 或 CGI 请求并发送给目标 Web 应用程序。具体来说，fuzzer 产生的 seeds 符合空字符分割的格式，包含 cookie，查询参数，POST 载荷等参数，harness 会构造对目标攻击点 URL 的请求，加入这些必要的参数后将请求发送给目标 Web 应用程序。当 Fault Escalator 发现漏洞触发时会就把段错误传回给 harness 进程，从而让 fuzzer 自动感知到错误。
针对第三项挑战，Witcher使用 Coverage Accountant 来更精确地收集覆盖信息，不同类型的解释型语言都需要先将源码翻译成字节码，然后再逐条执行字节码指令，Coverage Accountant 就是在解释器执行指令过程中将代码行数、参数等信息传给 Witcher。而对于 CGI 程序来说则只需使用 AFL 的编译插桩或 QEMU 动态插桩。
针对第四项挑战，Witcher实现了 HTTP-specific Input Mutations 以在变量的层面上对参数进行变异，具体来说就是为 AFL 增加了两个 mutation stage，使得 HTTP 参数在爬虫收集到的变量字典中以杂交的方式变异，从而使生成的测试用例更可能触发新的执行路径。
在对Witcher的效果进行评估时，作者主要围绕以下三个问题设计实验：
RQ1: Witcher 使用的增强性技术是否有效？
作者设置了四个配置 AFL, AFLHR, WiCR, WiCHR 代表启用/禁用 coverage acccountant 和 HTTP mutator 的四种情况，在 10 个 microtest 测试代码上运行，结果如下表所示，Witcher 的两种增强性技术极大地改进了 fuzz 效果。
RQ2: Witcher 识别 Web 应用程序中的漏洞效果如何？
为了测试 Witcher 扫描 Web 应用漏洞的实际表现，作者使用了不同种类应用组成的数据集来进行实验，其中有 8 个 PHP 应用，5 个路由器固件和 Java / Python / Node.js 应用各一个，共有 36 个已知的漏洞，对于每个漏洞都人工验证其是否 exploitable。
本轮实验的结果如下表所示，可以看出 Witcher 不仅检测到了超过六成的已知漏洞，还能许多发现未知的漏洞。而未检测出的漏洞大多是由于攻击点本身没被 crawler 爬取到，比如有些 URL 需要一系列点击操作才能触达或者根本是界面中不显示的隐藏后门。
RQ3: Witcher 的代码覆盖率和漏洞扫描效果与黑盒漏洞扫描器和其他工作相比如何？
作者主要将Witcher和知名的商业黑盒漏洞扫描器Burp对比，实验中设置了 Burp (solo) 和 BurpPlus Witcher 两种配置，分别采用内置 crawler 和 Witcher 的 crawler 提供的请求，后者能专注对比 Burp 和 Witcher 在输入生成上的效果，可以看出 Witcher 效果远胜 Burp。唯一的不足是 Witcher 专注于单页请求而不像 Burp 那样可能触发多个页面的状态。
Black Widow 和 WebFuzz 是今年对 Web 应用进行 fuzz 的工作，但它们主要关注 XSS 漏洞，因此本文只比较了其触发的代码行数，可以看出 Witcher 几乎占据绝对优势。
作者在文末也说明了 Witcher 的一些不足，首先是目前仅限于发现 SQL 和命令注入漏洞，而且在注入类漏洞中也只限于检测到单次请求的反射型漏洞，对于涉及多次请求的存储型漏洞，则无法精确判断具体是哪次输入触发漏洞。这种每次只 fuzz 一个 URL 的设计也使得它难以完整地感知 Web 应用的状态，作者认为可以结合一些相关工作来增进对其 Web 应用状态的理解，并支持发掘文件包含、XSS 等更多类型的漏洞。
论文地址：https://doi.ieeecomputersociety.org/10.1109/SP46215.2023.00007
原文始发于微信公众号（安全研究GoSSIP）：G.O.S.S.I.P 阅读推荐 2022-10-21
