模糊测试初体验

Loren夏季工作的办公桌和模糊测试集群 这个夏天从模糊测试开始——这项技术我早有耳闻但从未实践。其核心概念是向程序输入随机数据直到程序崩溃，然后分析崩溃原因来发现漏洞。由于时间限制，自写模糊器并不现实，于是我开始在网上寻找现有工具。

首先发现的是CERT的失败观察引擎(FOE)，这个工具本应大有可为。FOE提供多种参数用于精确调优，可针对特定目标定制。但实际使用中FOE表现不稳定：某些目标仅运行一次就停止，而非持续运行（这本是模糊器的基本要求）。于是转投其他工具，最终选定Linux平台的american fuzzy lop (AFL)和Windows平台的Microsoft MiniFuzz。

两者各有优劣：AFL最适合有源码的场景（主要针对开源软件，虽然实验性支持闭源二进制但效率较低）。配合源码编译时，AFL能获取代码覆盖率并在界面提供有用反馈。MiniFuzz则相反：专攻闭源Windows软件且运行时反馈极少，但其崩溃数据极为详尽——提供程序崩溃时所有寄存器值，这是其他模糊器不具备的。相比AFL复杂的编译设置，MiniFuzz基本属于点击即用型工具。

崩溃分析实战

当模糊器在VLC、Wireshark和Image Magick等目标上运行并产生崩溃后，真正的挑战开始了。AFL报告了VLC的多处崩溃，在验证可复现性时，我注意到多个崩溃都试图释放0x7d地址时出现段错误。这个异常小的地址引起了我的警觉，用十六进制编辑器检查崩溃输入文件后，果然在文件深处发现了0x0000007d的匹配项。将其修改为易识别的0x41414141后重新运行，段错误地址如预期变成了0x41414141！

确认能通过文件控制程序地址后，我开始深挖这个漏洞。这个过程让我与gdb和VLC源码建立了"亲密关系"。最终发现该漏洞允许释放两个用户可控的任意指针。

漏洞技术细节

VLC将文件不同部分作为"盒子"读取，并用带标签的联合体分类。漏洞源于类型混淆：当文件中的stsd盒子大小被修改扩大后，会错误地将后续的stts盒子视为其子项。VLC根据盒子类型及其父类型从函数表中索引读取函数，但错误的父类型导致匹配失败，转而使用默认读取方式将文件作为vide类型盒子读取。后续释放时仅检查自身类型触发正确函数，导致VLC尝试释放一个被当作通用vide盒子读取的stts盒子，直接从stts盒子中释放了两个地址。

QuickTime容器原子结构 CVE-2015-5949 由于控制两个释放地址可能形成有效攻击，我通过oCERT向VLC开发团队报告该漏洞，最终获得CVE编号CVE-2015-5949。经过多轮沟通后，该漏洞得到修复。

转向Web安全

在掌握模糊测试后，夏季的后半段我开始探索Web安全。相比模糊测试的即学即用，Web安全需要更多前置知识。我用一周时间研读《Web应用黑客手册》并完成MDSec实验，随后在HackerOne的漏洞赏金平台上实战检验，审查了ok.ru、marktplaats.nl和united.com等网站，提交了多份漏洞报告。

安全评估收官

实习最后阶段，我对纽约某科技初创公司进行安全评估，发现了应用逻辑、访问控制和会话管理等方面的漏洞，其中最严重的是可能造成重大财务风险的逻辑缺陷。在向公司汇报时，这些发现获得了积极反馈并正在修复中。

后记

在Trail of Bits的这段经历令我收获颇丰，奠定了应用安全和Web安全的坚实基础。在短暂休假参观大学后，我将在高三阶段继续兼职工作。