前言
在学习了一段时间的pwn后,我个人对漏洞挖掘也是充满了极大的兴趣,但是真实环境中的漏洞挖掘和CTF中的pwn题还是有很大区别的。原因在于,CTF中的pwn题代码量少,实现逻辑并不复杂,存在的漏洞也是比较明显的,一般都是通过代码审计就能发现;而在真实环境中,代码量大,实现逻辑复杂,虽然造成漏洞的代码可能和pwn题相差不大,但是在庞大的代码量下,通过代码审计的方式来发现漏洞并不是一个好的方式。因此,在工业界出现了fuzzing即模糊测试,其原理是变异输入来对程序进行测试,记录可以造成crash的输入,之后再单独分析这些输入。另外,对程序进行fuzzing来发现漏洞的软件叫fuzzer。
在本篇博客中要介绍的AFL就是fuzzer中的一个里程碑标志,其出现在2013年,并对之后出现的fuzzer产生了重大影响。AFL是基于代码路径覆盖率的,采用二进制插桩实现,可以分为有源码插桩和无源码插桩,下面介绍AFL的使用也是从这两个方向出发。
AFL的安装
AFL
安装的话从上面的官方链接点进去,如下截图所示,点击最新源代码打包工具的链接即可获得最新的源代码安装包。下载并解压成功后,进入到该文件夹中,使用make
命令进行安装,如果安装过程中出现问题,可以查阅docs/INSTALL
获得一些提示,看看是否有帮助,要不就百度一下。
AFL运行界面介绍
接下来看下AFL工作时的界面情况,如下截图所示,展示了AFL进行fuzzing时的工作界面状态。界面状态中的大部分内容都可以直接根据其中文意思知晓其含义,在本篇博客中将会简单介绍下大部分的状态指示。
- process timing – 指示了fuzzing测试的时间消耗。
一般说来一个中等程序的测试会需要数天或者数周的时间。其下面的四个状态栏信息按照中文翻译理解就行,值得说明的是,第二个状态指示last new path
,如果在程序开始测试的几分钟内没有变化,说明要么是程序引入不正确,或者是测试用例输入不正确,亦或者设置的内存太小,总之fuzzing没有正确启动。当然AFL会在last new path
长时间没有变化时给出警告。当然其实也有可能程序确实过于简单,比如我们自己写的测试程序,没有分支语句也会造成上诉情况。 - overall results – 汇总了fuzzing测试的执行结果。
第一个状态栏cycles done
表明fuzzing的轮数,其颜色值得说明一下,最开始是用品红色表示其处于the first pass
(关于the first pass
下一个小节会解释),正如截图中所示。如果在the first pass
后有新的发现,进入子过程,颜色会变成黄色,所有子过程完成后将会变成蓝色,最后变成绿色的话表明已经长时间没有新的动作了,此时也提示我们应该手动ctrl-c去关闭fuzzing。 - cycle progress