基于已知漏洞的ftp服务器的漏洞挖掘
我们的测试对象是EasyFTP 1.7.0.11,已知漏洞如下(github)：
| 命令 | 个数 |
|---|---|
| CWD | 1 |
| LIST | 1 |
| … | 11 |
Peach
简介
MichaelW Eddington等人开发的Peach是一个遵守MIT开源许可证的模糊测试框架，最初采用Python语言编写，发布于2004年，第二版于2007年发布，最新的第三版使用C#重写了整个框架。现在已经逐渐转入商业支持，我们这边调研使用的是peach社区版。
整体工作流程
xml的编写,一些重要的元素
DataModel定义发送的数据和接收的数据，可以支持很多协议的特性，例如校验码、固定长度元素等特性。
StateModel是最重要的元素，定义是状态机，规定输入和输出，按照有步骤的来。
还有一些其他的元素……
运行截图
命令行运行我们编写的ftp.xml，日志文件在c:\logs下。
在此命令下每个test生成10个测试用例，然后会显示发送和接收的数据。
在运行过程中会发现一些错误：
错误发现
peach会在WinDebugger监视进程下记录所有可能导致程序异常的的测试用例和栈的情况,测试时间和结果如下：
文件夹下记录status和出现的fault:
fault文件下文件夹命名方式和已知的漏洞和一些未知的错误
能查看导致程序崩溃的发送的数据和stack情况
Sulley
简介
Sulley一款用Python实现的开源Fuzz testing框架，主要应用于网络协议方面的测试. 目前现在关于这方面的测试工具也挺不少，不管是开源的（比如历史悠久的SPIKE, 或者是本文介绍的Sulley）还是商业的（比如Mu Dynamics公司的产品）
事实上，在Sulley出来之前，这方面的工具已经有一些了，但是为什么Sulley的作者还要选择重新造轮子呢？根据Sulley的文档，他这么做的理由是，当时已有的工具主要是专注在”数据生成“部分，**而仅仅做到这一步对Sulley是不够的，因为Sulley设计的目标是：不仅要简化数据生成，同样要简化与目标系统的之间的数据传输，以及目标系统的监控。**因此我们可以把刚才这段话理解成，Sulley要做的是一个能支持fuzz testing的整个测试流程的框架。在这一点上，显然Sulley的定位比起之前的工具高出了很多。而且事实上，Sulley的作者也不算是在造一个全新的轮子，比如在具体实现Sulley的时候，他也借鉴了一些当时已经成熟很成熟的Fuzz框架(SPIKE)的经验，比如用“块”结构的方式来构造数据，这点从Sulley构造Request所用的API接口就可以看出来，包括对于特定数据类型所用到的fuzz library也都直接从SPIKE拿过来
整体工作流程
sulley里面还有一些模块可以扩展，例如vmcontrol模块，可以控制虚拟机中程序奔溃返回原始状态
重要的概念–session,区别于peach里面的状态机
ftp里面的session如下图，sulley可以根据这幅图，自动遍历所有节点，保证每个节点顺利通过测试。
运行截图
运行process_monitor模块：
运行network_monitor模块：
运行编写的ftp2.py文件后，开始生成测试用例：
运行的时候还可以通过http:\\127.0.0.1:26000查看运行进度：
结果
运行时会对进行每个测试用例时候的网卡进行抓包
sulley会把运行的时候错误写在.crash_bin文件里，通过特定的插件可以查看crashbin文件里的内容，如下：
Sulley和Peach
功能方面：sulley和peach完成的功能点都是一样
开发角度：peach专注于xml文件的编写，其余部分几乎很少能改写，代码量比较大、没有详细的代码注释、现在开放的是社区版；sulley用代码来写测试，可以开发一些插件、监视器等,适用于深度开发。
ftp测试需要的代码量比较:peach的xml需要上千行代码，而sulley只需要300百行。
