[课业] | 软件安全 | 使用American Fuzzy Lop工具挖掘C/C++程序漏洞

文章目录

概念介绍

1. 模糊测试的概念

1.1 模糊测试技术的核心思想

• 模糊测试(Fuzz Testing)主要属于黑盒测试和灰盒测试领域，是一种基于缺陷注入的软件安全测试技术。
• 模糊测试技术的核心思想是通过监视非预期输入可能产生的异常结果来发现软件问题。 - 具体来说就是使用大量半有效的数据，以程序是否出现异常作为标志，发现应用程序中结构可能存在的安全漏洞。- 半有效数据是指，对应用程序来说，测试用例的必要标识部分和大部分数据是有效的，这样待测程序就会认为这是一个有效的数据，但是同时该数据的其他部分是无效的。这样，应用程序就有可能发生错误，这种错误可能导致应用程序的崩溃或者触发相应的安全漏洞。

1.2 模糊测试的方法

• 模糊测试可以简单到随意敲打键盘来输入随机数据。
• 早期的模糊测试方法多是基于对单一数据进行一维或多维变异来形成测试数据。当前，模糊测试已经演变成了更为有效的、自动化更加健全的技术。
• 模糊测试方法分类如下： - 预生成测试用例。需要理解对象规约支持的数据结构和可接受的范围，然后对应生成测试边界条件或者是违反规约的测试用例。生成测试用例很费神，但是可以复用。用完用例，测试结束。- 随机生成输入。效率最低，但是可以快速识别目标是否有非常糟糕的代码。- 手工协议变异测试。比随机生成更加初级。优点是可充分发挥自己过去的经验和“直觉”。常用于Web应用安全测试。- 变异或强制性测试。模糊器从一个有效的协议样本或是数据格式样本开始，持续不断地打乱数据包或是文件中的每一个字节、字、双字或是字符串。虽然该方法浪费了CPU资源，但是不需要对应用进行研究，并且整个模糊测试过程可以完全自动化。- 自动协议生成测试。需要先对应用进行研究，理解和解释协议规约或文件定义。但是这种方法并不基于协议规约或文件定义创建硬编码的测试用例，而是创建一个描述协议规约如何工作的文法。例如，SPIKE和SPIKEfile工具都是这类测试的典型例子，采用SPIKE脚本描述协议或是文件格式，并使用一个模糊测试引擎来创建输入数据。

2. 模糊测试的过程

模糊测试可以分为6个基本阶段，如图所示：

2.1 确定测试目标

• 不同的测试目标使用的模糊测试技术和方法也不一样。需要考虑对内部开发的应用程序还是对第三方应用程序进行模糊测试。还必须选择应用程序中的具体的目标文件或库，尤其是选择那些被多个应用程序共享的库，因为这些库的用户群体比较大，出现安全漏洞的风险也相应较高。
• 在此过程中，针对被测试程序，在一些典型的漏洞信息网站（如SecurityFocus、Secunia、CNVD等），查找软件开发商历史上曾出现的安全漏洞，分析这些漏洞的形成原因及编码习惯，有针对性地选择相应的模糊测试工具和方法。

2.2 确定预期输入

• 模糊测试是一个不断枚举输入向量的过程，任何从客户端发往目标应用程序的输入都应该作为输入向量，比如一个http请求，包括请求头、url以及发送的参数等，其他输入向量还有文件名、环境变量以及注册表键值等。
• 对不同的软件，可以选择性地侧重某些输入向量，但是一个完整的模糊测试过程应该进行充分、完全的测试。
• 例如，对tcp协议处理软件进行模糊测试，不仅要对数据部分进行测试，序号、确认号、数据偏移字段、标志位、保留字段、窗口以及校验和等部分也应该被纳入模糊测试的范围。

2.3 生成模糊测试用例

• 确定待测试目标和输入向量后，应该根据不同的输入向量选择不同的模糊器来生成模糊测试用例。由于数据量较大，这个阶段通常会采用自动化方式完成。
• 模糊器常用的生成测试数据的方法如下： - 基于生成的方法，在对目标软件输入数据格式的规约有深刻了解的基础上，自动生成一些不满足数据规约的测试样本。- 基于变异的生成方法，从一个合法的样本出发，通过某些算法不断地修改其中一些数据，生成一批畸形的测试用例。- 生成和变异相结合的方法。

2.4 执行模糊测试用例

• 执行模糊测试用例就是将上一阶段生成的大量模糊测试数据不断发送给待测试目标程序。面对大量的模糊测试数据，同样需要使用自动化工具来完成。

2.5 监视异常

