基于模糊测试的分布式数据库安全研究(二)——第一次Fuzzing

前言

开始第一次Fuzzing啦。

一、AFL环境的配置

本次实践中,我们是采用AFL进行的。AFL全称为American Fuzzy Lop,它已经成为现在的主流模糊测试工具之一,它是利用插桩技术来进行路径覆盖的,下次代码再执行到此处时,会识别出上次插的桩,从而判断来过。(因为是第一次接触整个模糊测试技术,个人对AFL的原理理解也很浅薄,原理部分以后再进行分享。)

1.准备Linux系统

我采用的时VMware12安装的虚拟机,在虚拟机上安装Ubuntu16的Linux系统,对Linux系统的核心和内存分配都采用默认值。

2.安装编译环境

检查LLVM和Clang是否安装。

sudo apt-get install llvm
sudo apt-get install clang

sudo 是Linux系统管理指令,是允许系统管理员让普通用户执行一些或者全部的root命令的一个工具,如halt,reboot,su等等。 这样不仅减少了root用户的登录和管理时间,同样也提高了安全性。
apt-get 命令能自动从互联网中搜索目标软件,并进行下载、安装、更新等。
LLVM 是一个自由软件项目,它是一种编译器基础设施,以C++写成,包含一系列模块化的编译器组件和工具链,用来开发编译器前端和后端。
Clang 是一个C、C++、Objective-C和Objective-C++编程语言的编译器前端。 它采用了LLVM作为其后端,而且由LLVM2.6开始,一起发布新版本。

3.安装AFL

从官网上下载AFL安装包

wget http://lcamtuf.coredump.cx/afl/releases/afl-2.52b.tgz

使用tar指令对压缩包进行解压

tar -zxvf afl-2.52b.tgz

解压完成后,cd到解压出的afl文件夹中,执行以下指令进行安装

make
sudo  make install

安装完成后尝试输入afl-fuzz,已经能提示出各个指令时,说明安装正确。
在这里插入图片描述

二、开始Fuzzing

1.准备待测试的c程序

将待测试的c代码保存为文件afl_test.c

#include <stdio.h> 
int main(int argc, char *argv[])
{
    char buf[100]={0};
    gets(buf);//存在栈溢出漏洞
    printf(buf);//存在格式化字符串漏洞
    return 0;
}

2.用gcc编译并准备

使用以下指令对afl_test.c进行编译。(以下指令的意思还不太懂,后续再更新)

afl-gcc -g -o afl_test afl_test.c

编译后会生成一个新文件afl_test,该afl_test相当于“启动器”(在其他地方的参考资料看到,以afl_test这个文件开始fuzz之后它会保持不变?不太理解,找机会问问学长)在这里插入图片描述

有了afl_test这个Fuzzing启动器后,创建两个文件夹,分别设为fuzz_in和fuzz_out,一个用来存储输入的测试用例,一个用来存储输出的crash信息。在这里插入图片描述
在fuzz_in文件中新建一个文本文档,命名为testcase,在里面随便写个字符串作为启动Fuzzing的第一个测试用例,之后的测试用例都是从这个用例突变而来。(个人暂时是这样理解的,还不知道对不对,需要求证一下学长)

编译完成后还需临时修改一下系统配置,使系统将coredump输出到文件,而不是上报给系统的处理程序

echo core > /proc/sys/kernel/core_pattern

3.开始Fuzzing

执行以下指令开始Fuzzing。

afl-fuzz -i fuzz_in -o fuzz_out ./afl_test

(如果是继续上一次的Fuzzing操作,则用-来代替fuzz_in)

afl-fuzz -i - -o fuzz_out ./afl_test

我对这个指令的理解为:执行afl的fuzz功能,-i表示指定input为fuzz_in文件夹,Fuzzing时会自动先从这个文件夹里的testcase中抽取测试用例,-o表示指定整个Fuzzing的output为fuzz_out这个文件夹,随后定位到Fuzzing的“启动器”afl_test的位置,开始Fuzzing。
在这里插入图片描述
整个Fuzzing的界面如上图,unique crashes就是测试出的漏洞。(整个界面的其他信息还不太懂是什么意思,待后续学习时分享)

4.Fuzzing结果查看

