一、简介
Fuzzing(模糊测试)是一种用于识别软件bug以及漏洞的方法。就目前的发展趋势来说Fuzzing正向着云端迈进，相较于传统Fuzzing方式，云端Fuzzing使得模糊测试速度加快也更加灵活。在本教程中，我们将与你一同走完云端模糊测试的全过程(即部署，Fuzzing以及使用softScheck
Cloud Fuzzing Framework (sCFF)框架检索结果)。我们将以运行在Ubuntu
16.04上的tcpdump4.9版本为例进行演示，读者可下载sCFF框架，和我们一同玩耍。
二、背景知识
第一章节将讲解在使用过程中会遇到的一些基础问题。当然，如果你对云端模糊测试有一定经验或者对这些基础问题足够了解的情况下可以跳过本章节。此外，我们强烈建议从上到下依次阅读本文，子章节可能有些简短，但是都会提供大家进一步了解详情的传送门。
1. Fuzzing
Fuzzing是一项用于软件强度测试的技术。其核心思想是自动或半自动的生成随机数据输入到一个程序中，并监控目标程序异常，如崩溃，断言(assertion)失败，以发现可能的程序错误，比如内存泄漏。
这些异常大多数都是软件漏洞，经验丰富的攻击者完全可以进行利用。由于其自动化特性以及可以应用于所有软件中，Fuzzing常作为安全专家的基本装备存在。尽管知晓源代码可以加快模糊测试的速度，但是并非必须的。数十年来，模糊测试工具以及目标应用都是在本地计算机上运行。然而随着各种云计算服务商兴起，似乎在云端运行模糊测试工具也是个不错的选择。事实上像微软，谷歌等大型公司已经实现在云端进行模糊测试了。在云端模糊测试方面，微软还要领先一步，其Springfield项目甚至还向开发者提供云端模糊测试服务。
相对于传统模糊测试，云端模糊测试有哪些优点呢?首先你不需要额外购买计算机，省钱，节省空间，不需要花过多时间去设置环境等等，云端模糊测试的主要优势还是它所具有的灵活性，同一时间程序可以在多个操作系统上进行测试，检测是否会出现不同表现行为。如果一个项目对数据吞吐量要求较高，就可以利用RAID0阵列中的SSD。当一个应用程序需要大量的RAM，也可以选择一个相应的实例。如果需要测试一个web应用或者是网络协议，这里有许多低阶终端，所以相对来说完成任务的花费就很便宜。
当然这里也是存在缺点的。首先你得相信为你提供云服务的商家，因为所有数据都是在云端运行，而非你个人的计算机。此外，你多用几个月所需要支付的价格差不多也够你自己再买一台计算机的价格了。
2. Amazon AWS
Amazon Web Services是指Amazon提供的各类云端服务合集，目前AWS是全球最大的一家提供云计算服务的公司。AWS中有一个名为Elastic
Compute Cloud (EC2)的组件，EC2允许用户自己配置虚拟机作为服务器使用。在云端创建的这个虚拟服务器实例，在创建时就可以选择操作系统，预安装软件，资源分配等各种设置。至于操作系统，用户可以依靠Amazon庞大的镜像库AMI进行选择，我们可以从Amazon提供的100余种不同的机器配置中自由选择。用户只需要按每小时支付费用，当然配置越高收费越贵咯!
3. softScheck Cloud Fuzzer Framework
softScheck为了让模糊测试过程更加轻松，使用Python 3开发了softScheck Cloud
Fuzzer Framework(sCFF)，该框架使用Boto 3 API与AWS进行通信。sCFF遵循Unix范式将不同的子程序分开：一个程序专注一件事。
4. American fuzzy lop
American fuzzy lop (afl)是sCFF框架中的一个模糊测试工具。以其速度，可靠性，复古风格的UI设计以及赫赫战功而闻名。如果可以获得测试软件的源代码，不仅能生成更加客观的模糊测试结果，还能提高测试覆盖率。编者注：当前大多数远程代码执行和特权提升等比较严重的漏洞基本是使用Fuzzing技术挖掘的，然而Fuzzing技术仍然存在着覆盖率低的缺陷。而许多的代码漏洞需要更大的路径覆盖率才能触发，而不是通过纯粹的随机尝试。
5. tcpdump
Tcpdump是一款著名的网络数据包分析工具。它能抓取，显示，以pcap文件格式保存网络中的数据包，之后这些数据将以更友好的方式提供给使用者。不同于老大哥Wireshark，Tcpdump是一个非交互式命令行程序，对于模糊测试来说更加方便。
6. GNU Debugger
GNU DeBugger (GDB),可以对软件运行状态进行单步分析，更精确的找出导致程序崩溃的原因。如果分析的是包含调试标志的二进制代码，你可以知道当前程序正在运行代码的那一行，对于修复bug来说更加轻松。甚至还可以在运行时修改某些变量的值，用以快速观察变量值改变是否能修复bug。
三、使用sCFF来对tcpdump进行模糊测试
介绍完背景知识后，接着继续我们文首提到的tcpdump 4.9漏洞发现之旅。这一章分为两个部分，首先就是章节列表，这是需要你在继续本教程之前完成的任务。由于文章篇幅的限制，这些内容并没有写入文章，还好网上已经有大量的文章教程可以使用。其次涵盖了预模糊测试阶段，主要讲解了在真是环境下进行模糊测试之前应该做的事情，最后即是发现漏洞后你该怎么做。
1. 前期工作
如果你想要以云端模糊测试的方法找出tcpdump中存在的漏洞，你首先需要完成一些本教程没涉及到的步骤，基本上这些操作可以归结为AWS以及sCFF框架的配置。如果你想以传统的本地模糊测试方法寻找漏洞，或者仅仅只是了解一下云端模糊测试，你可以跳过这些步骤。
必选项：
创建一个AWS账号
导出AWS密钥ID和密钥
.aws/config中应该包含你的域信息，.aws/credentials中应该包含密钥ID和访问密钥
创建SSH安全组，以允许实例与外部端口22之间进行通信
创建并下载密钥对(SSH通信需要使用到这些密钥)
下载并安装sCFF;
可选项：
为了进行模糊测试， 需要安装AFL的语言环境
确保afl-collect以及GDB + exploitable plugin已安装
2. 预模糊测试阶段
前期工作完成之后，接着便下载tcpdump 4.9版本的源代码。你也可以下载最新的git版本，虽然本文作为案例的漏洞在新版本中已进行修复，但谁能保证不会有其他惊喜呢?在下载源代码之后，使用afl-gcc编译对于之后的模糊测试是有帮助的(CC=afl-gcc
./configure && make)
编译成功之后，运行scff-mkconfig指令创建一个sCFF项目文件。请确保将target设置为tcpdump，参数设置为–e
–r @@。其中-e和-r都是tcpdump的参数，-e表示打印扩展头，-r表示读取文件。这两个标志在之后会被afl每次生成的模糊测试文件替换。记住，如果你是是第一次注册AWS
t2机器，只要运行时低于750小时都可以免费使用。所以你可能会坚持使用t2机器进行模糊测试。为了更快的得到测试结果，推荐大家使用一个模版，使用了一个170btyes的pcap文件包含ipv4通信数据。作为借鉴，以下为我们通过scff-mkconfig命令创建的配置文件：
[INSTANCES]
amiami = ami-0963b466
gid = tcpdump49
instancetype = t2.micro
name = auto
numberofmachines = 4
platform = linux
[FUZZING]
dependencies = none
fuzzer = afl
fuzzdir = fuzzing
inputdir = fuzzing/input
outputdir = fuzzing/output
template = ipv4.pcap
target = tcpdump
args = -e -r @@ |
如今可以通过scff-create-instances命令来创建EC2实例，你可以使用密钥对通过SSH进行通信。
3. 模糊测试阶段
接下来，我们可以通过scff-ctrl . bootstrap命令对将用于模糊测试的机器进行设置。一旦设置完成，正式的模糊测试便开始。sCFF提供了单模Fuzzing和分布式Fuzzing。在单模Fuzzing下，每个实例都会单独运行模糊测试工具;分布式Fuzzing，虽然同样每个实例运行一个模糊测试工具，但模糊测试数据会在实例间共享，这样可以提升测试速度。如果你拥有两个以上的实例，我们推荐使用分布式Fuzzing模式，以scff-ctrl
. distributed指令启动分布式模式。如果想要了解模糊测试的状态，我们可以通过浏览器进行查看。
你可以使用scff-ctrl . grab-findings命令随时下载导致这些崩溃的文件。
4. 测试完成后
运行scff-exploitcheck命令可以对这些崩溃文件进行分析，误判和重复出现的崩溃信息将会被过滤，最后剩下的信息将会用于漏洞的检测和利用。
如果信息中有红色EXPLOITABLE标签，那么这里存在漏洞的可能性就非常高了。再用gdb对所发现的内容进行检测。如下图，tcpdump
4.9的文件printsl.c中存在一个可利用的漏洞。
经过进一步的调试，我们可以得知dir为255，并且dir也是lastlen中的指针(定义为lastlen[2][255])，这里存在参数越界，进而导致程序崩溃。
为了修复这个错误，我们要么调整dir的值，要么检查dir的值是否在0和2之间。在dir = p[DIR_SLX]后面设置一个断点，然后在gdb中修改该值(例如0,p=0)
再对源代码进行编译，之后检查程序是否还会崩溃。
四、总结
由于该漏洞需要用户使用-e参数来打开pcap文件才可以完成攻击，危害并不是特别严重。
当我将该漏洞报告给tcpdump安全团队，他们的响应速度的确称赞，该漏洞已在4.10版本中得到修复。得益于云端模糊测试以及优秀的工具包，整个测试过程大约花费五个小时，其中包括识别以及修复漏洞。
Downloading and compiling tcpdump: 10 minutes
Pre Fuzzing Phase + template generation: 10 minutes
Fuzzing Phase: 110 minutes
Post Fuzzing Phase: 60 minutes
Patch writing and retesting: 90 minutes
--------------------------
Total: 300 minutes |
|