• 监视异常可以发现程序哪里发生故障，并根据监视信息进一步分析为什么会产生故障。由于模糊测试过程比较长，当测试用例的数目较多时，常常需要采用自动化的方式实现。
• 当前常用的异常监视技术依据原理分为两种： - 基于调试的方法。在调试模式下启动目标软件，通过操作系统平台提供的调试API，开发有针对性的异常检测模块。此方法实现异常监视虽然难度较大，但更加高效。- 基于插桩的方法。在模糊测试过程中，仅仅通过观察程序的输入、输出，对了解软件内部的运行信息往往是不够的。例如软件运行过程中内部变量的状态信息、模块之间的交互信息等，这些信息对于发现漏洞及定位漏洞来说特别重要。基于插桩的方法就是在保证被测试程序原有逻辑完整的基础上，在程序中插入一些探针（又称为“探测仪”，本质上是进行信息采集的代码段，可以是赋值语句或采集覆盖信息的函数调用），通过探针的执行并抛出程序运行的特征数据，通过对这些数据的分析，可以获得程序的控制流和数据流信息，进而得到逻辑覆盖等动态信息，从而实现测试目的的方法。目前常用的插桩方法分为源代码插桩、静态代码插桩和二进制代码插桩等。 - 源代码插桩(Source Code Instrumentation)。这是一种最自然的方式，即在编写软件时，在需要监视的地方插入检测代码，如增加输出信息语句、增加日志语句等，尤其是面向切面编程技术(Aspect Oriented Programming)可以较好地用于源代码插桩，有效分离业务逻辑与监测逻辑。- 静态代码插桩。例如在Java中，字节码插桩可以直接更改中间代码文件（如Java的.class文件等）或在类被类加载器(Class Loader)装载时进行字节码插桩。字节码插桩拥有执行效率高、插桩点灵活等优点，使其在面向切面编程领域大放光彩，并陆续出现了BCEL、Javassit和ASM等工具。- 基于二进制的插桩。该技术可以进一步提高模糊测试的异常检测能力，但是其系统消耗较大，且大部分为商业插桩软件。常用的二进制插桩工具有DynamoRIO、Dyninst和Pin等。

2.6 异常分析并确认漏洞

• 异常分析并确认漏洞是模糊测试过程中的最后一步，主要分析目标软件产生异常的位置与引发异常的原因。常用的分析方法是借助于IDA Pro、OllDbg和SoftICE等二进制分析工具进行人工分析。

实验流程

1. 安装AFL

• 下载AFL源代码wget https://lcamtuf.coredump.cx/afl/releases/afl-latest.tgztar -zxvf afl-latest.tgzcd afl-2.52b
• 安装gcc编译器 - 原本打算通过安装llvm与clang进行编译，不过在之后执行sudo make install的时候报错"Oops, the instrumentation does not seem to be behaving correctly..."，经查可能是llvm版本问题，故改为gcc编译。sudo apt-get install gcc
• make并展示指令列表，确认安装成功make sudo make installalf-fuzz

2. 安装漏洞语料库、目标C程序

• 安装漏洞语料库mkdir testcasecd testcasewget http://samples.ffmpeg.org/tests/DivX-test/Xmen-OpenDivX-200-slow.avicd ..
• 确定目标C程序：选择的目标C程序是off-the-shelf C程序ultrix42-deroff.c，其内容存在于testfile.c内

3. 开始测试

• 对代码进行编译afl-gcc -g -o afl_test testfile.c
• 开始fuzzing程序- 原本使用的指令为afl-fuzz -i testcase -o output . /afl test，报错内容为- 修改配置，执行以下指令，结果如图sudo su rootecho ecore > /proc/sys/kernel/core_patternexit- 此问题解决之后再次报错显示内存的50M限制被占满，该用以下指令解决该问题。afl-fuzz -i testcase -o output ./afl_test sam2p @@
• fuzzing时的面板
• 结束后的面板

参考内容

1. 博客：AFL(American Fuzzy Lop)的初次使用使用
2. 教材：机械工业出版社《软件安全技术》
3. 博客：AFL(American fuzzy lop) 二进制程序模糊测试工具学习
4. 论坛：llvm_mode error with llvm 13: "Oops, the instrumentation does not seem to be behaving correctly"报错的原因
5. 博客：AFL黑盒测试FFmpeg（参照使用了此博客内实验流程使用的测试语料库）
6. 博客：fuzzing工具之AFL的安装与使用（参照使用此博客内实验流程的指令格式，解决"Oops, the program crashed with one of the test cases provided." 报错）
7. 代码：有漏洞的off-the-shelf C程序ultrix42-deroff.c
8. 官方网页：AFL官网