Fuzzing是不会主动停止的,当感觉测试的差不多了就可以操作快捷键Ctrl+C进行停止(暂时的理解,但感觉应该是有表示差不多可以停止了这类的标志性信息,还需后续学习)
观察fuzz_out中的内容,盲猜crashes里面存放的就是出错的测试用例(显然不用猜),上网查了下,hangs表示超时的测试用例,queue里面是每个不同执行路径的测试用例。

在这里插入图片描述

想看具体的crash是什么样的嘛??按下面操作就可以啦。

首先cd到crashes文件夹里在这里插入图片描述

然后使用ls -al命令就能查看到所有crash的“标志信息”(不知道说的准不准确)
在这里插入图片描述
下面用xxd指令来查看这两个crash的具体情况
在这里插入图片描述
在这里插入图片描述
左边是16进制的表示形式(右边好像就是造成crash的具体用例的吧?问问学长再来)

三、目前的小问题

问明白了再来更新
1、编译c文件使用的指令afl-gcc -g -o afl_test afl_test.c每一步是啥意思讷?
2、通过上面的gcc编译生成的afl_test不会改变吗?插桩插上面了为啥还不变呢?
3、fuzz_in文件夹里边的testcase里的内容是第一个测试用例嘛?以后的用例都是基于它突变而来嘛?具体怎么突变的呢?第一个测试用例的设置有没有什么“讲究”?
4、整个Fuzzing界面各个部位的含义是什么?
5、Fuzzing过程中怎么确定是否可以停下来了?
6、Fuzzing输出的结果查看到了,但结果具体是啥意思捏?

四、问题解答

1、编译c文件使用的指令afl-gcc -g -o afl_test afl_test.c每一步是啥意思?

afl-gcc是afl所特有的编译器,不过在网上查了一下之后发现,它可以理解为是在gcc表面上套了层壳,实现了gcc的编译功能和afl特有的插桩,实际调用afl-gcc进行编译时,还是会转向调用gcc。-g就是gcc中的“生成调试信息”的指令,个人感觉在实现编译功能时并不是特别需要吧?-o可以理解为“-output”,output所接即为输出文件,剩下一个.c的文件名自然就是需要afl-gcc编译的C文件了。换一种写法其实会更明了一些,afl-gcc afl_test.c -o afl_test,直接由afl-gcc指向待编译的afl_test.c文件,输出的编译完成的文件命名为afl_test。

2、通过上面的gcc编译生成的afl_test不会改变吗?插桩插上面了为啥还不变呢?

程序的执行过程有4步:先进行预处理,随后进行编译,再对编译生成的文件进行汇编,最后进行链接。预处理时将代码中的头文件换成原始的C程序,并插入到程序中,生成.i文件,而在编译阶段就将预处理生成的文件编译为.s文件,该文件再经过汇编生成可直接执行的机器指令,保存为.o文件,链接时就将C语言标准库中的函数包链接到C程序中。AFL这个工具其实就是在编译时进行插桩的,插桩插的是一段统计代码(个人感觉是遇到一个统计代码的标记,就在AFL计数,所以afl_test这个文件是不会变的),我之前还以为是先输入测试用例,测试用例在运行过程中每找到一个分支路径就插个桩。

3、待续

应该是这样的,不过具体的突变方式也需要读源码才知道。测试用的设置肯定是有讲究的,afl提供了基本语料库和语料库蒸馏的方法,学了再来分享。

4、整个Fuzzing界面各个部位的含义是什么?在这里插入图片描述

process timing:部分表示Fuzzer运行时长(run time)、以及距离最近发现的路径(last new path)、崩溃(last unique crash)和挂起(last unique hang)经过了多长时间。

在这里插入图片描述
overall results:部分表示Fuzzer当前状态的概述,完成的测试轮数、代码路径数量、特定种类的崩溃次数、特定种类的挂起次数。
在这里插入图片描述
cycle progress:输入队列的距离。
在这里插入图片描述
map coverage:目标二进制文件中的插桩代码所观察到覆盖范围的细节。
在这里插入图片描述
Stage progress:Fuzzer现在正在执行的文件变异策略、执行次数和执行速度。在这里插入图片描述
Findings in depth:有关我们找到的执行路径,异常和挂起数量的信息。在这里插入图片描述
Fuzzing strategy yields:关于突变策略产生的最新行为和结果的详细信息。在这里插入图片描述
Path geometry:有关Fuzzer找到的执行路径的信息。

5、Fuzzing过程中怎么确定是否可以停下来了?

主要通过观察afl的状态栏来完成。
(1)”cycles done”字段颜色变为绿色
在这里插入图片描述
状态窗口中该字段的颜色可以作为何时停止测试的参考,随着周期数不断增大,其颜色也会由洋红色,逐步变为黄色、蓝色、绿色。当其变为绿色时,继续Fuzzing下去也很难有新的发现了,这时便可以通过Ctrl-C停止afl-fuzz。
(2)距上一次发现新路径(或者崩溃)已经过去很长时间了
在这里插入图片描述
这里显示的已经53分钟没有找到新的路径或crash了,估计也差不多了。
(3) 目标程序的代码几乎被测试用例完全覆盖,这种情况比较少见,但是对于某些小型程序还是有可能的。

6、Fuzzing输出的结果查看到了,但结果具体是啥意思?

暂时只知道xxd出来结果一大片的是栈溢出,长度较短的是造成崩溃的字符串用例。。在这里插入图片描述
在这里插入图片描述

已标记关键词 清除标记
目录 作者序 译者序 前 言 第一部分 第1章 安全漏洞发掘方法学 1.1 白盒测试 1.1.1 源代码评审 1.1.2 工具和自动化 1.1.3 优点和缺点 1.2 黑盒测试 1.2.1 人工测试 1.2.2 自动测试模糊测试 1.2.3 优点和缺点 1.3 灰盒测试 1.3.1 进制审核 1.3.2 自动化的进制审核 1.3.3 优点和缺点 1.4 小结 1.5 脚注 第2章 什么是模糊测试 2.1 模糊测试的定义 2.2 模糊测试的历史 2.3 模糊测试阶段 2.4 模糊测试的局限性和期望 2.4.1 访问控制缺陷 2.4.2 设计逻辑不良 2.4.3 后门 2.4.4 内存破坏 2.4.5 多阶段安全漏洞 2.5 小结 第3章 模糊测试方法和模糊器类型 3.1 模糊测试方法 3.1.1 预先生成测试用例 3.1.2 随机方法 3.1.3 协议变异人工测试 3.1.4 变异或强制性测试 3.1.5 自动协议生成测试 3.2 模糊器类型 3.2.1 本地模糊器 3.2.2 远程模糊器 3.2.3 内存模糊器 3.2.4 模糊器框架 3.3 小结 第4章 数据表示和分析 4.1 什么是协议 4.2 协议域 4.3 简单文本协议 4.4 进制协议 4.5 网络协议 4.6 文件格式 4.7 常见的协议元素 4.7.1 名字-值对 4.7.2 块标识符 4.7.3 块长度 4.7.4 校验和 4.8 小结 第5章 有效模糊测试的需求 5.1 可重现性和文档记录 5.2 可重用性 5.3 过程状态和过程深度 5.4 跟踪、代码覆盖和度量 5.5 错误检测 5.6 资源约束 5.7 小结 第部分 第6章 自动化测试测试数据生成 6.1 自动化测试的价值 6.2 有用的工具和库 6.2.1ETHEREAL /WIRESHARK 6.2.2LIBDASM 和LIBDISASM 6.2.3LIBNET /LIBNETNT 6.2.4LIBPCAP 6.2.5METRO PACKET LIBRARY 6.2.6PTRACE 6.2.7PYTHON EXTENSIONS 6.3 编程语言的选择 6.4 测试数据生成和模糊启发式 6.4.1 整型值 6.4.2 字符串重复 6.4.3 字段分隔符 6.4.4 格式化字符串 6.4.5 字符翻译 6.4.6 目录遍历 6.5 小结 第7章 环境变量和参数的模糊测试 7.1 本地化模糊测试介绍 7.1.1 命令行参数 7.1.2 环境变量 7.2 本地化模糊测试准则 7.3 寻找目标程序 7.4 本地化模糊测试方法 7.5 枚举环境变量 7.6 自动化的环境变量测试 7.7 检测问题 7.8 小结 第8章 环境变量和参数的模糊测试:自动化 8.1 iFUZZ本地化模糊器的特性 8.2 iFUZZ的开发 8.3 iFUZZ的开发语言 8.4 实例研究 8.5 益处和改进的余地 8.6 小结 第9章 Web应用程序和服务器模糊测试 9.1 什么是Web应用程序模糊测试 9.2 目标应用 9.3 测试方法 9.3.1 建立目标环境 9.3.2 输入 9.4 漏洞 9.5 异常检测 9.6 小结 第10章 Web应用程序和服务器的模糊测试:自动化 10.1 Web应用模糊器 10.2 WebFuzz的特性 10.2.1 请求 10.2.2 模糊变量 10.2.3 响应 10.3 必要的背景知识 10.3.1 识别请求 10.3.2 漏洞检测 10.4 WebFuzz的开发 10.4.1 开发方法 10.4.2 开发语言的选择 10.4.3 设计 10.5 实例研究 10.5.1 目录遍历 10.5.2 溢出 10.5.3 SQL注入 10.5.4 XSS脚本 10.6 益处和改进的余地 10.7 小结 第11章 文件格式模糊测试 11.1 目标应用 11.2 方法 11.2.1 强制性或基于变异的模糊测试 11.2.2 智能强制性或基于生成的模糊测试 11.3 输入 11.4 漏洞 11.4.1 拒绝服务 11.4.2 整数处理问题 11.4.3 简单的栈和堆溢出 11.4.4 逻辑错误 11.4.5 格式化字符串 11.4.6 竞争条件 11.5 漏洞检测 11.6 小结 第12章 文件格式模糊测试:UNIX平台上的自动化测试 12.1 NOTSPIKEFILE和SPIKEFILE 12.2 开发方法 12.2.1 异常检测引擎 12.2.2 异常报告(异常检测) 12.2.3 核心模糊测试引擎 12.3 有意义的代码片段 12.3.1 通常感兴趣的UNIX信号 12.3.2 不太感兴趣的UNIX信号 12.4 僵死进程 12.5 使用的注意事项 12.5.1 ADOBE ACROBAT 12.5.2 REALNETWORKS REALPLAYRE 12.6 实例研究:REALPLAYER REALPIX格式化字符串漏洞 12.7 语言 12.8 小结 第13章 文件格式模糊测试:Windows平台上的自动化测试 13.1 Windows文件格式漏洞 13.2 FileFuzz的特性 13.2.1 创建文件 13.2.2 应用程序执行 13.2.3 异常检测 13.2.4 保存的审核 13.3 必要的背景知识 13.4 FileFuzz的开发 13.4.1 开发方法 13.4.2 开发语言的选择 13.4.3 设计 13.5 实例研究 13.6益处和改进的余地 13.7 小结 第14章 网络协议模糊测试 14.1 什么是网络协议模糊测试 14.2 目标应用 14.2.1APPLEGATE 14.2.2 网络层 14.2.3 传输层 14.2.4 会话层 14.2.5 表示层 14.2.6 应用层 14.3 测试方法 14.3.1强制性或基于变异的模糊测试 14.3.2 智能强制性模糊测试和基于生成的模糊测试 14.3.3 修改的客户端变异模糊测试 14.4 错误检测 14.4.1 人工方法(基于调试器) 14.4.2 自动化方法(基于代理) 14.4.3 其它方法 14.5 小结 第15章 网络协议模糊测试:UNIX平台上的自动化测试 15.1 使用SPIKE进行模糊测试 15.1.1 选择测试目标 15.1.2 协议逆向工程 15.2 SPIKE 101 15.2.1 模糊测试引擎 15.2.2 通用的基于行的TCP模糊器 15.3 基于块的协议建模 15.4 SPIKE的额外特性 15.4.1 特定于协议的模糊器 15.4.2 特定于协议的模糊测试脚本 15.4.3 通用的基于脚本的模糊器 15.5 编写SPIKE NMAP模糊器脚本 15.6 小结 第16章 网络协议模糊测试:Windows平台上的自动化测试 16.1 ProtoFuzz的特性 16.1.1 包结构 16.1.2 捕获数据 16.1.3 解析数据 16.1.4 模糊变量 16.1.5 发送数据 16.2 必要的背景知识 16.2.1 错误检测 16.2.2 协议驱动程序 16.3 ProtoFuzz的开发 16.3.1 开发语言的选择 16.3.2 包捕获库 16.3.3 设计 16.4 实例研究 16.5 益处和改进的余地 16.6 小结 第17章 Web浏览器模糊测试 17.1 什么是Web浏览器模糊测试 17.2 目标 17.3 方法 17.3.1 测试方法 17.3.2 输入 17.4 漏洞 17.5 错误检测 17.6 小结 第18章 Web浏览器的模糊测试:自动化 18.1 组件对象模型的背景知识 18.1.1 在Nutshell中的发展历史 18.1.2 对象和接口 18.1.3 ActiveX 18.2 模糊器的开发 18.2.1 枚举可加载的ActiveX控件 18.2.2 属性,方法,参数和类型 18.2.3 模糊测试和监视 18.3 小结 第19章 内存数据的模糊测试 19.1 内存数据模糊测试的概念及实施该测试的原因 19.2 必需的背景知识 19.3 究竟什么是内存数据模糊测试 19.4 目标 19.5 方法:变异循环插入 19.6 方法:快照恢复变异 19.7 测试速度和处理深度 19.8 错误检测 19.9 小结 第20章 内存数据的模糊测试:自动化 20.1 所需要的特性集 20.2 开发语言的选择 20.3 Windows调试API 20.4 将其整合在一起 20.4.1如何实现在特定点将"钩子"植入目标进程的需求 20.4.2如何来处理进程快照和恢复 20.4.3如何来选择植入钩子的点 20.4.4如何对目标内存空间进行定位和变异 20.5你的新的最好的朋友PYDBG 20.6 一个构想的示例 20.7 小结 第三部分 第21章 模糊测试框架 21.1 模糊测试框架的概念 21.2 现有框架 21.2.1 ANTIPARSER 21.2.2 DFUZ 21.2.3 SPIKE 21.2.4 PEACH 21.2.5 通用模糊器(General Purpose Fuzzer) 21.2.6 AUTODAF? 21.3 定制模糊器的实例研究:SHOCKWAVE FLASH 21.3.1 SWF文件的建模 21.3.2 生成有效的数据 21.3.3 对环境进行模糊测试 21.3.4 测试方法 21.4模糊测试框架SULLEY 21.4.1 SULLEY目录结构 21.4.2 数据表示 21.4.3 会话 21.4.4 21.4.5 一个完整的实例分析 21.5 小结 第22章 自动化协议解析 22.1 模糊测试存在的问题是什么 22.2 启发式技术 22.2.1 代理模糊测试 22.2.2 改进的代理模糊测试 22.2.3 反汇编启发式规则 22.3 生物信息学 22.4 遗传算法 22.5 小结 第23章 模糊器跟踪 23.1 我们究竟想要跟踪什么 23.2 进制代码可视化和基本块 23.2.1 CFG 23.2.2 CFG示例 23.3 构造一个模糊器跟踪器 23.3.1 刻画目标特征 23.3.2 跟踪 23.3.3 交叉引用 23.4 对一个代码覆盖工具的分析 23.4.1 PSTALKER设计概览 23.4.2 数据源 23.4.3 数据探查 23.4.4 数据捕获 23.4.5局限性 23.4.6 数据存储 23.5 实例研究 23.5.1 测试策略 23.5.2 测试方法 23.6 益处和改进的余地 23.7 小结 第24章 智能故障检测 24.1 基本的错误检测方法 24.2 我们所要搜索的内容 24.3 选择模糊值时的注意事项 24.4 自动化的调试器监视 24.4.1 一个基本的调试器监视器 24.4.2 一个更加高级的调试器监视器 24.5 24.6 动态进制插装 24.7 小结 第四部分 第25章 汲取的教训 25.1 软件开发生命周期 25.1.1 分析 25.1.2 设计 25.1.3 编码 25.1.4 测试 25.1.5 维护 25.1.6 在SDLC中实现模糊测试 25.2 开发者 25.3 QA研究者 25.4 安全问题研究者 25.5 小结 第26章 展望 26.1 商业工具 26.1.1 安全测试工具beSTORM 26.1.2 BREAKINGPOINT系统BPS-1000 26.1.3 CODENOMICON 26.1.4 GLEG PROTOVER PROFESSIONAL 26.1.5 安全测试工具MU-4000 26.1.6 SECURITY INNOVATION HOLODECK 26.2 发现漏洞的混合方法 26.3 集成的测试平台 26.4 小结
相关推荐
©️2020 CSDN 皮肤主题: 游动-白 设计师:白松林 返回首页